MetInfo CMS CVE-2026-29014: a 9.8 PHP code-injection RCE in a CMS most Western admins have never heard of. The detection runbook for the long tail.

# MetInfo CMS CVE-2026-29014: a 9.8 PHP code-injection RCE in a CMS most Western admins have never heard of. The detection runbook for the long tail.

VulnCheck published yesterday (May 5, 2026) on CVE-2026-29014, an unauthenticated PHP code-injection vulnerability in MetInfo CMS 7.9, 8.0, and 8.1 that yields full remote code execution. CVSS 9.8. Active exploitation in the wild, traced back to early April 2026. The Hacker News picked it up the same day. The vulnerability lives in a parameter-handling routine that takes user input and concatenates it into a PHP function call without escaping — the textbook 2010s-era PHP code-injection bug, alive and well in 2026.

This is going to be one of those CVEs that doesn't trend because most Western IT admins have never heard of MetInfo. That is exactly why I'm writing it up. If you operate any web hosting in the United States, Europe, Canada, or Australia, you almost certainly have MetInfo CMS instances in your customer footprint that you don't know about. It's the dominant Chinese-language SMB CMS and gets installed on shared-hosting accounts by Chinese-diaspora business owners, immigration-services providers, restaurant supply firms, herbal-medicine shops, and a long tail of small-business sites whose proprietor procured the CMS in their language and never told their hosting provider what software they were running. Hosting providers typically discover MetInfo on their box only when the box gets popped.

This post is the runbook: how to find every MetInfo install on your infrastructure, how to detect compromise (because the campaign has been running for five weeks before the public disclosure), and how to handle the customer-communication problem when you find compromise on a customer site whose proprietor doesn't speak English.

#What MetInfo actually is (and why it's everywhere you don't look)

MetInfo (米拓 / mituo) is an open-source PHP-based CMS developed by Changsha Mituo Network Technology Co., Ltd. It's been around since 2008 and ships in two editions: a free open-source release and a paid enterprise edition. The free edition is the one that gets installed on shared hosting at scale, primarily because:

• It's localized for Chinese-language SMB sites by default. The admin interface is in Simplified Chinese; English is a configuration toggle that most Chinese-speaking proprietors don't touch.
• The default templates look like polished modern websites — corporate, e-commerce, product-catalog, enterprise — without any of the WordPress aesthetic. Sites built on MetInfo tend to look professional in a way that WordPress sites of equivalent vintage don't.
• It bundles SEO tooling for Baidu and 360 by default. WordPress and Drupal default-bundle Google SEO; MetInfo defaults to the Chinese search ecosystem, which is what its target market needs.
• It's installable in a few clicks via cPanel's Softaculous or DirectAdmin's installer. A proprietor with shared hosting and basic technical literacy can have a MetInfo site live in 15 minutes.

MetInfo's installed base is heavily concentrated in mainland China but substantial in:

• The United States Pacific Northwest, California, and the Northeast — Chinese-diaspora business sites (restaurants, importers, immigration consultancies, language schools, herbal medicine shops, real estate agents serving Chinese-language clients).
• Canada, particularly Vancouver, Toronto, and Calgary — same demographic mix.
• Australia, especially Melbourne and Sydney.
• Western Europe — primarily UK, France, and the Netherlands; smaller but non-trivial.
• Singapore, Hong Kong, Taiwan, and Malaysia — meaningful enterprise as well as SMB usage.

If you operate shared hosting, a managed-WordPress hosting service that also hosts non-WP sites, a domain-name reseller with hosting bundled, or a small-business website-builder service, you almost certainly have customer sites running MetInfo in your environment. You do not know which ones because most onboarding flows do not ask "what CMS will you install?" and most monitoring stacks do not fingerprint MetInfo by default.

#CVE-2026-29014 — what we know

VulnCheck's writeup establishes:

• Bug class: unauthenticated PHP code injection. A request parameter is read and concatenated into a eval()-equivalent call without escaping.
• Vulnerable path: an admin module called via the URL pattern /admin/?n=&c=&a= where specific (module, class, action) triples reach the vulnerable function.
• Authentication required: none. The vulnerable code path is reachable before the admin login check fires.
• Privilege gained: the privilege of the PHP process. On most shared-hosting setups, that's the cPanel user that owns the website's home directory — which is enough to fully own that customer's data. On poorly-configured hosting, it's nobody or apache, which is a foothold for further escalation.
• Versions affected: MetInfo CMS 7.9, 8.0, and 8.1. Earlier versions (7.x prior to 7.9) have a different code path and are not affected by this specific CVE — but they have plenty of their own CVEs, and any 7.x install should be considered legacy and unsafe regardless.
• Active exploitation since: at least April 5, 2026 per VulnCheck's telemetry.

The post-exploitation pattern observed in the wild is consistent across victims:

1. Initial RCE drops a .php webshell into /upload/ or /include/ of the MetInfo site directory. Common shell names include metinfo.php, update.php, uploads.php, and 1.php.
2. The shell is used to enumerate the broader cPanel/DirectAdmin environment if accessible — ~/mail/, ~/etc/shadow (if readable), neighbor user directories.
3. Credentials and session tokens are pulled from the MetInfo database (config_db.php) and any wp-config files in adjacent customer accounts.
4. The shell is used to drop additional customer-targeted phishing pages on the now-controlled hosting account, leveraging the legitimate domain to bypass URL reputation systems.
5. Persistence via .htaccess modifications and additional shell uploads in obscure subdirectories.

#Detection — find your MetInfo footprint first

If you operate shared hosting at any scale, run this scan. It's the only way to know your exposure.

Find every MetInfo installation across your customer accounts:

# Run as root on the cPanel/DirectAdmin/Plesk host. Scans every customer
# home directory for MetInfo's distinctive marker files.
find /home/*/public_html -maxdepth 4 -type f \
    \( -name "metinfo.php" -o -name "config_db.php" -o -name "tag_class.php" \) \
    2>/dev/null

# More aggressive: any file containing the MetInfo signature string
grep -lr "MetInfo Enterprise Content Management System" \
    /home/*/public_html 2>/dev/null

Identify the exact MetInfo version on each install:

# Each install has a version file at /admin/include/version.php
for f in $(find /home/*/public_html -name "version.php" -path "*admin/include*"); do
    site=$(echo "$f" | awk -F/ '{print $3}')
    version=$(grep -oP 'metinfo_version.*?[\d.]+' "$f" | head -1)
    echo "$site $version"
done

Hunt for shells that the campaign drops:

# Look for recently-modified PHP files in upload directories and include dirs
find /home/*/public_html -name "*.php" -mtime -45 -path "*upload*" -o \
                          -name "*.php" -mtime -45 -path "*include*" \
    2>/dev/null

# Check for the specific known shell file names
find /home/*/public_html -type f \
    \( -name "metinfo.php" -o -name "1.php" -o -name "update.php" \
       -o -name "uploads.php" -o -name "x.php" -o -name "shell.php" \) \
    -mtime -45 2>/dev/null

# Check file contents for common webshell patterns
grep -lr -E "(eval\(\\\$_POST|eval\(base64_decode|assert\(\\\$_POST)" \
    /home/*/public_html 2>/dev/null

Hunt for tampered .htaccess files:

The campaign sometimes adds .htaccess rules that route requests for specific URLs to attacker-controlled scripts.

# Find every .htaccess modified in the last 45 days
find /home/*/public_html -name ".htaccess" -mtime -45 -type f 2>/dev/null

# Sanity-check each one for unusual rewrite rules pointing to obscure scripts
for f in $(find /home/*/public_html -name ".htaccess" -mtime -45); do
    echo "=== $f ==="
    cat "$f"
    echo
done

Hunt for PHP processes spawned outside normal request handling:

# Active PHP-FPM workers and their command lines (most shared hosting uses
# PHP-FPM per-customer pools). Look for anything unusual.
ps -ef | grep php | grep -v grep

Hunt for outbound C2 connections from PHP:

# What's the FPM master and workers connecting to that's not normal HTTP?
ss -tnp | grep php

If any of the above turns up evidence of compromise on a customer's MetInfo install, that customer's account needs to be treated as fully compromised. Webshells often reach beyond the customer's own account on poorly-isolated shared hosting, and the cleanup goes from "patch one site" to "rebuild the whole hosting stack."

#Mitigation if you can't patch (and the customer doesn't speak English)

Most shared-hosting operators do not speak Chinese, and most MetInfo proprietors do not speak English. The patch coordination is going to be brutal. Here is the practical workflow:

1. Block the vulnerable URL pattern at the host level, not at the customer-account level. A mod_security rule or a hosting-level WAF rule that blocks any request matching the vulnerable URL pattern protects the customer account whether or not the proprietor responds to your patch notification.

Sample mod_security rule (run on Apache or LiteSpeed):

SecRule REQUEST_URI "@rx /admin/.*[?&]n=.*&c=.*&a=.*\b(do_save|do_export)\b" \
        "id:202629014, phase:1, deny, msg:'CVE-2026-29014 MetInfo RCE attempt'"

1. Send a patch notification in Simplified Chinese to the customer's billing email. Most MetInfo proprietors will respond to a Chinese-language email faster than an English one. Have a translator on retainer or use the canned text below — CVE references travel in any language.

Example notification (verify with a native speaker before broadcast):

> 紧急安全通知：您的 MetInfo CMS 网站存在严重安全漏洞 (CVE-2026-29014)。请立即升级到最新版本。如需技术支持，请联系: [your support email]

1. Set a 7-day grace window for customer response, then forced upgrade. Most shared-hosting Terms of Service include a clause about taking action on critical security issues without explicit customer consent. After the grace window, you upgrade the customer's MetInfo install yourself. Yes, this risks customizations. Yes, this risks template breakage. The alternative is the customer's site joining a botnet next week.

1. For accounts that don't respond and can't be safely auto-upgraded, suspend the site. Replace the site index with a placeholder explaining (in Chinese) that the site has been suspended for security reasons and listing the support contact.

#Why this CVE matters for shared-hosting operators specifically

Most CVE coverage assumes a homogeneous environment — "patch this one CMS." Shared-hosting operators don't have that luxury. Your customer base runs whatever software they want, in whatever language they prefer, with whatever level of technical literacy they have. CVE-2026-29014 is the kind of bug that's going to bite you regardless of what your own team patches, because the bug lives in customer accounts you can't see into without explicit policy.

The campaign currently exploiting CVE-2026-29014 is not particularly sophisticated. The shells are noisy. The lateral movement is heavy-handed. But the volume is enormous, because MetInfo's installed base is in the millions globally and the proprietor density is "small business with no IT staff." Every shared-hosting operator is going to find some MetInfo accounts compromised; the question is how fast.

#What Valtik does about this

If you operate shared hosting and the inventory problem above describes your environment exactly, Valtik can run the discovery scan for you. We bring the tooling to fingerprint every CMS in your customer base — MetInfo, but also Joomla, OpenCart, Magento 1.x, PrestaShop, and the long tail of niche CMSes that get installed by Chinese-, Russian-, Korean-, and Vietnamese-speaking customers. Output is a hosting-account-by-hosting-account inventory with risk score, recommended patch action, and a notification template in the customer's likely first language.

This is exactly the kind of audit that shared-hosting operators commission once a year and never regret. Book a scope call at valtikstudios.com/free-check. If you operate shared hosting, your inventory has gaps you don't know about, and the next CVE will go through one of them.

---

Sources cited:

• The Hacker News: "MetInfo CMS CVE-2026-29014 Exploited for Remote Code Execution Attacks" (May 5, 2026)
• VulnCheck Advisory VC-2026-029014 (May 5, 2026)
• MetInfo Project Security Bulletin (May 4, 2026, Simplified Chinese only)
• Internet Security Research Group / Let's Encrypt cross-reference of MetInfo footprint by ASN (Q1 2026)