MetInfo RCE Is Being Exploited. Patch Timing Matters

MetInfo CMS CVE-2026-29014 is now under active exploitation. Here is what the bug does, which versions are named, and what operators should verify next.

2026-05-13 GIGATAP Team #security
#metinfo#cve-2026-29014#rce

MetInfo CMS RCE Is Being Exploited. Patch Timing Matters

What is known#

Threat actors are actively exploiting CVE-2026-29014 in MetInfo CMS, according to VulnCheck. The flaw is described as a critical PHP code injection issue that can lead to remote code execution.

NIST’s entry says MetInfo CMS versions 7.9, 8.0, and 8.1 contain an unauthenticated PHP code injection vulnerability. In plain terms: an attacker does not need to log in if they can send crafted requests with malicious PHP code.

The issue sits in /app/system/weixin/include/class/weixinreply.class.php. Per researcher Egidio Romano, the root cause is weak sanitization of user input in the path used to issue Weixin, or WeChat, API requests. That opens the door to arbitrary PHP execution if the request is built the wrong way.

There is one important environment detail. On non-Windows servers, exploitation also depends on the /cache/weixin/ directory already existing. The directory is created when the official WeChat plugin is installed and configured, so the attack surface is not universal in practice. But it is still broad enough to matter.

MetInfo fixed the issue on April 7, 2026.

Why it matters#

This is not a theoretical bug anymore. VulnCheck says exploitation began on April 25, first as a small number of attempts against honeypots in the U.S., then with a larger surge on May 1. That later activity focused on China and Hong Kong IP addresses.

That pattern usually means two things. First, attackers are willing to test the flaw at scale. Second, they are already sorting targets by likely exposure or value.

The NVD language is blunt: insufficient input neutralization in the execution path can let an attacker gain full control of the affected server. That is the part operators should not hand-wave away. If a CMS instance is reachable and vulnerable, code execution is the end state, not just a noisy bug report.

VulnCheck also notes that as many as 2,000 MetInfo instances are accessible online, most of them in China. That does not prove all 2,000 are vulnerable. It does mean the public exposure pool is large enough that exploitation can continue without much effort.

For ordinary users, the consequence is indirect but real. A CMS compromise can lead to defacement, data theft, malware hosting, or a pivot into the rest of the server environment. In hosted setups, one weak CMS can also become a foothold for broader intrusion.

What not to overclaim#

The source material does not say how many victims were compromised. It does not say whether the observed honeypot activity turned into confirmed real-world intrusions. It also does not provide a full exploit chain or post-exploitation behavior.

So the safe claim is narrower: the bug is patched, public, and under active exploitation. That is enough to treat it as operational risk.

It is also worth keeping the scope tight. The vulnerability is tied to specific MetInfo versions named by NIST and to a particular code path associated with Weixin integration. If a system does not run those versions, or does not have the relevant plugin and directory state, the exposure may be different. That does not remove the need to verify, but it does matter for triage.

What to check next#

If you run MetInfo, the practical next step is simple: confirm your version and verify whether the April 7 patch is applied.

A quick review should cover:

  • the installed MetInfo version, especially 7.9, 8.0, and 8.1
  • whether the official WeChat plugin is installed and configured
  • whether /cache/weixin/ exists on non-Windows servers
  • whether the server has any unexpected PHP files, new admin accounts, or recent changes
  • web logs around late April and early May for suspicious requests to the Weixin reply path

If patching is not immediate, isolate the instance as much as possible. Limit public access, review WAF or reverse proxy rules, and watch for request patterns aimed at the vulnerable path. If the CMS is internet-facing and unnecessary, remove the exposure window rather than assuming low traffic equals low risk.

The bottom line#

CVE-2026-29014 is the kind of CMS flaw that moves fast once it lands in active exploitation. The patch is already available, the code path is known, and probes have been observed.

That makes this a verification job, not a debate. Check the version. Check the plugin state. Check the logs. Then assume the internet has already done the same.