A cache plugin becomes a webshell dropper
A critical vulnerability in the Breeze Cache plugin, a performance optimisation tool for WordPress built and maintained by cloud hosting provider Cloudways, is under active exploitation. Tracked as CVE-2026-3844, the flaw carries a CVSS score of 9.8 and allows an unauthenticated attacker to upload arbitrary files to the server by abusing the plugin's remote Gravatar-fetching feature. The root cause is straightforward: the fetch_gravatar_from_remote function fetches a remote image file without validating what type of file it actually receives. An attacker does not need to authenticate. They do not need to be a user of the site at all.
An attacker who can write an arbitrary PHP file to a predictable location within the web root can execute arbitrary code on the server. From there, the compromise is limited only by the privileges the web server process holds. Database credentials, session tokens, stored personal information, payment integrations: anything the application can reach, the attacker can reach.
Breeze Cache has over 400,000 active installations. Cloudways shipped a patched version within a short window of disclosure. That part of the story is relatively good. The problem is that a plugin with this installation base being actively exploited within days of disclosure reveals something about how WordPress environments are actually managed in practice.
This is not an isolated event
Breeze Cache is not a plugin with one bad release. WPScan's published vulnerability history for the plugin shows a stream of access control and authorisation issues across its version history: missing authorisation in multiple versions, cross-site scripting in administrator-level accounts, and a separate authorisation bypass affecting the plugin's REST API endpoint (CVE-2025-13864) disclosed earlier this year. Each of those earlier issues was patched. Each required site administrators to update before the fix applied.
The WordPress plugin ecosystem operates on a trust model that is structurally difficult to secure. Plugins are often written by small teams or individuals, reviewed by the WordPress.org security team only selectively, and updated at the discretion of whoever installs them. There is no mandatory security baseline for plugin publication. There is no automatic patch deployment in most environments. Plugin acquisitions happen without triggering any formal code review; the EssentialPlugin supply chain compromise identified in April 2026 illustrates the extreme end of this, where a six-figure acquisition was used as a vehicle to plant a backdoor across more than 30 plugins, with the injected code remaining undetected for months.
The practical gap in most organisations running WordPress is not malicious intent. It is the absence of any structured process for knowing what plugins are installed, what version they are running, who maintains them, and what their track record looks like.
The audit gap
Most organisations engage a developer to build a WordPress site and then treat it as infrastructure: something that runs in the background until it breaks. Plugin updates are often deferred because updating can break theme compatibility. Security tooling is often limited to a commercial security plugin that scans for known malware signatures, which is useful but falls well short of a review of what is actually installed and whether each component's security posture is acceptable.
A structured WordPress security audit covers different ground. At the plugin layer, it asks: what is installed, what does each plugin actually do, who maintains it, what does its public CVE and disclosure history look like, and does the site actually need it. A plugin with a recurring pattern of authorisation failures is a different risk profile than one with a single patched disclosure. Plugins that have been abandoned by their developers, with no updates for 18 months or more and no response to disclosed vulnerabilities, represent a category of risk that no amount of patching resolves, because there is no patch coming.
At the hosting layer, the audit asks whether PHP execution is disabled in directories where arbitrary file uploads could land. The web server configuration that prevents PHP from executing inside the uploads directory is not a default setting on most shared or managed hosting environments. It is a straightforward nginx or Apache directive that materially reduces the impact of an arbitrary file upload vulnerability. That it is not standard practice is an indictment of how plugin vulnerabilities interact with default hosting configurations.
At the data layer, the audit asks what personal information the site holds, how it is stored, and whether the site's privacy posture is consistent with the privacy policy it presents to users and its obligations under the Privacy Act 1988 (Cth). Many organisations running WordPress sites have never mapped the data flow between their plugins, their database, and their third-party integrations. That mapping matters when a breach assessment has to be completed in hours.
Build your organsation out of the risk
For some functions commonly implemented via WordPress plugins, the appropriate remediation is not to find a better plugin. It is to implement the function outside WordPress entirely, or to evaluate whether WordPress remains the right platform for what the site has become.
Caching functionality, which is the category Breeze Cache belongs to, is an area where server-side configuration through nginx FastCGI cache, Varnish, or CDN-layer caching via Cloudflare achieves the same outcome without placing a plugin with file system access and outbound network requests into the WordPress process. The Gravatar feature that introduced CVE-2026-3844 is not a core caching function. It is a peripheral optimisation that proxies an external asset fetch through the server. Handling remote resource fetching inside a caching plugin created that attack surface. A caching layer that lives entirely outside WordPress does not make that trade-off.
For organisations whose WordPress sites have grown beyond simple content delivery into platforms handling transactions, memberships, or sensitive data, that question is worth asking explicitly: is WordPress still the right tool, or has it become the path of least resistance maintained by accumulated inertia? That is not a question with a universal answer, but it is one a structured technical and legal review can actually address.
Getting visibility before an incident forces the issue
The organisations that handle WordPress compromises well are not necessarily the ones with the most sophisticated security tooling. They are the ones that know what their site holds, have a tested response process, and can answer the NDB assessment questions quickly because the groundwork was already done.
Artificer Cyber conducts WordPress security audits covering the plugin inventory and lifecycle, hosting configuration, PHP execution controls, data mapping, and privacy posture; Artificer Legal contributes legal input on whether the site's current configuration creates exposure under the Privacy Act 1988 (Cth). For organisations managing WordPress sites that handle personal information, that kind of review is more useful before the call comes in than after. If that is relevant to your situation, reach out here.
Threat actors don't pause while you find a firm.
Artificer Cyber maintains active readiness across DFIR, legal privilege, and threat intelligence. When something happens, we're already briefed — and we can be engaged within the hour.