Loading the post…
On 19 August 2026, an ops lead at a provider with a few thousand WordPress sites opened a new advisory. Elementor Pro had a critical flaw, CVE-2026-32475, rated 9.0 and exploitable with no login and no click from anyone on the site. Elementor shipped the fix, version 4.2.2, the same day.
Customers got a notice. Auto-updates did what they could.
By the textbook, the problem was solved.
Across the Imunify threat intelligence network, the first exploit requests arrived the next morning. Traffic peaked on day six, at 431k requests in a single day. On day 12, more than 2.1 million of the 2.6 million sites that were on an affected version at disclosure still hadn't moved.
84% of sites were exposed through the bulk of the campaign.
Developers often fix WordPress plugin vulnerabilities within days of disclosure, and the fixes reach sites over weeks.
On a single site, the update closes the flaw.
Across a fleet, some sites always update late, so the question for WordPress hosting security is what covers them in the meantime, and who can do it.
A WordPress plugin vulnerability is a flaw in a plugin's code that lets a request do something the plugin never meant to allow, usually without an account on the site.
Plugins are where nearly every WordPress vulnerability lives. In 2024, 7,966 new vulnerabilities were found in the WordPress ecosystem. Plugins accounted for 96% of them, and WordPress core for seven. About 33% of the flaws had no patch when they were publicly disclosed.
The wordpress.org directory lists 78,000 plugins from thousands of independent authors, with no shared code review between them. A fix exists only when the author ships one. It reaches a site only when someone installs it.
The flaws themselves are often small. In Elementor Pro's Forms module, the code that validated an upload and the code that stored it disagreed about an empty file slot, so a second file part skipped the extension blocklist and landed as a .php file in a public folder.
In Ultra Addons for Contact Form 7, the PDF Generator rebuilt a PHP object from form data without checking it. That let a visitor aim Contact Form 7's cleanup code at files of their choosing.
Vulnerability databases answer "is my plugin on the list?" well. They can't say how long a listed flaw stays exploitable across thousands of sites, and that is the number a host pays for.
Elementor Pro's disclosure gave us a clean measurement, because the exploit leaves a fingerprint. The vulnerable code renames every upload to a 13-character, time-based string. In the two months before the advisory, our telemetry recorded no requests for names like that ending in .php in Elementor's forms directory.
Here is how the two weeks after the vulnerability disclosure ran, as published in the full Elementor Pro telemetry, two weeks after disclosure.
The second curve is patch uptake. Sites on the fixed release grew from 100k on 20 August to 415k on 31 August, roughly four times as many in under two weeks.
By WordPress standards, that is fast. The 415k on the fixed release are about 16% of the 2.6 million sites exposed at disclosure, which leaves 84%, more than 2.1 million sites, still on an affected version.
Put the curves side by side. Exploit traffic peaked on day six. By day 12, the exposed population had shrunk by about 16%. The bulk of the attack ran inside the window where patching had barely started.
Security teams call the first half of this measurement mean time to exploit: the gap between disclosure and attacks in the wild. Our figure comes from one campaign, so it is a data point, not a mean. The shape is typical of an n-day vulnerability, a flaw that is public and fixed but still unpatched on most of the sites that run it.
The Verizon 2025 Data Breach Investigations Report found the same gap for the edge-device vulnerabilities it tracked. The median time from disclosure to mass exploitation was zero days, and the median time to patch was 32.
Automated mass exploitation campaigns do not wait for anyone's patch cycle.
WordPress automatic updates are the obvious answer, but they cover less than most people assume. Four gaps keep the uptake curve flat.
When WordPress fixed the WordPress 7.0.3 login flaw, CVE-2026-64638, on 6 August 2026, the fix went to every branch back to 4.7. Automated probing still reached sites across the fleet, because a share of them had auto-updates switched off or owners who had stopped checking.
Keeping plugins and themes updated is the top security challenge for 65% of WordPress agencies, and for 75% of those with 100+ sites. Among agencies with 100+ sites, 45% still update manually, one site at a time. Among hosting providers, 53% name outdated or vulnerable software their top security challenge, driven by WordPress plugins and themes, and 35% count security incidents among their biggest support drains.
Keep auto-updates on wherever they can run. Customer education won't change the shape of that uptake curve.
Who can act depends on where a request is stopped.
A security plugin sees a request only after WordPress has loaded, and it can't see a request that goes around WordPress. The 7.1.4 updater flaw , which a plugin firewall never sees, was one of those, because its request went straight to an unpacked copy of WordPress in wp-content/upgrade/.
A server-level web application firewall (WAF) sees every request before PHP starts. The operating system decides how far a compromise can reach once something does run. The full path is in where a request goes before WordPress sees it.
Each layer has an owner, and each owner can do different things before the update lands.
| Party | Controls | Can do inside the window | Can't do |
|---|---|---|---|
| Plugin developer | The plugin's code | Ship the fix | Install it on anyone's site |
| Site owner | One site's WordPress | Apply the update, remove unused plugins, turn on auto-updates | Act on a flaw with no patch, or cover a site nobody logs in to |
| Agency on managed hosting | Client sites' WordPress | Bulk-update client sites, choose the host | Change anything on the server |
| Hosting provider or self-managed agency | The server | Apply WAF rules to every site at once, run PHP runtime protection, isolate accounts, patch end-of-life PHP, push bulk updates | Change the plugin's code |
A web application firewall for WordPress, run at the server, is the one control in that table that reaches every site on the day a rule ships. The host is the only party that can act on all of them at once.
It is also the party that pays for the gap, in cleanup tickets and in churn, since 19% of providers lose customers to security incidents.
For web hosting security, that makes the exposure window a server-side job. Agencies running their own servers hold the same levers, which is why CloudLinux and Imunify360 for agencies running their own servers covers the same stack.
A virtual patch is a web application firewall rule that recognizes the request an exploit sends and blocks it before the vulnerable code runs, so the site is shielded while it waits for the real update.
The term comes from network security, where it applies to any application behind a firewall.
In WordPress, a virtual patch is written against one plugin, theme, or core flaw, such as the double file upload Elementor Pro mishandled, or the object Ultra Addons rebuilt from form data. WAF rules of this kind sit in front of the site and leave its code as it is.
Managed virtual patching for WordPress is the host delivering those rules fleet-wide, through automatic ruleset updates, with nothing for the site owner to install or configure. On Imunify360 servers, a rule is enforced at the server-level WAF, in the Imunify Security plugin for WordPress at the application layer, or at both, depending on the flaw.
A virtual patch has four limits:
One layer needs no CVE at all. In the 30 days before the Elementor Pro advisory, Imunify360's webshell-access rules and Proactive Defense, its real-time PHP security module, blocked hundreds of access and execution attempts in Elementor's forms directory, with Proactive Defense running in Kill Mode. Those were probes for other webshells. Nothing matched this exploit's filename pattern in that window.
On 20 August alone, the webshell-access layer blocked 3.6 million such requests across the network.
These six steps are for the person who controls the server. Five are levers only the host has. The sixth is the update, which still has to happen.
The post-compromise check is the same for any upload flaw. After a disclosure, look in the folder the exploit writes to for scripts that do not belong there. The advisory names the folder and the filename pattern. An empty result does not prove the site is clean, because an attacker can rename or delete the file.
On Imunify360 servers, the malware scanner already checks and cleans that folder automatically.
| Layer | What it stops | Who does it |
|---|---|---|
| Server-level WAF in blocking mode | Exploit requests for known flaws, including ones that bypass WordPress | Host |
| WordPress virtual patching | Plugin, theme, and core exploits at the application layer | Host |
| Real-time PHP behavior blocking, in a mode that terminates the script | Malicious PHP behavior with no rule yet | Host |
| Patched builds of end-of-life PHP | Known flaws in end-of-life PHP | Host |
| Account isolation | Cross-account reach after a compromise | Host |
| Plugin updates | The flaw itself | Site owner, or the host with bulk tooling |
Exploitation can start the day a flaw is disclosed. Verizon's 2025 DBIR put the median time from disclosure to mass exploitation at zero days for the edge-device vulnerabilities it tracked, against five days across all known-exploited vulnerabilities. WordPress plugins show the same pattern. In the Elementor Pro case, CVE-2026-32475 went public on 19 August 2026 and exploit requests reached servers the next morning. The campaign peaked on day six, at 431k requests in a day, and was still probing two weeks later.
Partly. Core security releases install in the background by default. Plugin auto-updates are opt-in, one plugin at a time, and premium plugins update only with an active license. A major-version jump often doesn't happen automatically, which is why 84% of exposed Elementor Pro sites hadn't moved after twelve days.
It is the host delivering WAF rules that block exploits for specific plugin, theme, and core flaws to every site on the server, through automatic ruleset updates. The site owner installs nothing. It covers the window before the update and doesn't fix the flaw itself.
The developer writes the fix, and the site owner applies it. The host is the only party that can protect every site at once while updates lag, with server-level WAF rules, PHP runtime protection, account isolation, and patched end-of-life PHP.
No. A virtual patch blocks the exploit request, and the vulnerable code stays on the site until the update replaces it. It also leaves alone any file planted before the rule arrived, so run the update and the post-disclosure check either way.
Back on 19 August, the ops lead had two weeks ahead. By 2 September, the 84% was either a cleanup queue or a set of log entries for requests that never reached PHP. The difference comes down to three settings, the server-level WAF in blocking mode, the Imunify Security plugin enabled across the server, and Proactive Defense in Kill Mode. Check all three on one server today. The product mechanics and a trial are with WAF for WordPress, included with Imunify360.
Nikolay Galov
Comments