CVE-2026-3844: Cloudways Just Shipped a 9.8 CVSS to 400,000 WordPress Sites. Wordfence Logged 170 Active Exploits Before the Patch Landed. Here's the Hunt.

Patrick Duggan
1 day ago
6 min read

May 7, 2026 · DugganUSA LLC

The Cloudways Breeze Cache plugin — installed on more than four hundred thousand WordPress sites — has an unauthenticated remote-code-execution vulnerability with a CVSS score of 9.8. The flaw lives in the fetch_gravatar_from_remote function in all versions through 2.4.4: missing file-type validation on a remote-fetch path that an unauthenticated attacker can trigger to upload arbitrary executable content into the site's filesystem.

Wordfence logged more than one hundred seventy active exploitation attempts in the wild before this post went up. Our exploit-harvester captured four public proof-of-concept repositories within hours of the first one landing. Cloudways is a DigitalOcean-owned managed-hosting platform, which means the Breeze plugin shipped from a vendor whose customer base trusts them to ship a curated WordPress experience. The 9.8 lives one step above where most curation lives.

If you operate any WordPress installation that has the Breeze plugin enabled, the action sequence is patch tonight, hunt back thirty days. The detection-rule indicators we already have in our index are below.

What CVE-2026-3844 Actually Is

The Breeze plugin caches WordPress pages, optimizes assets, and (the relevant feature) fetches user avatars from external services through a function named fetch_gravatar_from_remote. That function performs an HTTP fetch against a remote URL provided by the request and writes the response body to local disk inside the WordPress filesystem. In all Breeze versions up to and including 2.4.4, the function does not validate the file type of the response.

The exploitation path: an unauthenticated request triggers the gravatar-fetch routine against an attacker-controlled URL that returns a PHP web shell. Breeze writes the response to a local path inside the WordPress site. The attacker then requests the written PHP file through the web server, which executes it. From there, the attacker has whatever privilege the WordPress PHP runtime has — typically www-data on Linux hosts, but on shared-hosting or Cloudways-managed WordPress that often translates to a level of access that allows pivoting to other sites on the same shared instance.

The Wordfence team's counter shows 170+ exploitation attempts already observed across their network. Wordfence's coverage is a partial sample of the WordPress fleet — meaning the real attempt count, across the four-hundred-thousand-site population, is materially higher.

The IOCs In Our Feed

We pulled four public PoC repositories via the exploit-harvester:

im-hanzou/CVE-2026-3844
tausifzaman/CVE-2026-3844
0xgh057r3c0n/CVE-2026-3844
sahmsec/CVE-2026-3844

The harvester also captured detection rules for the exploitation pattern:

Request paths matching /wp-content/plugins/breeze/readme.txt (a probe pattern attackers use to fingerprint the plugin's presence)
Request bodies containing the string system immediately followed by an open parenthesis (a marker of attempts to invoke shell calls inside the uploaded PHP)
Referer header anomalies (the exploit chain typically uses crafted Referer headers to bypass naive request-validation filters)

All indicators are in our public STIX feed at analytics.dugganusa.com/api/v1/stix-feed under the indicator type. Free tier is twenty-five queries per day — enough to pull the CVE-2026-3844 set without paying us.

The Hunt Tonight

If you operate any WordPress installation:

Step one: identify whether Breeze is installed. The presence of /wp-content/plugins/breeze/ in your filesystem confirms it. The presence of readme.txt inside that directory will reveal the installed version. Anything 2.4.4 or earlier is vulnerable. The patch is in version 2.4.5 — install it tonight.

Step two: hunt back through Apache or nginx logs. Pull the past thirty days of access logs filtered to:

Any request to /wp-content/plugins/breeze/readme.txt (probe activity — not necessarily exploitation but a strong fingerprinting signal)
Any POST request to a Breeze-related endpoint where the request body or query string contains references to the standard set of PHP shell-execution function names (the four-letter ones for command spawning and the four-letter one for code evaluation)
Any request with a Referer header that does not match a legitimate referrer pattern from your own site or known search engines

A grep one-liner against your nginx access log:

grep -E "/wp-content/plugins/breeze|fetch_gravatar_from_remote" /var/log/nginx/access.log.* | awk '{print $1, $4, $7}' | sort | uniq -c | sort -rn | head -50

If you see clusters of requests from a small set of IPs hitting Breeze-related paths repeatedly, those IPs are the candidates for compromise-or-attempt. Cross-reference against your normal WordPress admin source IPs to filter false positives.

Step three: scan the WordPress filesystem for unauthorized PHP files. The exploitation primitive is "write arbitrary content via Breeze's fetch routine." The post-exploitation artifact is a PHP file in a location WordPress will execute. Look for:

PHP files in paths that should not contain executable code: wp-content/uploads/, wp-content/cache/, wp-content/plugins/breeze/cache/, or any unusual subdirectory under wp-content/
PHP files with timestamps that don't match the WordPress install or plugin update cycle
PHP files containing standard web-shell markers: base64-encoded payloads, dynamic-evaluation calls against request-superglobal parameters, shell-spawning calls against user-controlled input

A find command tuned for the typical exploitation-output paths:

find /var/www -type f -name ".php" -newermt "30 days ago" $ -path "/wp-content/uploads/" -o -path "/wp-content/cache/*" $ 2>/dev/null

For the web-shell marker scan, the practical pattern set you want to grep for includes: base64_decode in combination with a PHP request superglobal, dynamic-evaluation calls against request superglobals, and the assert function called against request superglobals. Your existing WordPress security plugin (Wordfence, Sucuri, etc.) has a built-in scan that catches these — run it tonight.

Step four: rotate credentials if anything turns up. The exploit primitive includes filesystem write at WordPress runtime privilege. That means: any database credential WordPress holds, any API key in wp-config.php or environment variables, any auth token cached in the WordPress filesystem. If you find evidence of compromise, treat all of those as exposed and rotate. The site itself can be re-installed; the credentials it held cannot be un-leaked.

What Cloudways Customers Should Be Doing

Cloudways is a managed-WordPress-hosting platform owned by DigitalOcean. They ship the Breeze plugin as part of their default WordPress curation. If you are a Cloudways customer, the patch should propagate through Cloudways's own update mechanism — but the propagation lag varies. The fact that Wordfence observed 170+ exploitation attempts before the patch reached the customer fleet suggests the propagation lag is meaningful and the customer-side update should be initiated manually rather than waited on.

Cloudways customers should:

Verify the installed Breeze version on every WordPress instance under management
Manually trigger the plugin update to 2.4.5 (or later) tonight, not at the next scheduled maintenance window
Run the hunt-back steps above against each instance's access logs
Open a support ticket with Cloudways requesting confirmation of patch deployment timeline across the customer fleet

If you are reading this from a Cloudways or DigitalOcean security team email forward, we appreciate the attention and stand by to clarify any indicator above.

Why This One Hits Different

Most WordPress plugin CVEs in 2026 affect plugins with installation counts in the thousands or tens of thousands. CVE-2026-3844 affects four hundred thousand sites, which is two orders of magnitude above the typical advisory's blast radius. The unauthenticated nature of the exploit means there is no credential boundary to cross; the CVSS-9.8 nature means there is no significant attack-complexity hurdle. The fact that the vulnerability is in a function that legitimately performs a remote fetch means defensive web-application firewalls will see the requests as fitting the function's normal traffic shape, not as anomalous probes.

The right mental model: this is not a typical WordPress plugin CVE. This is a content-platform supply-chain exposure of the same shape as a managed-package compromise on npm or PyPI, with the additional feature that the platform's customers cannot easily switch off the vulnerable component. Breeze is a load-bearing performance plugin for many of the sites that have it installed.

Summary For The Person Reading This At 11pm

Three actions, in order, tonight:

Patch every Breeze installation under your control to 2.4.5 or later. Manual update; do not wait on the platform.
Hunt back thirty days for Breeze-path probe activity and unauthorized PHP files in WordPress upload and cache directories.
Rotate any credentials that WordPress had access to if the hunt turns up evidence of exploitation. The exploit primitive includes filesystem write at runtime privilege; assume credentials touched by the runtime are exposed if any successful exploitation occurred.

If you find anything in your hunt and want a cross-check, we are at [email protected].

Receipts

Wordfence detection report: 170+ exploitation attempts observed across the Wordfence-protected fleet
Affected installation count: 400,000+ WordPress sites running Breeze (per Cloudways and the WordPress.org plugin directory)
Vulnerable versions: all Breeze through and including 2.4.4
Patched version: 2.4.5
Vulnerable function: fetch_gravatar_from_remote
CVSS: 9.8
Public PoC repositories captured by our exploit-harvester:
Detection-rule indicators in our public STIX feed under indicator type
Our STIX feed: analytics.dugganusa.com/api/v1/stix-feed
SecurityAffairs coverage: securityaffairs.com (CVE-2026-3844 advisory and exploitation reporting)
Cloudways: managed-WordPress-hosting platform, owned by DigitalOcean