Wordfence has documented sustained exploitation of two WordPress plugin flaws:

  • Super Forms, CVE-2026-14894, CVSS 9.8 — missing file type validation in the upload handler. Fixed in 6.3.314.
  • Elementor Pro, CVE-2026-32475 — an unauthenticated file upload bypass. Fixed in 4.2.2. We covered the flaw itself when it was disclosed.

Wordfence blocked more than 250,000 attempts against the first and more than 190,000 against the second: 440,000 combined.

What that number measures

It measures requests Wordfence blocked, on sites running Wordfence, over the reporting period.

It does not measure compromises. It does not measure vulnerable sites. It does not measure attacks on the far larger population of WordPress installations that do not run Wordfence at all, and it says nothing about what happened on those.

The reporting also does not separate scanning from successful exploitation — a distinction that matters enormously, because a single automated scanner sweeping a plugin path across a large host will generate tens of thousands of blocked requests without a single site falling over.

None of this is a criticism of Wordfence, which is reporting what it can see and is one of very few sources with any visibility here at all. It is a caution about the sentence "440,000 attacks" that is going to circulate this week, because that sentence will be read as 440,000 attempts on 440,000 targets, and it is not that.

The honest version: a lot of automated traffic, aimed at two known flaws, sustained over weeks, and nobody has published how many sites were actually taken.

The timeline is the part worth acting on

Super Forms exploitation began on 14 July 2026 and peaked at over 40,000 requests on 18 August. Elementor Pro attacks started on 19 August.

So the Super Forms campaign has been running for close to two months. That is long enough that "we patched when we heard about it" is not the same as "we were never exposed", and any site running the vulnerable version through July and August should be checked rather than assumed clean.

The mechanics

Both are the same class of flaw and both end in a PHP web shell.

Against Super Forms, attackers post Base64-encoded payloads to /wp-admin/admin-ajax.php. The upload handler did not validate file type, so a PHP file goes where an attachment was supposed to.

Against Elementor Pro, the bypass works on array validation, and the resulting PHP files land in /wp-content/uploads/elementor/forms/.

That second path is the useful detail. A PHP file inside an uploads directory is not ambiguous — nothing legitimate puts executable code there — and it is the single easiest thing to search for on a site you are worried about.

Ten distinct IP addresses are associated with each campaign.

Why it is always file upload

Unauthenticated file upload is the most reliable path to remote code execution in the WordPress ecosystem, and it recurs because of what these plugins are for.

A form builder exists to accept files from strangers. That is the product. Which means every one of them has an endpoint that takes attacker-controlled bytes and writes them to disk on the web server, and the entire security of the arrangement rests on validation code that a developer has to get right on every path, forever.

The two flaws here are a missing check and a bypassable one. Those are the only two options for how this fails.

What to do

  • Update Super Forms to 6.3.314 and Elementor Pro to 4.2.2. Both fixes exist.
  • Search your uploads directory for PHP files. Start with /wp-content/uploads/elementor/forms/ and then widen. Nothing legitimate needs to be there.
  • If you were running a vulnerable version at any point since 14 July, assume you were reached and look, rather than patching and closing the ticket.
  • Block PHP execution in the uploads directory at the web server. This is a configuration change that neutralises an entire class of flaw, including the next one, and most WordPress hosts do not do it.
  • Do not repeat "440,000 attacks" without the qualifier. It is a blocked-request count from one vendor.

What is not established

  • How many sites were successfully compromised. No figure has been published.
  • Whether the attempts were scanning or successful exploitation. The reporting does not separate them.
  • What the attackers did after a successful upload — account creation, data theft, full takeover. None is documented.
  • Whether exploitation is continuing now that patches are available.
  • How many vulnerable installations remain.