Hackers Are Exploiting WordPress Plugins Right Now. Your Site Might Be Next.

Three serious vulnerabilities in widely used WordPress plugins were disclosed in the space of about seven weeks this summer. Wordfence reports two of them under active attack right now. All three end with a stranger running their own code on the server, and all three live in code the site owner never wrote and can't read. That last part is the whole story.

Key fact: Between the first week of July and August 20, 2026, Super Forms, Elementor Pro and All-in-One WP Migration each shipped a fix for a flaw that leads to remote code execution. Two of the three run on millions of sites.

We build on custom code, not WordPress, and we have for years. That's a position, and this summer is a clear example of why we hold it. But it's worth being precise about what actually happened before getting to what we'd do about it.

What happened to Super Forms?

An attacker could upload a PHP file to a site running Super Forms without ever logging in. Attackers did.

Key fact: CVE-2026-14894 is an unauthenticated arbitrary file upload in Super Forms versions up to and including 6.3.313. Wordfence, which assigned the CVE, rates it 9.8 out of 10; Patchstack scores it a full 10.

The mechanism is mundane, which is what makes it dangerous. The plugin's form submission handler took a base64-encoded file from the request and wrote it to disk under whatever filename the sender chose, with no check on the type. That handler was exposed through an AJAX action anyone on the internet could call. Per Wordfence's code analysis, its only guard was a nonce, and the plugin offered a second public action that would mint one for you, which reduces the whole attack to two unauthenticated requests. The patch commit adds exactly the missing checks.

Super Forms is sold directly by its developer rather than listed on wordpress.org, so there's no official install count; Wordfence estimates around 13,000 active installations. The vendor fixed it in 6.3.314 in the first week of July, and Wordfence published the details on July 9.

Then the exploitation started. Wordfence says it saw the first attacks on July 14. In its September 3 writeup it reports blocking more than 250,000 exploit attempts against sites it protects, with the heaviest activity between August 18 and 25. That's the figure for Super Forms alone. You'll see 440,000 quoted in some coverage; that number adds the Elementor Pro attempts below to it. A public proof-of-concept script was posted to GitHub a week after disclosure.

What happened to Elementor Pro?

The same class of bug, in a plugin with a far larger footprint.

Key fact: CVE-2026-32475 is an unauthenticated file upload leading to remote code execution in Elementor Pro versions up to 4.2.1, fixed in 4.2.2 on August 19, 2026. Wordfence reports it under active exploitation from the day it was disclosed.

This one comes from the Forms module's file upload field. Wordfence and WPScan both describe the same root cause: the upload validation routine used return where it should have used continue, so when the first file in a multi-file field was empty, the extension and type checks were skipped for every file after it. Send an empty file first and a PHP script second, and the script lands on the server.

Not every Elementor Pro site is exposed. Wordfence and Patchstack both say the site needs a published page with a Form widget that has a file upload field not marked required, which is the field's default. Elementor's own notice to subscribers, as quoted by BleepingComputer, drew the line narrower, at forms with the multiple-file option switched on. The two haven't been reconciled publicly, and nobody has published how many sites meet either condition.

The severity depends on who you ask, and the honest answer is to say so. Patchstack, which assigned the CVE, rates it 9.0. Wordfence and WPScan both rate it 9.8. The National Vulnerability Database hasn't published its own score for any of the three flaws in this article and lists all of them as deferred, which is its own small commentary on how many WordPress CVEs there are to get through.

Wordfence estimates Elementor Pro at roughly 6 million active installations. That's the paid plugin, not the free Elementor builder, which is a separate plugin with a separate and larger user base. In its September 2 report, Wordfence reports more than 190,000 blocked exploit attempts since disclosure, concentrated in the first four days. Public exploit code followed quickly: a proof-of-concept on GitHub two days after disclosure, and a Nuclei scanner template a week after that.

One more detail worth sitting with. Elementor's Pro changelog for 4.2.2 describes the fix as "Improved code security enforcement in Form widget." No CVE, no severity, no word that attackers were already using it. If you were reading release notes to decide whether an update was urgent, you'd have had no way to know.

What happened to All-in-One WP Migration?

A backup plugin running on more than 5 million sites carries a flaw that ends in remote code execution, and there's public proof-of-concept code for it.

Key fact: CVE-2026-19949 is a second-order SQL injection in All-in-One WP Migration versions up to and including 7.109, rated 8.8 by Wordfence and fixed in 7.110 on August 20, 2026.

This one is more involved, and the details matter because they show how far an attacker can get from a very small opening. Per Wordfence's technical writeup, the payload is planted through WordPress's trackback feature, which anyone can use. It sits harmlessly in the database until an administrator runs a routine export and import with the plugin, which is what the plugin is for. During that import, a flawed regular expression misreads a backslash at the end of the planted string, the injected SQL runs, and the plugin's secret key leaks out through the public comments API. With that key, the attacker can drive the plugin's own import function and load a crafted archive carrying a malicious must-use plugin. At that point they're running code as the web server.

This one is rated high rather than critical, and the chain needs an administrator to run an import before it fires. Unlike the other two, no primary source has confirmed exploitation in the wild as of this writing, and it isn't in CISA's Known Exploited Vulnerabilities catalogue. Public proof-of-concept repositories started appearing on GitHub in the first week of September, about ten days after disclosure.

The wordpress.org listing puts active installations at 5 million, which is the directory's rounded bucket rather than an exact count. SecurityWeek, reading the directory's version statistics, estimated that only about 35 percent of installations had updated to 7.110 as of September 3. That's their arithmetic, not a measured figure, but it points at the part of this that matters most.

What do the three have in common?

Three different plugins, three different bugs, one cause. And it isn't carelessness by any one developer.

Key fact: Every one of these flaws lives in third-party code, runs with the full privileges of the site, and was reachable by a visitor who never logged in.

That's the structure of WordPress. The core is a small part of what a real business site runs. The forms, the page builder, the backups, the SEO, the caching, the galleries: each is a plugin, written by a different team, updated on a different schedule, and granted the same access to your database and file system as WordPress itself. The WordPress sites that come to us for migration usually carry twenty or more. You didn't write any of that code, you can't audit it, and when one of the teams makes a mistake with a return statement, it's your site that gets a web shell.

The second thing they share is that the fix depended entirely on the site owner noticing. All three vendors patched quickly, within days of being told. The exposure comes from the gap between the patch existing and the patch being applied, and on WordPress that gap is measured in months, not hours. Elementor's changelog called it improved security enforcement. ServMask, the maker of All-in-One WP Migration, has no security advisory page at all; its changelog line for 7.110 thanks the researcher and describes the fix as handling values ending in a backslash. If you weren't reading Wordfence's blog, you weren't told.

This is one of the seven signs a business has outgrown WordPress we wrote about earlier this year, and this summer turned it from a maintenance headache into the headline.

Why does custom code change the equation?

Because a custom site has none of the moving parts these three flaws live in. That deserves to be exact rather than a slogan.

Key fact: A site built from code you own has no plugin marketplace, no anonymous AJAX endpoints you didn't write, and no upload handlers waiting to be called by a stranger. The attack surface isn't smaller. For this class of flaw, it's absent.

Every site we build is custom code on a modern framework, server-rendered and shipped as static pages wherever a page can be static. There's no PHP admin surface exposed to the internet. Forms post to an API we wrote, with validation we wrote, that stores files where we decided they go. If a form field needs to accept an upload, it accepts the types we list and nothing else, and that decision is in a file we can point to. When something needs fixing, one team fixes it, and it doesn't wait on a vendor's changelog to tell you it happened.

We won't pretend custom code has no bugs. It does. The difference is scope and accountability. A custom site has a few thousand lines that one team is responsible for, not a few hundred thousand across thirty vendors with no shared obligation to you. That's why we don't build on WordPress, and it's the objection we hear most often from businesses considering us: custom code sounds riskier. This summer is a good time to look at where the actual risk has been.

There's a performance argument too, and it's the same argument. A site that carries thirty plugins carries their scripts, their styles and their database queries on every page load. Our builds ship only what the page needs, which is why we can hold every one of them to a 90 or better on Google's mobile Lighthouse test before it goes live. Fewer moving parts is safer and faster for the same reason.

What should a business on WordPress do this week?

There's a short list, and it's worth doing today even if a rebuild is a longer conversation.

Key fact: Update Super Forms to 6.3.314 or later, Elementor Pro to 4.2.2 or later, and All-in-One WP Migration to 7.110 or later. Do it today, not on the next maintenance cycle.

Then:

1. Check whether you're already compromised. For the two upload flaws, look in your uploads directory for PHP files that shouldn't be there. Wordfence's advisories list the specific paths attackers have been using. If you find one, the plugin update alone won't remove it.
2. Remove every plugin you don't actively use. A deactivated plugin is still code on your server. Each one you delete is one fewer team whose mistake can become yours.
3. Turn on automatic updates for the plugins you keep, and accept that this trades one risk for another. Automatic updates close the exposure gap, and they also mean an update you didn't review can change your site at 3 a.m.
4. Get a second opinion on the whole stack. We run a free audit that tests the live site and hands back an interactive dashboard within a few minutes, including which plugins are loading on every page and what they cost you in speed. It's also a plain inventory of how much third-party code you're actually running.

If the list feels long, that's the point. Maintaining a WordPress site properly is a real job, and most small businesses are doing it in the gaps.

Is a rebuild the right answer for every business?

No, and we'd rather say that than sell you one.

Key fact: A brochure site with five pages, no forms and no logins carries very little of this risk, and a rebuild would be spending money to solve a problem you don't have.

The businesses this summer should worry are the ones with forms that accept files, page builders on every page, membership or client areas, e-commerce, or anything that stores customer data. Those are the sites where a plugin's mistake becomes a breach notification. If that's you and you're in Cincinnati or Northern Kentucky, book a call and we'll tell you honestly whether a migration to custom code is worth it for your site. Sometimes the answer is a maintenance plan and a shorter plugin list. Sometimes it's a rebuild. We'll tell you which, and why.

Frequently asked questions

Which WordPress plugins had serious vulnerabilities in summer 2026?

Super Forms (CVE-2026-14894, critical, fixed in 6.3.314), Elementor Pro (CVE-2026-32475, critical, fixed in 4.2.2) and All-in-One WP Migration (CVE-2026-19949, high, fixed in 7.110). Wordfence reports the first two as actively exploited. The third has public proof-of-concept code but no confirmed exploitation as of this writing.

How do I know if my WordPress site was hacked through a plugin?

Look for PHP files in your uploads directory, new administrator accounts you didn't create, unexpected must-use plugins in the mu-plugins folder, and outbound traffic or redirects you didn't set up. A security scanner such as Wordfence or Patchstack will flag the known indicators for these specific flaws. If you find anything, updating the plugin isn't enough; the site needs to be cleaned.

Does custom code mean a site can never be hacked?

No. It means the site runs only code its builders wrote and are accountable for, with no third-party plugin ecosystem attached. That removes the category of flaw described in this article, where a stranger's code runs with full site privileges. It doesn't remove the need to build carefully.

Are these vulnerabilities in WordPress itself?

No. All three are in plugins. WordPress core was not the flaw in any of them. The point is that a working WordPress business site is mostly plugins, and plugins are where the majority of WordPress security problems live.

Sources

• CVE Program record and NVD entry for CVE-2026-14894; Wordfence, Attackers Actively Exploiting Critical Vulnerability in Super Forms Plugin, September 3, 2026; Patchstack database entry; Super Forms changelog.
• CVE Program record and NVD entry for CVE-2026-32475; Patchstack, Critical Unauthenticated File Upload to RCE in Elementor Pro; Wordfence, advisory of August 20 and exploitation report of September 2, 2026; WPScan entry; Elementor Pro changelog, Pro tab; BleepingComputer, Critical Elementor Pro bug exposes WordPress sites to RCE attacks, August 20, 2026, for Elementor's subscriber notice; ProjectDiscovery Nuclei template, August 26, 2026.
• CVE Program record and NVD entry for CVE-2026-19949; Wordfence, 5 Million WordPress Sites Affected by SQL Injection Vulnerability in All-in-One WP Migration, September 1, 2026; Patchstack database entry; wordpress.org plugin listing; SecurityWeek, Over 3 Million WordPress Sites Affected by Migration Plugin Vulnerability.
• CISA Known Exploited Vulnerabilities catalogue, checked September 8, 2026: none of the three CVEs is listed.