10 min read

The WordPress security community is currently raising serious concerns over a newly discovered security vulnerability. Tracked as CVE-2026-3844, this is a critical arbitrary file upload vulnerability in the Breeze Cache plugin, with a CVSS v3.1 score of 9.8 out of 10. The flaw affects more than 400,000 WordPress websites and has already shown signs of active exploitation in the wild, making delayed patching a major security risk for affected sites.
This article provides a complete technical breakdown of CVE-2026-3844: what it is, how it works, which assets are at risk, what the fix is, and what additional defensive actions every WordPress site owner and security team should take immediately.
What is CVE-2026-3844?Link to heading

CVE-2026-3844 is an arbitrary file upload vulnerability found in the Breeze Cache plugin for WordPress, developed by Cloudways. The vulnerability is located in the fetch_gravatar_from_remote function within the class-breeze-cache-cronjobs.php file of the Breeze Cache plugin.
The vulnerable function was designed to fetch Gravatar profile images from a remote URL and store them locally in the WordPress uploads directory, a feature meant to improve page load performance by reducing external requests. However, the function performs no validation whatsoever on the file type or file content of what it downloads.
This critical oversight means an attacker who controls the source URL can instruct the server to fetch a PHP webshell, a malicious script disguised as an image, rather than a legitimate Gravatar. Once downloaded, the malicious file lands in a directory where the web server permits PHP execution. From that moment, the attacker has remote code execution (RCE) capabilities on the affected server.
Why is CVE-2026-3844 so dangerous?Link to heading
The danger of this vulnerability comes from three compounding factors:
- No authentication required. Any anonymous user on the internet can trigger the exploit. There is no login, no token, no user role required.
- No user interaction needed. The attack is fully automated and can be executed without any action from the site owner or administrator.
- Active exploitation is already happening. Public threat telemetry has recorded thousands of attack attempts in the days immediately following public disclosure. This is not a theoretical risk. Attackers are actively scanning and exploiting vulnerable sites right now.
The only precondition for exploitation is that the "Host Files Locally – Gravatars" option must be enabled in the Breeze plugin settings. Importantly, this option is disabled by default, meaning sites that have never touched this setting are not immediately vulnerable. However, any site where this feature has been turned on is at severe risk.
What assets are affected by CVE-2026-3844?Link to heading

Plugin versionsLink to heading
CVE-2026-3844 impacts every Breeze Cache release up to and including version 2.4.4. This covers the standard WordPress.org release as well as the Cloudways-managed cloudways:breeze build at version 2.1.4. Both fall below the patched release of version 2.4.5.
Scale of exposureLink to heading
Breeze Cache has more than 400,000 active WordPress installations worldwide. The plugin is widely used to speed up WordPress sites through page caching, file minification, CDN integration, and database cleanup. Its adoption across small business sites, e-commerce stores, and enterprise WordPress deployments makes this a high-value target for threat actors.
An affected asset in practical terms is any internet-facing WordPress site that meets two conditions:
- The site is running Breeze Cache version 2.4.4 or earlier.
- Websites become vulnerable when the “Host Files Locally – Gravatars” feature is turned on in the plugin configuration settings.
WordPress sites are almost always publicly accessible, and the Breeze plugin operates within the standard WordPress request lifecycle, meaning the vulnerable endpoint is reachable from anywhere on the internet without any special access.
Why these sites are high-value targetsLink to heading
A successful exploit against CVE-2026-3844 does not just deface a website. Once a webshell is in place on the server, an attacker can:
- Pivot into the WordPress database and access all stored data, including user credentials, customer information, and private content.
- Harvest passwords, API keys, and authentication tokens stored in configuration files.
- Install backdoors for persistent access even after the initial webshell is removed.
- Use the compromised server as a launchpad to deliver malware to site visitors or attack other systems.
This is why CVE-2026-3844 must be treated as an emergency, not a routine patch cycle item.
Are fixes available for CVE-2026-3844?Link to heading

Cloudways has released Breeze Cache version 2.4.5, which resolves the arbitrary file upload vulnerability. Upgrading to v2.4.5 or any later release is the primary recommended action for all site owners and hosting providers managing WordPress sites with Breeze installed.
Steps to patchLink to heading
- Log in to your WordPress admin dashboard.
- Navigate to Plugins → Installed Plugins.
- Locate Breeze – WordPress Cache Plugin in the list.
- Click Update Now if an update is available, or manually upload the 2.4.5 package from the WordPress plugin repository.
- Verify the update by confirming the plugin version displayed is 2.4.5 or higher.
Important: Do not rely solely on a central hosting dashboard or plugin management system to confirm the update. Verify the plugin version directly on each individual WordPress site, as configuration state can differ between instances.
Interim mitigations (If immediate upgrade is not possible)Link to heading
If a production environment cannot be patched immediately, the following mitigations reduce exposure:
- Turn off the “Host Files Locally - Gravatars” option in the Breeze Cache settings. This directly blocks the vulnerable code path. The site can continue operating with all other Breeze features intact.
- If the patch cannot be applied right away, disable the Breeze plugin completely as a temporary safeguard. This eliminates all risk from the plugin at the cost of its performance benefits.
These are interim measures only. Updating to version 2.4.5 is still the only permanent fix and should be done as soon as possible, especially since active exploitation is already happening.
Additional recommended actions after patchingLink to heading

Patching the plugin closes the vulnerability, but if exploitation has already occurred on a site, additional forensic and hardening steps are necessary. Even sites that patch before being compromised benefit from the following defensive measures.
Audit the WordPress uploads directoryLink to heading
Immediately inspect the /uploads/breeze/gravatars/ directory on your web server. Search for any files with the following extensions:
- .php
- .phtml
- .phar
The presence of any file with these extensions in this directory is a strong indicator of compromise. These files should be quarantined and analyzed immediately.
Review web server access logsLink to heading
Examine your web server access logs, particularly requests to admin-ajax.php, for entries containing fetch_gravatar_from_remote parameters. This is the specific request pattern used to trigger the vulnerability.
Pay close attention to the timestamp of any suspicious requests, then cross-reference with outbound connection logs from the web server around the same time. A successful exploit forces the server to make an outbound request to an attacker-controlled URL; unusual outbound connections are a secondary indicator of exploitation.
Restrict PHP execution in the uploads directoryLink to heading
At the web server level (Apache or Nginx), restrict PHP execution within the WordPress uploads directory. This is a defense-in-depth measure that would prevent webshell execution even if a malicious file were somehow uploaded. This configuration should be standard practice on all WordPress servers regardless of this specific vulnerability.
For Apache, add the following to your .htaccess or server configuration:
<Directory /var/www/html/wp-content/uploads>
php_flag engine off
</Directory>
For Nginx, add inside the relevant server {} block:
location ~* /wp-content/uploads/.*\.php$ {
deny all;
}
Apply WAF rulesLink to heading

If your infrastructure includes a Web Application Firewall (WAF), apply or enable rules that block remote-URL parameters in Gravatar-related endpoints. Cloudflare, Sucuri, and other WAF providers typically push signatures for high-profile CVEs within days of disclosure. Confirm that relevant rules are active and not in "log-only" mode.
Before attackers can exploit critical vulnerabilities like CVE-2026-3844, your website needs a stronger security layer capable of blocking malicious requests in real time. W7SFW is an advanced external WordPress firewall designed to stop dangerous exploit attempts, malicious uploads, brute-force attacks, and suspicious traffic before they ever reach WordPress or vulnerable plugins.
Activate W7SFW today to add an extra layer of protection for your WordPress website before the next critical vulnerability is exploited.
Rotate credentials after a confirmed compromiseLink to heading
If forensic investigation confirms that exploitation occurred before the patch was applied, rotate all credentials stored on the affected host. This includes:
- WordPress admin passwords
- Database credentials (update wp-config.php accordingly)
- API keys and tokens stored in plugin configuration or environment files
- SSH keys and hosting panel passwords
- Any third-party service credentials accessible from the server
A successful exploit grants the attacker read access to the entire WordPress installation. Assume all credentials on that server are compromised until rotation is complete.
ConclusionLink to heading
CVE-2026-3844 leaves very little room for hesitation. Every WordPress site running Breeze Cache version 2.4.4 or earlier with local Gravatar hosting enabled is potentially exposed.
The path forward is straightforward: update to Breeze Cache 2.4.5, disable the vulnerable feature if an immediate update is not possible, and audit your uploads directory for any signs of prior exploitation. If credentials were stored on the affected server, rotate them immediately. If a WAF is in place, verify that the relevant security rules are actively enforced.