MetInfo CMS Under RCE Attack: Critical Vulnerability CVE-2026-29014 Actively Exploited

Threat actors are weaponizing CVE-2026-29014, an unauthenticated RCE vulnerability (CVSS 9.8) in MetInfo CMS. Activity spiked on May 1, 2026, putting approxima…

A significant surge in attacks against MetInfo CMS was detected on May 1, 2026, as threat actors actively exploit CVE-2026-29014 to achieve unauthenticated remote code execution (RCE). While an official patch has been available since April 7, 2026, active exploitation was observed as early as April 25 against honeypots in the United States and Singapore. For the approximately 2,000 internet-exposed instances—primarily located in China—the risk of total server compromise is now immediate.

Key Takeaways

CVE-2026-29014 affects MetInfo CMS versions 7.9, 8.0, and 8.1. With a CVSS score of 9.8, it allows for unauthenticated PHP code execution.
The attack chain targets the WeChat plugin: the wxAdminLogin() method writes the FromUserName parameter to a PHP cache file via cache::put() without proper sanitization.
Exploitation attempts began hitting honeypots on April 25, 2026, followed by a sharp spike on May 1, 2026, targeting IP addresses largely in China and Hong Kong.
Roughly 2,000 MetInfo CMS instances remain exposed online. Administrators are urged to apply the patch released on April 7, 2026.

Anatomy of the Exploit: From WeChat Cache to Code Execution

The vulnerability is located within the wxAdminLogin() method in /app/system/weixin/include/class/weixinreply.class.php. This function captures the user-provided FromUserName parameter and persists it to disk using the cache::put() primitive. The resulting PHP file utilizes double-quote string interpolation: $cache="{$data}";.

Because the input is not neutralized before being written, a remote attacker can inject a sequence leveraging PHP's {${eval(...)}} syntax. These curly braces trigger code evaluation within the string when the file is later processed or included by the server. This results in arbitrary command execution under the privileges of the web process.

Technical analysis from WebSec reveals that the payload is typically obfuscated within a custom HTTP header named C and decoded on the server side using Base64. This tactic partially masks the malicious intent during transit, complicating detection by security tools relying on static request body signatures.

"This vulnerability matters because it combines three properties defenders should treat as high priority: no authentication requirement, direct code injection into PHP execution flow, and public exploit availability." — WebSec Technical Analysis

Attack Timeline: From Initial Probes to the May 1 Spike

Initial scanning activity was recorded on April 25, 2026, when honeypots in the U.S. and Singapore intercepted malicious requests. This early phase confirmed that the publicly available Proof of Concept (PoC) had moved beyond research labs and into offensive toolchains.

The volume of attacks escalated sharply on May 1, 2026. Data from VulnCheck, reported by The Hacker News, indicates that the spike primarily targeted IP addresses geographically linked to China and Hong Kong. It remains unclear whether this surge represents a coordinated campaign by a single threat actor or simultaneous opportunistic activity by multiple groups.

The National Vulnerability Database (NVD) classifies the flaw as a PHP code injection that grants attackers full control over the impacted server. The 9.8 CVSS score reflects the critical severity resulting from remote access, the lack of authentication requirements, and the high impact on confidentiality, integrity, and availability.

The Role of Public Proof-of-Concept Exploits

The availability of a public PoC has significantly accelerated the transition from technical discovery to mass exploitation. WebSec documented how the payload exploits curly interpolation within dynamically generated PHP files, making the attack reproducible even for threat actors with limited resources. Such ready-to-use code reduces weaponization time to just hours following the publication of a security advisory.

Vector Analysis: Why the WeChat Module is a Critical Link

This flaw does not reside in an obsolete component, but rather in a WeChat integration feature widely used by site administrators targeting Chinese audiences. Installing the official plugin creates the /cache/weixin/ directory, which serves as the mandatory destination for the malicious file on non-Windows servers. Without this directory, the write path is unavailable, making the plugin an implicit prerequisite for the exploit on these platforms.

The underlying issue is architectural: data arriving from an external API is encapsulated into an executable PHP file without a neutralization layer. When a cache mechanism writes code instead of pure data, the boundary between storage and execution vanishes. In this instance, double-quote interpolation transforms any input into a potential instruction for the PHP engine.

Recommended Mitigation and Response

For administrators managing exposed MetInfo instances, the following actions are critical:

Immediately update MetInfo CMS to the patched version released on April 7, 2026. Versions 7.9, 8.0, and 8.1 are confirmed vulnerable.
Disable the WeChat plugin and remove the /cache/weixin/ directory if the module is not strictly required. On non-Windows servers, this directory is a prerequisite for the malicious file write.
Inspect web server logs for direct requests to weixinreply.class.php containing the HTTP header C with Base64 payloads or anomalous sequences in the FromUserName parameter.
Segment access to the administration panel and restrict the visibility of /app/system/weixin/ to trusted origins, applying the principle of least privilege at the network level.

It remains to be seen how many of the 2,000 exposed instances have applied the patch and how many have already been compromised. At this time, the identity of the actors behind the May 1 spike and the full extent of the damage have not been confirmed.

Frequently Asked Questions

Why does the attack require the WeChat plugin if the flaw is in the MetInfo core?

The vulnerable method belongs to the weixinreply.class.php class, which is loaded by the WeChat plugin. On non-Windows systems, the /cache/weixin/ directory—created during plugin installation—is necessary to store the malicious cache file. Without it, the exploit lacks the required write path.

How does this code injection differ from a standard SQL injection?

In an SQL injection, an attacker manipulates database queries. In this case, malicious input is written directly into a .php file via string interpolation. The {${eval(...)}} syntax triggers immediate PHP execution within the cache file, bypassing the data persistence layer entirely.

Is it possible to mitigate the risk without updating MetInfo?

On non-Windows servers, removing the /cache/weixin/ directory and disabling the WeChat plugin removes the prerequisite for the file write. However, the only definitive mitigation is the official April 7, 2026 patch, as other vectors could potentially emerge from the same vulnerable classes.

This incident underscores how auxiliary features like WeChat integration can become critical vectors when user input is written directly to executable files. For security teams, the priority is not only patching the CMS but systematically reviewing caching logic that generates PHP files from external data. Because no authentication is required, the margin for error is non-existent: administrators of exposed instances must act immediately.

Information has been verified against cited sources and is current as of the time of publication.