Visual Composer CVE-2026-12227: CVSS 9.8, no login needed

CVE-2026-12227 is the kind of WordPress bug that does not need a phishing email or a logged-in victim. It needs a URL. The Visual Composer Website Builder plugin honors an attacker-supplied vcv-template parameter on ordinary front-end page loads, which lets an unauthenticated visitor pull arbitrary files off the server and execute PHP inside them. CVSS 9.8. A working proof of concept is already published on GitHub. If you run this plugin, the next ten minutes are for updating it.

What actually happened

The flaw is a classic local file inclusion with a modern delivery path. On affected versions, WordPress's template_include handling inside the plugin's page-template controller trusts the vcv-template request parameter and includes the file it names. No authentication, no nonce, no admin click — just a normal page request built with Visual Composer and a crafted query string. Public tracking records put it at CVSS 9.8 (CWE-98), affecting all versions up to and including 45.16.0, with the fix landing above that version. The CVE record was published September 24.

Here is the part that should change how you patch. Visual Composer's own changelog never names this vulnerability. The releases after 45.16.0 read like routine maintenance: 45.16.1 on July 23 fixed a vendor folder, 45.16.2 on September 9 fixed "a security vulnerability related to the user roles," and 45.16.3 on September 24 restricted Contributor role content overwrites. An unauthenticated remote-code-execution path is not mentioned in any of them. The plugin has 30,000+ active installations and the current stable release is 45.16.3.

Two things follow. One, the fix shipped quietly, so you may have been patched for weeks without knowing you were ever exposed. Two, publication plus a public PoC means anyone still on 45.16.0 or earlier is now in the window where scanning starts.

Why an unauthenticated LFI matters for your business

Update to 45.16.3 today, then assume nothing. LFI that reaches PHP execution is a full server compromise, not a defacement. Check your web server access logs for requests containing vcv-template, look for PHP files in wp-content/uploads, diff your plugin and theme directories against clean copies, and rotate database credentials and any API keys stored in wp-config.php. An unauthenticated bug leaves no failed-login trail to find — the logs are the only evidence you get.

Changelogs are marketing copy, not a security feed. You cannot decide whether to patch by reading what a vendor chose to write. Subscribe to a vulnerability feed keyed to your actual installed plugin list — Wordfence Intelligence and Patchstack both publish one — and treat the feed as the source of truth. We hit the same lesson this week with the Elementor CSRF bypass, which shipped a fix in 4.3.2 before any CVE existed.

A page builder with filesystem reach is an architecture decision. The reason this one is CVSS 9.8 rather than a 6 is that the plugin runs as PHP with the web user's full filesystem access, on the same box as everything else. When we build commerce sites, the marketing layer cannot read the order database or the payment credentials, because those live in a separate service with its own identity. That is not paranoia — it is the difference between "restore the CMS from backup" and "notify every customer."

Count your plugins, because that number is your patch load. Every plugin is an independent vendor with its own disclosure discipline, and as this one shows, that discipline varies. If a plugin is not carrying real weight on the site, removing it is the cheapest security work available.

Sources: WordPress.org plugin page and changelog, CVE-2026-12227 record.