Elementor Pro CVE-2026-32475: The Patch Started the Clock

If you run a portfolio of client sites and any of them use the paid version of the most widely installed WordPress page builder, this is a this-week job rather than a this-quarter job. The short version: a critical file-upload flaw in the Form widget allows an unauthenticated attacker to write a PHP file to the server and then execute it. The fix shipped on 19 August 2026 in version 4.2.2. Attacks began immediately afterwards, and a large share of installations still had not updated at the start of September.

The detail worth your attention is not the severity adjective. It is the sequence — patch first, exploitation second — because that sequence is what determines how much time a portfolio owner actually has, and almost nobody prices it.

What is the actual defect?

It is a small logic error with a large consequence, and it is worth understanding because the shape recurs. According to the advisory from the CNA that assigned the identifier, the plugin's Form module handles a File Upload field in two separate passes: an extension check, and the step that moves the file into place. Those two passes treat an empty file entry differently. Submit a single upload field as an array with two parts — an empty slot first, then a PHP payload — and the validation pass stops at the empty entry while the processing pass skips it and carries on to the second part. The payload is written to a public directory without ever being checked, and can then be requested directly.

No login is required at any point. That is what moves it from "a bug in a plugin" to "site takeover", and it is why the remediation window matters more than the classification.

Is it 9.8 or 9.0?

Both numbers are in circulation, and it is worth being precise because a security lead who checks will find the discrepancy in about a minute. The identifier is CVE-2026-32475. Widely republished coverage gives the score as 9.8. The advisory from the assigning authority gives 9.0, and the vector published on the CVE record rates attack complexity as High, which is what produces 9.0 rather than 9.8. The national vulnerability database record carries no score of its own at all — its own assessment is listed as not yet provided.

So the honest statement is: the only score published by the party that assigned the identifier is 9.0, one widely quoted figure of 9.8 does not match it, and no independent assessment has been published. All three of those things are true simultaneously, which is normal and not a scandal.

Operationally it changes nothing. Both numbers are in the critical band, the defect is unauthenticated remote code execution either way, and the decision — patch now, then check whether you were hit — is identical at 9.0 and at 9.8. The reason to get the number right is not the number. It is that quoting a figure you did not check is how a client learns to discount everything else you tell them.

Am I affected?

The vulnerable component is the paid plugin, at all versions up to and including 4.2.1, and the exposure runs through the Form widget's File Upload field. The fix is 4.2.2.

Be careful with the population figures, because they are being repeated in a form that makes them mean more than they do. The reported figures are: over 6 million active installations of the paid plugin; approximately two-thirds of the free plugin's 10 million installations running a vulnerable version as of 4 September. Those are two different populations, and the security firm that produced the exploitation data says plainly that it is unclear how many installations are actually affected. "Roughly two-thirds are unpatched" is defensible. "Two-thirds of affected sites are exposed" is not, and the second version is the one that will get repeated back to you.

For your own estate the number that matters is the one you can produce: how many of your sites run the paid plugin, and what version each of them is on today.

How do I check for compromise right now?

The indicator is unusually cheap to check, which is the single most useful thing about this disclosure. A successful attack writes a PHP file into the directory that stores uploaded form submissions — /wp-content/uploads/elementor/forms/. That directory should never contain a PHP file. If it does, treat the site as compromised rather than as suspicious.

The follow-up steps are the ordinary ones and they matter as much: review request logs for activity against the admin AJAX endpoint around and after 19 August, and if you find any evidence of compromise, sweep for persistence rather than deleting the one file you found. An attacker who achieved code execution three weeks ago did not leave a single artifact behind.

Do the check on every site running the plugin, not only on the ones you consider important. The scan that found your estate did not consult your client list.

Why did exploitation start after the patch, not before?

Because for a large class of vulnerabilities the patch is the disclosure. A published fix to open code is a description of the defect: the diff shows exactly which check was missing and exactly where. Turning that into a working exploit is a much smaller job than finding the flaw was.

This is why "we patch monthly" is a policy that quietly assumes attackers work on the same schedule. In this case the interval between the fix landing and attacks beginning was reported as immediate, and the number of blocked attempts against one vendor's customer base passed 190,000. Your patch window is not measured from when you heard about it. It is measured from when the fix went public, and if you first heard about this from a news article in September, the clock had already been running for two weeks.

What does this actually cost a portfolio owner?

Not the patching. Applying an update to a site you know about is a small, well-understood task, and if that were the whole job nobody would be exposed two weeks later.

The cost is in the two steps around it. First, inventory: knowing which of your sites run the component, at which version, without opening each one. Second, verification: producing evidence, per site, that the update was applied and the indicator was checked — because the client question that follows a public exploitation report is not "did you patch" but "how do you know". Teams that can answer both in an afternoon are not more diligent than the ones that cannot. They have a list, and the others have a memory.

If you are quoting remediation to a client, quote those two steps honestly. We are not going to publish a per-site figure, because it depends entirely on how your estate is built, and a made-up number would be worth less than none.

Is this a one-off, or a pattern?

A pattern, and a narrow enough one to be useful. The recurring shape is a file upload accepted through a public form field, where the code that validates and the code that stores make different assumptions about the same input. Contact forms, application forms, quote requests and support widgets are the features clients ask for constantly and the features that carry the highest-consequence defects in this category — because a public form is, by definition, reachable without credentials.

The practical consequence for delivery work: any form field that accepts a file deserves the same scrutiny as a login page, wherever it comes from. Ask what validates the file, where the file lands, whether that location is web-accessible, and whether the code that stores it re-checks what the code that validated it concluded.

Does a hosted or managed version solve it?

Not by itself, and this is the assumption worth testing in your own estate. A managed hosting arrangement can shorten the patch cycle, add a filtering layer in front, and take the update decision off your plate — all genuinely valuable. What it does not do is change the code. The same defect exists in the same component; the question is only who applies the fix, how fast, and whether they tell you.

We wrote that out at length in the patch-chain question to ask about any platform: not "is it open source" but who is obliged to fix the engine, on what timescale, and what happens to your estate while that plays out.

What if the engine isn't yours to patch?

Then your control is contractual and procedural rather than technical, and the questions change accordingly. Who executes the patch chain for the engine? On what cadence, and is it published? How are customers notified — before, during or after? Can you verify a version yourself, or are you taking someone's word for it? What does the platform emit that your monitoring can consume? Is any of that in the agreement, or only on a marketing page?

Those are the same questions we set out in the piece on where a zero-trust programme runs out of road at the content layer, and they apply to every platform including ours. You will not find a sentence in this article claiming that our own upload handling is safe. That would be an unverifiable control claim published by the party it flatters — the exact thing this article is telling you to interrogate. Ask us the questions above; the honest limits of what we can answer are set out in where WebinOne is the wrong choice and our security review page.

What should be on the list by Friday?

Five things, in order. Produce the inventory: every site, the plugin, the version. Update everything below 4.2.2. Check the uploads directory on every one of them for a PHP file that should not exist. For anything that shows the indicator, assume compromise and hunt for persistence rather than cleaning one file. And write down what you did, per site, with a date — because that record is what turns the next disclosure from a scramble into a task.

The fifth item is the one that gets skipped and the one that pays. Every portfolio owner will do the first four again within the year, for some other component.

Where does this leave the estate you run?

With a decision that has nothing to do with ideology. Plugin ecosystems are enormously productive and that is why everyone uses them; the cost is that your remediation obligations are set by the release schedule of code you did not write. That is a legitimate trade with an honest price, and it is worth deciding deliberately rather than by accumulation.

If you are weighing the platform layer under a portfolio, the evaluation questions are in our checklist for evaluating a white-label DXP, and the delivery mechanics — environments, roles, handover — are in how integrators run delivery on WebinOne. For a portfolio move, scoping and pricing a portfolio migration is the relevant piece, the platform overview covers the environment, partner terms are on the partner programme page, and if you would rather ask a person, talk to us.