Unauthenticated PHP code injection enables MetInfo CMS RCE

TL;DR — A remotely reachable, unauthenticated request path in MetInfo CMS can be abused to inject PHP and execute commands on the server, with public technical details and a working PoC.

What happened

MetInfo CMS is a PHP-based content management system used to build and administer websites.

CVE-2026-29014 describes a critical unauthenticated PHP code injection flaw enabling remote code execution (RCE) against MetInfo CMS versions 7.9 through 8.1. The CVE record states attackers can send crafted requests containing malicious PHP code, and that insufficient input neutralization in the execution path can lead to full compromise of the server.

The original researcher disclosure (Karma(In)Security) provides a concrete exploit chain in /app/system/weixin/include/class/weixinreply.class.php, specifically weixinreply::wxAdminLogin(). According to the write-up, attacker-controlled values from EventKey and FromUserName (XML tags in the HTTP request body for Weixin/WeChat API dispatch) reach cache::get() / cache::put() unsanitized; the $code parameter can be manipulated with path traversal to influence cache file inclusion and then force a write into /cache/weixin/Array.php, ultimately enabling PHP code injection and execution (via PHP’s curly syntax). The write-up links a proof-of-concept exploit that targets the Weixin endpoint and drops an interactive webshell flow.

Severity is CVSS v4.0 9.3 (Critical) (and CVSS v3.1 9.8 (Critical)) in the CVE record. Unauthenticated RCE in a CMS remains a high-signal internet-exploitation pattern because these systems are frequently exposed to the public web and often run with filesystem privileges sufficient for persistence.

Who is impacted

• Sites running MetInfo CMS versions 7.9.0 through 8.1.0 (inclusive), per the CVE record.
• Highest practical risk where the exposed Weixin/WeChat integration request path is reachable from untrusted networks.
• The researcher notes an additional prerequisite on non-Windows systems: successful exploitation requires the /cache/weixin/ directory to exist (created when installing/configuring the official WeChat plugin).

What to do now

• Treat this as an internet-facing emergency if your MetInfo instances are publicly reachable. Immediately inventory exposed MetInfo deployments (hostnames, containers, images) and confirm whether they fall in the affected range.
• If you operate the Weixin/WeChat integration, review the researcher’s solution status statement and plan compensating controls accordingly:

  • "No official solution is currently available."

• Reduce reachable attack surface while awaiting a vendor fix:
  • Restrict network access to the Weixin endpoint path used by the PoC (researcher PoC targets app/system/entrance.php?n=include&m=module&c=weixin&a=doapi) to trusted sources only, or disable the integration if not required.
  • Apply layered filtering (reverse proxy/WAF) to block unexpected request patterns into the Weixin handler until you can validate a vendor remediation path.
• Assume potential compromise if an affected instance was exposed:
  • Review web server and application logs for anomalous POST bodies targeting the Weixin handler and for evidence of command execution behavior.
  • Rotate secrets accessible to the CMS runtime (database credentials, API keys) and validate filesystem integrity under the web root and cache directories.