A Caching Plugin on 70,000 WordPress Sites Has an Unauthenticated Code Execution Bug. If You Run WordPress for Yourself or a Client, Patch Today.
Wordfence disclosed CVE-2026-83627 on September 5: a critical, unauthenticated remote code execution vulnerability in Hummingbird Performance, a caching and page-speed plugin installed on roughly 70,000 WordPress sites. It carries a CVSS score of 9.8, the top of the scale, and it doesn't require a login to exploit. If you or a client runs WordPress with this plugin active, this is a today task, not a someday task.
How the bug actually works
Hummingbird writes a debug log for its page-caching module to wp-content/wphb-logs/page-caching-log.php, a file sitting directly inside the web-accessible uploads path. That's normally fine, because the plugin is supposed to write a protective <?php die(); ?> header at the top of the file before anything else touches it, which turns the file into a dead end for any browser that requests it directly.
The bug is in how that protection gets applied. The check guarding the header uses class_exists('Filesystem'), a plain string, when the actual class lives in a namespace as Hummingbird\Core\Filesystem. PHP's class_exists() resolves a bare string argument against the global namespace, so the check can never match the namespaced class it's actually looking for. The condition silently fails every time, which means the protective header never gets written when the log file is created during a normal front-end request.
Once that header is missing, a second function, get_cookies(), writes the raw name of any cookie matching the wphb_cache_ prefix into the now-unprotected log file without sanitizing it. Since cookie names are attacker-controlled, an unauthenticated visitor can set a cookie containing PHP code as its name, trigger a page-cache log write, and have that code land directly in a file the web server will execute. That's a full remote code execution path with no login required, built out of a namespace typo in a security check that was supposed to prevent exactly this.
Why a caching plugin is exactly the wrong place for this
Performance plugins are the ones people install once, configure, and forget. Nobody re-audits their caching plugin every quarter, because caching isn't where anyone expects a security problem to live. It's infrastructure, not a feature you interact with, and that's precisely why it's a good place for a serious bug to sit unnoticed. Hummingbird is developed by WPMU DEV, an established plugin publisher, and 70,000 active installs is a meaningful footprint. This isn't an obscure plugin from an abandoned repository. It's the kind of plugin that ends up on real production sites, including client sites a solo developer set up once and hasn't opened since.
The fix and why it should jump your queue
The patched version is 3.21.1, which resolves the namespace resolution issue so the protective header gets written correctly regardless of how the class-existence check evaluates. Every version up to and including 3.21.0 is affected. If you're running WordPress and you're not sure whether Hummingbird Performance is one of your active plugins, check now. If it is, update it before you do anything else today. A critical, unauthenticated, remotely exploitable code execution bug on a security scale that tops out at 10 is about as close to an emergency as WordPress security advisories get, and it should displace whatever else was on your list.
The broader lesson about the plugins nobody watches
The specific bug here is a one-line fix, but the pattern is worth sitting with. WordPress sites accumulate plugins for jobs nobody thinks of as security-relevant: caching, image optimization, SEO metadata, form handling. Those plugins often have broad filesystem or database access because their job requires it, and they get a fraction of the security review that a login form or a payment plugin gets, because nobody's threat-modeling their cache. If you maintain WordPress sites, even a handful for clients as side income, it's worth a periodic look specifically at the "boring" plugins: the ones that aren't user-facing, that you installed for performance or convenience, and that you haven't thought about since setup.
What I'd actually do
Check your active plugin list today, not this week. If Hummingbird Performance is on it, update to 3.21.1 immediately. Then set a recurring reminder, monthly is enough, to skim the changelog of every plugin you run for the word "security" or a CVE number, since WordPress security advisories move fast and most of us only hear about the ones that make it to a headline.
The honest caveat: I don't run WordPress for my own site, this one runs on Astro, so my stake in this specific bug is secondhand. But a meaningful share of solo operators either maintain a WordPress site themselves or manage one for a client as part of a services business, and for that group this isn't optional reading, it's an action item with a five-minute fix and a genuinely bad downside if you skip it.
Author
Lukas
@lukcombinator