CVE-2026-3844 was rated CVSS 9.8 (Critical) this week — an unauthenticated arbitrary file upload flaw in the Breeze cache plugin (maintained by Cloudways), installed on 400,000+ WordPress sites. BleepingComputer reports active in-the-wild exploitation. In one sentence: with no credentials, an attacker drops a .php file on your server and gets a webshell — an enterprise-ending breach.
The mechanism is simple, which is why it is dangerous. The flaw lives in fetch_gravatar_from_remote: when the Host Files Locally – Gravatars add-on is enabled, the plugin fetches remote avatars and stores them locally with no extension/MIME validation. Attack chain: unauthenticated attacker → manipulate the fetch source and filename → write malicious PHP into a web-accessible directory → call it for RCE. No login, no user interaction; a PoC is public on GitHub. The only precondition is the local-Gravatar option being on (not default).
Affected versions: Breeze ≤ 2.4.4; Cloudways patched it in 2.4.5. WordPress powers 40%+ of the web, cache plugins are near-standard, and Breeze is common on Cloudways/DigitalOcean stacks. The disclose-to-exploit window compressed as usual. For any agency running client WordPress sites, this is a today-level action.
Next: how to tell if you have the option on, patch vs mitigations, and which IOCs to hunt.
Technical Detail: Vuln Type & Attack Path
- Type: unauthenticated arbitrary file upload → RCE.
- Root cause: fetch_gravatar_from_remote lacks file-type/extension validation.
- Trigger: Host Files Locally – Gravatars add-on enabled.
- Auth: none.
- PoC: public.
Quick mitigation (Nginx: block PHP execution in upload dirs):
location ~* /wp-content/(uploads|cache)/.*\.php$ {
deny all;
return 403;
}find /var/www/*/wp-content/{uploads,cache} -name '*.php' -mtime -14 -printImmediate Actions for Three Audiences
- Sysadmins: upgrade Breeze to 2.4.5 now; if you cannot, disable Host Files Locally – Gravatars and block PHP execution in uploads/cache; add a WAF rule for abnormal Gravatar requests.
- Developers: scan uploads/cache for .php added in the last 14 days; check access logs; rotate potentially leaked keys and admin passwords.
- Agencies / consultants: send a client advisory today. The perfect moment to turn security care into a maintenance retainer.
Patch vs Mitigation
| Scenario | Immediate patch | Mitigation if you cannot patch now |
|---|---|---|
| Can update now | Upgrade Breeze to 2.4.5 | — |
| Cannot update yet | — | Disable Host Files Locally – Gravatars |
| Host layer | — | Disable PHP execution in uploads/cache |
| Edge layer | — | WAF block unauth Gravatar fetches; restrict writable dirs |
| Aftermath | — | Scan for webshells; rotate keys and admin passwords |
IOCs & Threat Intel
- Unexpected .php files in wp-content/uploads or cache.
- Abnormal POST/GET to Gravatar endpoints with external URL params.
- Repeated requests to a newly created .php path (webshell interaction).
- Unfamiliar wp-cron tasks or new admin accounts.
What They Won't Tell You
- Only non-default option affected sounds safe, but many managed sites already turned local Gravatar hosting on for speed — verify in settings.
- The patch only closes the function. If a webshell is planted, upgrading does not remove the backdoor — do file auditing and key rotation.
The Bigger Trend
The disclose to patch to exploit window keeps compressing to hours. For WordPress, the real risk is never core — it is the install-and-forget third-party plugins. The era of waiting for a patch window is over; what is left is auto-update plus active auditing.
FAQ
My site does not have that Gravatar option on — do I still need to update?
Yes. It is off by default, but many managed hosts enable it for performance, and you cannot guarantee it will not be flipped on later. Upgrading to 2.4.5 is near-zero cost.
Am I safe after upgrading to 2.4.5?
The patch closes the hole but does not remove a webshell planted before the upgrade. Add a file audit and rotate keys and admin passwords.
I am not on WordPress — is this relevant?
The principle generalizes: any feature that fetches a remote file and stores it locally without type validation can become a file-upload flaw. In Laravel, validate MIME and extension and keep writable dirs out of the web root.
How do I know if I have been breached?
Scan uploads/cache for .php added in 14 days, correlate with access logs, and check for unknown admin accounts or wp-cron tasks.
My Take
The mainstream says non-default option, limited impact. I disagree — because it is non-default and assumed off, nobody checks a switch they think is off. The real lesson is that cache/performance plugins are treated as harmless and never inventoried. For a studio like ScriptWalker running many client WordPress sites, keep a central ledger of each site's plugins, versions, and auto-update status, so when a CVE drops you scan every site and blast an advisory in 30 minutes. That see-all-client-assets capability is the most valuable selling point of a maintenance retainer.
Sources
- Primary: NVD — CVE-2026-3844
- Primary: Breeze plugin page (WordPress.org)
- Primary: CVE-2026-3844 PoC (GitHub)
- Third-party: BleepingComputer report
- Third-party: SentinelOne vulnerability database