MetInfo CMS CVE-2026-29014 Exploited for Unauthenticated RCE Against Internet-Facing Servers

By Ash K May 5, 2026

An unauthenticated RCE in a public-facing CMS is the kind of vulnerability attackers do not need to overthink. They scan, they probe, and if the target is reachable, they try to turn the web server into their shell.

That is now the situation around CVE-2026-29014, a critical code-injection flaw in MetInfo CMS that VulnCheck has linked to active exploitation. The bug affects MetInfo CMS versions 7.9, 8.0, and 8.1, and gives remote attackers a path to execute arbitrary PHP code without credentials.

What Happened

VulnCheck disclosed CVE-2026-29014 on April 1, 2026, describing it as an unauthenticated PHP code-injection vulnerability in MetInfo CMS. The flaw is tracked as CWE-94, Improper Control of Generation of Code, and carries a CVSS 4.0 score of 9.3 from VulnCheck. NVD lists the CVSS 3.1 base score as 9.8 critical.

The Hacker News reported on May 5, 2026, that threat actors are actively exploiting the flaw. According to that reporting, patches were released by MetInfo on April 7, 2026, and exploitation activity was later observed beginning around April 25 against susceptible honeypots in the U.S. and Singapore.

The activity was initially sparse and appeared consistent with automated probing. By May 1, however, exploitation had surged, with reporting pointing to activity focused on China and Hong Kong IP addresses. SecurityWeek also reported that exploitation had intensified over the weekend and noted a focus on deployments in Singapore. Both accounts point to the same operational reality: attackers moved quickly from testing to broader targeting once exploitability was clear.

The Vulnerability

The issue sits in MetInfo’s Weixin integration path, specifically in the /app/system/weixin/include/class/weixinreply.class.php script. Security researcher Egidio Romano, who is credited with discovering the vulnerability, said the weakness stems from insufficient sanitization of user-supplied input when MetInfo processes Weixin, also known as WeChat, API requests.

That input can be abused in the CMS caching path, allowing a remote attacker to inject PHP code and cause it to execute on the server. On non-Windows deployments, successful exploitation has an additional condition: the /cache/weixin/ directory must already exist. That directory is created when the official WeChat plugin is installed and configured.

This is not a theoretical web bug that requires a chain of fragile assumptions. It is remote, unauthenticated, low-complexity, and tied to a public-facing CMS component. That combination is exactly why exploitation followed so quickly after disclosure.

Why This Stands Out

The operational risk is straightforward: attackers do not need a valid account. They do not need to phish an administrator. They do not need to wait for a user to click. If a vulnerable MetInfo instance is exposed and the right conditions are present, crafted requests can lead to arbitrary PHP execution.

Once attackers gain code execution inside a CMS environment, the next moves are predictable: web shell deployment, credential theft from configuration files, database access, malicious redirects, SEO spam, staging infrastructure, or pivoting into the hosting environment. For small and mid-sized organizations, a CMS compromise often becomes the attacker’s first foothold into broader infrastructure.

The exposure count is also meaningful. Public reporting cites approximately 2,000 MetInfo CMS instances accessible from the internet, with most located in China. That is not a massive global attack surface by enterprise software standards, but it is large enough for automated exploitation to pay off.

Known Exploitation Timeline

Date	Event
February 26, 2026	Researcher disclosure attempt to the vendor began, according to Karma(In)Security.
March 31, 2026	CVE-2026-29014 was assigned.
April 1, 2026	Public disclosure and VulnCheck advisory publication.
April 7, 2026	MetInfo released a security patch, according to researcher disclosure notes and public reporting.
April 25, 2026	Exploitation activity was reportedly observed against susceptible honeypots in the U.S. and Singapore.
May 1, 2026	Observed activity surged, with reporting pointing to China and Hong Kong IP space and continued targeting of exposed deployments.
May 5, 2026	The Hacker News and SecurityWeek reported active exploitation based on VulnCheck findings.

Why Defenders Should Care

The highest-risk systems are not simply “MetInfo CMS” installations. They are internet-facing MetInfo CMS 7.9, 8.0, or 8.1 deployments, especially those using or having previously configured the official WeChat plugin path that creates the vulnerable cache directory condition on non-Windows servers.

Security teams should treat exposed MetInfo systems as potentially probed. That means patching is necessary, but not enough. If the system was reachable before patching, defenders should review web server logs, CMS directories, PHP files, recently modified cache artifacts, unexpected admin accounts, suspicious outbound connections, and changes to site content or templates.

Because the vulnerability allows code execution, incident responders should also assume that successful exploitation may leave behind persistence outside the obvious CMS directory. A clean version check does not prove the server was never compromised.

Recommended Actions

Organizations running MetInfo CMS should immediately upgrade to a patched version from the vendor and confirm that versions 7.9, 8.0, and 8.1 are no longer exposed to the internet.

Defenders should search access logs for unusual POST requests to Weixin-related paths, requests touching /app/system/weixin/, unexpected writes under /cache/weixin/, and PHP files created or modified around April 25, May 1, and later. Any suspicious cache files or recently modified PHP artifacts should be investigated before being deleted, so responders can preserve evidence.

Teams should also restrict direct internet access to CMS administration and plugin endpoints where possible, place high-risk CMS deployments behind a WAF or reverse proxy, and monitor for outbound traffic from the web server to unfamiliar IP addresses. Web servers should not have broad write permissions across application directories unless the CMS explicitly requires it.

NeuraCyb's Assessment

CVE-2026-29014 is a reminder that attackers still win quickly when a public-facing application turns user input into executable code. The defender priority is not just “patch the CMS.” It is to prove whether the server was touched before the patch landed, because with unauthenticated RCE, the compromise window starts the moment the exploit becomes operational.

References

Ash K

Ashton is a seasoned Cybersecurity Professional with over 25 years of experience in Cybersecurity Research, Cybersecurity Incident response, Products and Security Solutions architecture.