Breeze Cache Plugin Flaw Hits 400K WordPress Sites

Critical Breeze Cache Flaw (CVE-2026-3844) Puts 400,000 WordPress Sites at Risk

A missing six lines of validation code in a popular WordPress caching plugin has handed unauthenticated attackers the keys to 400,000 websites. Hackers are already exploiting it. A patch exists. The only question is whether site owners will apply it before the attackers find them.

Security researchers have a name for the category of vulnerability that CVE-2026-3844 belongs to: an unrestricted file upload flaw. The description is technically precise but emotionally inadequate. “Unrestricted file upload” sounds like an administrative inconvenience. What it means in practice is that an attacker — anyone on the internet, requiring no account, no password, no prior access of any kind — can place a file of their choosing on your web server. And if that file is a PHP web shell, they can then use it to execute any command they like on the machine hosting your website.

That is the reality of CVE-2026-3844: a critical-severity, unauthenticated arbitrary file upload vulnerability in the Breeze Cache plugin for WordPress, developed by Cloudways and installed on over 400,000 active websites. The flaw has a CVSS score of 9.8 out of 10 — the second-highest possible severity rating — and has been assigned a “critical” classification by every major vulnerability database that has reviewed it. Hackers are already exploiting it. Wordfence, the security firm whose firewall protects more than four million WordPress sites, has detected more than 170 exploitation attempts since the vulnerability entered public knowledge.

Cloudways has released a patch — version 2.4.5 of the plugin, released on April 21, 2026. But approximately 138,000 downloads of the patched version have occurred since release, against a total install base of more than 400,000. The implication is clear: hundreds of thousands of sites may still be running vulnerable versions, while a vulnerability with a 9.8 severity score is being actively weaponized.

Vulnerability Details at a Glance

Before examining the technical details, here is the complete profile of CVE-2026-3844:

The Root Cause: Six Missing Lines of Code in a Gravatar Function

The vulnerability was discovered by security researcher Hung Nguyen, who publishes under the alias “bashu.” The root cause is unambiguous and has been confirmed by Wordfence researchers at Defiant: missing file-type validation in the fetch_gravatar_from_remote() function, located in the file class-breeze-cache-cronjobs.php.

To understand the flaw, it helps to understand what the vulnerable feature does. Breeze Cache includes an optional feature called “Host Files Locally – Gravatars,” designed to improve website performance. Gravatars are the small profile avatar images associated with email addresses and displayed next to comments and author bylines on WordPress sites. By default, these images are loaded from Gravatar.com’s servers each time a page is served. The local hosting feature is an optimisation: instead of fetching the Gravatar from the remote server on every page load, the plugin downloads the image once and stores a local copy on the WordPress server.

The flaw is in the download step. The fetch_gravatar_from_remote() function retrieves a file from a remote URL and saves it to the server. In a correctly implemented version of this function, the code would: check the MIME type of the downloaded content to confirm it is actually an image; validate the file extension to ensure it is safe (.jpg, .png, .gif); and strip or reject any filename or extension that could be interpreted as executable code by the web server.

None of those checks exist in the vulnerable version. As SentinelOne’s technical analysis confirmed: “The function accepts remote file content without verifying” the file type, MIME type, or extension. The downloaded content is saved to the server’s Gravatar cache directory with whatever filename and extension it was served with — and if a web shell is served at the attacker-controlled URL with a .php extension, that web shell is saved to the target server’s web-accessible cache directory, ready to execute.

“The Breeze Cache plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the ‘fetch_gravatar_from_remote’ function in all versions up to and including 2.4.4. This makes it possible for unauthenticated attackers to upload arbitrary files on the affected site’s server which may make remote code execution possible.”

— Wordfence / Defiant official vulnerability disclosure, April 2026

How the Attack Works: A Step-by-Step Walkthrough

The exploitation path for CVE-2026-3844 is well-understood and has been documented by both Wordfence and SentinelOne. The attack requires no authentication, no special tools, and no prior knowledge of the target site other than its URL and plugin version:

The attack is rated as having no required authentication and no required user interaction — the two conditions that, combined, make file upload vulnerabilities at the top of the severity scale. An attacker does not need to trick an administrator into clicking a link, does not need to create an account, and does not need any inside knowledge of the target. They need only to identify that the site is running a vulnerable plugin version with the Gravatar feature enabled.

Scope and Exposure: Who Is Actually at Risk?

The 400,000 active installations figure is the number most widely reported — and the most likely to be misread. Not all 400,000 sites are equally exposed, and the actual number of critically vulnerable installations is likely lower, though still significant.

The critical qualifier: CVE-2026-3844 is only exploitable when the “Host Files Locally – Gravatars” option is enabled in the plugin settings. This option is not enabled by default. Sites that installed Breeze Cache and left the default settings in place are exposed to the unauthenticated file upload only if they have specifically navigated to the plugin settings and enabled this feature.

No data is publicly available on what percentage of the 400,000 installs have this feature enabled. The feature is primarily useful for high-traffic sites that want to reduce external API calls and improve page load speeds — a performance-conscious configuration choice rather than a casual default. Sites optimised for performance are the ones most likely to have enabled it. Given that Breeze Cache is developed by Cloudways — a managed WordPress hosting platform specifically focused on performance — a meaningful fraction of its user base may indeed have enabled local Gravatar hosting as part of their performance optimisation work.

Even at the most conservative estimate, however, tens of thousands of live, production WordPress websites are potentially exposed to a CVSS 9.8 unauthenticated remote code execution vulnerability that is currently being actively exploited. That is not a theoretical risk — it is an active emergency for site owners who have not yet patched.

Active Exploitation: What Wordfence Has Observed

Wordfence’s firewall — which is installed on more than four million WordPress sites — began detecting exploitation attempts targeting CVE-2026-3844 within days of the vulnerability becoming public knowledge. As of April 23, 2026, more than 170 distinct exploitation attempts had been logged against sites protected by Wordfence. This figure represents only the attacks against the subset of sites running Wordfence — the actual number of attempts against the broader install base of 400,000 sites is necessarily higher.

The exploitation pattern is consistent with automated scanning: attackers are using scripts to identify vulnerable sites at scale across the internet, rather than manually targeting specific high-value victims. Automated exploitation of WordPress vulnerabilities typically begins within days of a flaw entering public knowledge — sometimes within hours — and accelerates as the scripts are shared among threat actors.

The nature of what attackers do after achieving RCE through CVE-2026-3844 varies based on their goals. Common post-exploitation activities observed in similar WordPress RCE campaigns include: installing persistent PHP backdoors that survive plugin updates; harvesting database credentials from wp-config.php; redirecting site visitors to malicious or phishing pages; injecting SEO spam to redirect search traffic; enrolling the server in botnet infrastructure for DDoS or spam campaigns; and deploying ransomware or cryptomining payloads.

The WordPress Plugin Security Problem: Breeze Cache Is Not Alone

CVE-2026-3844 is a serious vulnerability. It is also, unfortunately, not an unusual one in the WordPress plugin ecosystem. In the same week that Breeze Cache’s flaw entered public knowledge, more than 1,300 internet-exposed Microsoft SharePoint servers were found to be vulnerable to a separate zero-day, and the SVG-based Magecart campaign against Magento stores was still actively running with no production patch available for PolyShell.

WordPress’s plugin ecosystem — comprising over 59,000 plugins in the official repository alone — is structurally challenging to keep secure. Plugin developers vary enormously in their security expertise and code review practices. Many plugins are maintained by small teams or individual developers who may not have dedicated security review processes. The sheer volume of plugin code makes comprehensive third-party auditing impossible at scale.

The specific class of vulnerability in CVE-2026-3844 — missing file-type validation — is one of the most consistently documented and most consistently preventable vulnerability types in web application security. The OWASP Top 10 has included it as a known risk category for over a decade. The fix, implemented correctly, requires a small number of additional lines of code: check that the downloaded content has a safe MIME type; verify the file extension is in an allowlist of safe image formats; reject any content that fails those checks. Cloudways implemented exactly these checks in version 2.4.5.

The fact that these checks were missing from the original implementation is not evidence of malice — it is evidence of the ordinary imperfection of software development under resource and time pressure, combined with the complexity of correctly implementing security validation for edge cases like remote file fetching. What matters now is not the root cause of the oversight, but the speed with which the affected 400,000 sites apply the available fix.

“Given the active exploitation status, website owners and admins who rely on Breeze Cache to boost performance are recommended to upgrade to the latest version of the plugin as soon as possible or temporarily disable it.”

— BleepingComputer / Wordfence advisory, April 2026

What to Do Right Now: Prioritised Mitigation Steps

For every site owner running Breeze Cache, the following actions should be taken immediately, in order of priority:

How to Check if Your Site Has Already Been Compromised

If your site was running a vulnerable version of Breeze Cache with local Gravatar hosting enabled before you applied the patch, you should assume potential compromise and investigate. The following checks can help determine whether attackers have already established a foothold.

Check the Gravatar cache directory. Navigate to wp-content/cache/breeze/gravatar/ (or the equivalent path on your server). Any file in this directory with an extension other than .jpg, .jpeg, .png, .gif, or .webp is suspicious. Any .php, .phtml, .phar, or .php5 file is a confirmed indicator of compromise and should be deleted and reported to your hosting provider immediately.

Review web server access logs. Search your access logs for POST requests made to files in the cache/breeze/gravatar/ path, or for direct HTTP GET requests to unexpected filenames in that directory. Requests to a .php file in the Gravatar cache that were not made by your legitimate users are a strong indicator of post-exploitation activity.

Run a WordPress malware scan. Tools such as Wordfence, Sucuri SiteCheck, or MalCare can scan your entire WordPress installation for known malware signatures, unauthorized file modifications, and suspicious code patterns. Wordfence specifically has updated its signature database to detect files uploaded via CVE-2026-3844 exploits.

Change database credentials and secret keys. If your site was compromised, assume that the contents of wp-config.php — including your database username, password, and WordPress secret keys — have been exfiltrated. Rotate all of these credentials, regenerate your WordPress secret keys using the official generator, and monitor for unauthorized database activity.

A Critical Flaw, a Ready Patch, and a Closing Window

CVE-2026-3844 is a serious vulnerability, but it is also one of the most straightforward to address: the patch is available, the fix works, and the prerequisite for exploitation (the Gravatar local hosting feature) is not enabled by default. This is not the scenario of an unpatched zero-day for which no remediation exists. It is the scenario of a patched critical vulnerability being actively exploited against a user base that has not yet updated.

The window between “patch available” and “most sites updated” is the most dangerous period in the lifecycle of any widely-deployed software vulnerability. Attackers know that many site owners check for plugin updates weekly or monthly rather than daily — and they are using that window aggressively. Every hour that a Breeze Cache site remains on version 2.4.4 with local Gravatar hosting enabled is an hour during which automated exploitation scripts are scanning for it.

The recommendation is unambiguous: update Breeze Cache to version 2.4.5 now. If you cannot update immediately, disable the local Gravatar feature now. If you have already been running the vulnerable configuration, investigate for signs of compromise before you do anything else. The patch is free, takes thirty seconds to apply, and eliminates the entire attack surface. There is no reason to wait.