Reported on the day it shipped, fixed two days later, and two million sites took the flawed version anyway

Everybody moved fast and it did not help

Elementor is a page builder for WordPress running on more than ten million sites. Version 4.3.0 was released on 22 September 2026. Patchstack, acting on a report from a bug hunter using the name Saggre, reported a cross site request forgery flaw in it to Elementor the same day. Version 4.3.2, which fixes it, shipped on 24 September.

That is a two day turnaround on a same day report. By any reasonable standard nobody in this story was slow.

And in those two days, the two affected releases, 4.3.0 and 4.3.1, reached more than two million sites.

That is the whole finding. Two million installations of a defect that existed for roughly forty eight hours, which works out at something like forty thousand sites an hour, or seven hundred a minute. Twenty per cent of the plugin's install base took a version that was only ever alive for two days.

What that does not establish. It does not establish that two million sites were attacked, or that any were: exploitation needs a logged in administrator to follow a crafted link, and nobody has published evidence of that happening. It does not establish that automatic updates are a bad idea; the same machinery is now delivering the fix at the same speed, and the alternative is millions of sites sitting on old versions indefinitely. It does not establish negligence anywhere, and the article is not making that argument. And the two million figure is Patchstack's, derived from install telemetry, so it is an estimate rather than a census.

The check that reads a string the attacker writes

WordPress protects cookie authenticated REST API requests with a nonce. It is the only cross site request forgery protection that layer has, which makes it an unusually consequential thing to switch off.

In 4.3.0 and 4.3.1, and only those two releases, Elementor's Editor Events module disables that validation whenever the literal string elementor/v1/events/ appears anywhere in the request URI.

The request URI includes the query string. The query string is written by whoever composes the link.

So an attacker takes any REST request they want an administrator's browser to make, appends the magic string as a query parameter, and the nonce check does not run. Patchstack's description of the consequence is the one to remember: any REST request can opt itself out of that protection by appending a harmless looking parameter.

The demonstrated impact is creating a new administrator account, which is site takeover. The attacker needs a logged in administrator to open the link, which is the only thing standing between the flaw and full compromise.

The flaw carries a CVSS of 8.8 and, at the time of writing, no CVE identifier. That is worth a line on its own. A flaw on two million sites, fixed and publicly described, with no identifier attached to it, will not appear in most vulnerability feeds, will not match a version comparison in most scanners, and will not turn up in any report that counts CVEs.

It is also worth asking why only two releases are affected, because the answer is reassuring in one way and not in another. The Editor Events module and its URI check appear to have been introduced in 4.3.0, which is the release that also added a set of new capabilities to the plugin. So the flaw arrived with a feature rather than having sat undetected for years.

That is the good news: this was caught almost immediately by somebody looking at new code. The less good news is the general case it illustrates. New code is where new flaws are, new code is what a rapid release cycle produces continuously, and an install base that updates automatically is subscribed to all of it.

Distribution speed is a security property in both directions

The usual argument about automatic updates treats speed as unambiguously good: a fix reaches everybody before an attacker can use the details. This episode is the same property observed in the other direction.

The defect in 4.3.0 was not exploited in the two days it existed, as far as anybody has said. But the plugin ecosystem moved two million copies of it in that time, and it would have moved them just as fast if the defect had been found in six weeks rather than six hours.

That has a consequence for how to think about the risk. The exposure window of a fast moving component is not the time between the flaw shipping and the fix shipping. It is that window multiplied by how quickly the component propagates, and for something like this the multiplier is enormous.

It also means the thing that limited this incident was not the update machinery. It was the researcher reporting on day zero and the vendor turning a fix around in forty eight hours. Take either of those away and the same two million sites are exposed for weeks.

What the published figures support, and what they do not. Install counts are Patchstack's estimates from telemetry; the rates are ours.

Figure	What it establishes	What it does not
More than 2 million installs of 4.3.0 or 4.3.1	The update machinery moved a defective release at scale in about 48 hours	That any of those sites were attacked
Two day window	Exposure was short in calendar terms	That exposure was small, because propagation is the multiplier
CVSS 8.8	The impact is site takeover if exploited	That exploitation is easy: it needs a logged in administrator to follow a link
No CVE assigned	Nothing to match in a version feed	That the flaw is minor or disputed
Fixed in 4.3.2	The current version is not affected	That sites on 4.3.0 or 4.3.1 have updated yet

One detail in that table deserves drawing out, because it is the only number in the story that is still moving. Two million sites took the flawed versions. Nobody has published how many have since taken 4.3.2. The same telemetry that produced the first figure could produce the second, and until it does, the honest statement about the current exposure is that it is unknown and shrinking.

What to do about it

The question this leaves

It is tempting to file this as another WordPress plugin story and move on, and the install numbers make that a mistake. Ten million sites is a larger estate than most national infrastructures, updated automatically, with a change reaching a fifth of it inside two days.

Everything worked as designed here. The researcher reported immediately. The vendor fixed it in two days. The update system distributed both the problem and the solution efficiently and without asking anybody. The outcome is still that two million sites ran a site takeover flaw over a weekend.

So the question for anything in your estate that updates itself: you know how long it takes a fix to arrive, because that is the number vendors advertise. Do you know how long it takes a defect to arrive, and have you ever treated that as the same measurement?