Visual Composer CVE-2026-12227: Are You on 45.16.1+?

CVE-2026-12227 lets an unauthenticated attacker make the Visual Composer Website Builder plugin include and run files on your server. It affects every version up to and including 45.16.0, and it’s rated CVSS 9.8.^[1] The fix is version 45.16.1, which shipped on July 23. We recommend going straight to the current 45.16.3.^[1][3]

The catch is that the fix arrived two months before anyone said it was a security fix. The 45.16.1 changelog line only mentions a vendor folder, and the advisory went public on September 23.^[2][3] Proof-of-concept code is already public.^[6] If you run Visual Composer and haven’t touched it since July, check it today.

TL;DR: What to do right now

1. Check the Visual Composer version on every site. Anything at 45.16.0 or lower is vulnerable.^[1]
2. Update to 45.16.3. It includes the July fix and two later security fixes from September.^[3]
3. If you can’t update today, deactivate the plugin until you can, and check how your pages render.
4. Look for signs of compromise: PHP files in wp-content/uploads, admins you don’t recognise, and vcv-template in your access logs.
5. Agencies: check the whole fleet. About one in five installs is on a branch that is definitely vulnerable.^[4]

What CVE-2026-12227 does

The bug is a local file inclusion (LFI) flaw in how the plugin handles the vcv-template parameter.^[1] An attacker can point that parameter at a file on the server, and PHP runs whatever code that file contains. Wordfence lists the results as bypassing access controls, reading sensitive data, or running code.^[1]

Why uploads make it worse

LFI on its own can only run files that are already on the server. The advisory spells out when that becomes full code execution:

images and other “safe” file types can be uploaded and included

Wordfence Intelligence ^[1]

In practice, that means any feature that lets a stranger put a file on your server. Contact forms with attachments, registration forms with avatars, and quote or job-application forms are all candidates. A file that passes an “images only” check can still contain PHP. If your site accepts uploads from visitors, treat this as more urgent, not less.

The timeline

Nothing in the 45.16.1 changelog tells you it closed a critical hole.^[3] Anyone who skips updates that look cosmetic, or who pins page builders to avoid layout breakage, had no reason to take it. That’s the group at risk now.

How many sites are still exposed?

WordPress.org publishes a rough version breakdown for every plugin. On September 27, Visual Composer’s looked like this:^[4]

So at least 21% of installs sit on a branch where every release is affected. The 45.16 figure doesn’t split out 45.16.0, so the true number is higher. We haven’t seen a report of exploitation in the wild, and the CVE isn’t in CISA’s Known Exploited Vulnerabilities catalog.^[6] With public exploit code and no login needed, we wouldn’t count on that lasting.

How to check your sites

1. Check the version

Run this from the site root. The plugin’s slug is visualcomposer.^[3][7]

wp plugin get visualcomposer --field=version
# vulnerable: 45.16.0 and lower
wp plugin update visualcomposer

In wp-admin, the Plugins screen shows the same number.

2. Look for PHP where it doesn’t belong

WordPress stores uploads as media, not code. A PHP file in the uploads folder is a red flag whatever caused it.

find wp-content/uploads -type f \
  \( -name '*.php' -o -name '*.phtml' \)
find wp-content -type f -name '*.php' \
  -newermt '2026-07-01' | head -50

The second command lists PHP files changed since July 1. Plugin and theme updates will show up there, so compare against what you know you installed.

3. Check administrators

wp user list --role=administrator \
  --fields=ID,user_login,user_email,user_registered

Remove any administrator nobody on your team created, then rotate the real admins’ passwords.

4. Search the access logs

The advisory doesn’t publish indicators of compromise.^[1] The parameter name is a reasonable thing to grep for. It only catches requests that put it in the URL, not in a POST body, so an empty result proves nothing. The log path is an example; use your server’s.

LOG=/var/log/nginx/access.log
grep -i 'vcv-template' "$LOG" | grep -v ' 404 '

5. Agencies: check the whole fleet

Put your WP-CLI aliases (one per line, like @client1) in sites.txt. Sites without the plugin print an error you can ignore.

while read -r site; do
  echo "== $site"
  wp "$site" plugin get visualcomposer \
    --field=version < /dev/null
done < sites.txt

Look hardest at sites where plugin updates are pinned or turned off. Those are the likeliest to still be on 45.15 or 45.10.

The same bug class, twice in one week

This is the second file-inclusion flaw we’ve written about this week. The first was in WordPress core itself; see our CVE-2026-87902 checklist.^[8] Both turn “include a file” into “run a file”. In both, what is already on the server decides how bad it gets. Our Elementor CVE-2026-62062 write-up covers a different page-builder bug from the same few days.

Zero Spam doesn’t patch Visual Composer, and it won’t clean up a compromised site. What it does is filter spam and malicious submissions on your comments, registrations and forms, through the free WordPress plugin or the API. That cuts down the junk that reaches the places where strangers can hand your site a file. If that helps, start on the free Explorer plan; code ZEROSPAM20 takes 20% off a paid license.^[9]

FAQ

About Ben Marshall

Full-stack Developer & Engineering Manager

Ben Marshall is a full-stack developer and engineering manager who loves building solid software and helping teams do their best work. He’s equal parts builder and coach—focused on practical architecture, clean implementation, and making collaboration easier (and faster) for everyone.

• WordPress.org