The WordPress webshell wave, 2024–2026: what the data shows

WordPress runs 40.7% of all websites and 58.9% of sites whose CMS is known (W3Techs, checked 4 September 2026 — the two numbers are routinely conflated, so it is worth naming which one you mean). That share is why the file-upload bug in a form plugin is, from a hosting operator’s chair, an infrastructure problem rather than a customer problem — and why it landed on the desks of operators who had just lost their scanner, as we covered in what CXS operators should do next .

This article sets out what is actually sourced about the 2024–2026 backdoor wave: the campaigns, the file-level indicators, the scale figures with their dates, and — importantly — the cases that argue against our own product category.

The vulnerability supply, in numbers that carry a year

Patchstack’s annual series is the cleanest count of what enters the ecosystem.

In the 2025 data, 1,966 of those (17%) were high severity, a 113% year-on-year rise, and the split was 91% plugins, 9% themes, six in core (Patchstack 2026 ).

Wordfence’s 2024 annual report , published 8 April 2025, counted 8,223 disclosed vulnerabilities for 2024 (+68%), 96% of them in plugins, with roughly 35% still unpatched. The detail that matters most for this article: arbitrary file upload was the most common high-threat vulnerability type, and the second most-detected malware family in Wordfence’s data was “a generalized obfuscated backdoor”, found on 78,500 sites.

Two caveats on that series. Wordfence has published no annual report for 2025 or 2026 — the format was replaced by quarterlies, and because the Q1 and Q2 2025 editions were never issued, no full-year 2025 total exists and none can be reconstructed by summing. And Patchstack’s 2024 edition page carries a contaminated header that repeats the 2025 edition’s intro text; anyone scraping the top of that URL will attribute 2024 figures to the 2023 report.

Speed is the part patching cannot fix

Patchstack measured a weighted median time to first exploitation of five hours, with 45% of exploitation occurring within 24 hours of disclosure (Patchstack 2026 ). Against that, look at when exploitation actually began for four well-documented cases:

And the population that never patches is not small. Imunify360 measured that 84% of 2.6 million Elementor Pro sites were still unpatched two weeks after disclosure — roughly 2.1 million sites still vulnerable as of 31 August 2026 (Imunify360 blog ).

Patching remains the correct fix, and nothing below argues otherwise. But “patch faster” is not an instruction a hosting operator can execute on 2.1 million third-party sites, and exploitation that starts before the advisory cannot be outrun by patching at all. That gap is the space a host-level detection layer occupies.

What the telemetry says, and what it does not

Firewall vendors publish large blocked-attempt figures. Here are four, with their windows:

• wp2shell (WordPress core, CVE-2026-63030 and CVE-2026-60137) — over 11 million blocked attempts from 17 July 2026 (Wordfence ).
• Super Forms — over 250,000 from 14 July 2026 (Wordfence ).
• Elementor Pro — over 190,000 from 19 August 2026 (Wordfence ).
• Ninja Forms File Upload — over 118,600 from 6 April 2026 (Wordfence ).

Imunify360 separately logged 3.6 million webshell-access requests in a single day (20 August 2026) plus 757,000 exploit-fingerprint requests over twelve days for Elementor Pro (Imunify360 ).

These are attempts, not compromises, and that distinction is not a technicality. Wordfence says so itself in the wp2shell write-up: despite the eleven million blocked attempts, “we have not observed such a surge” in actual compromises. F5 Labs, analysing the same campaign, is blunter still — its sensors “did not observe a web shell being deployed in the captured activity.” Wordfence also notes the counts reflect only customers on a specific premium firewall rule, a small percentage of its user base.

Treat these numbers as what they are: attempts against one vendor’s customer base, measured with that vendor’s instrumentation. Anyone presenting eleven million blocked attempts as eleven million hacked sites is telling you something false.

The counting problem cuts both ways. SOCRadar’s analysis of the 2026 WP-SHELLSTORM exploit kit gives conversion figures that are refreshingly unflattering: Breeze Cache, 45,000 targets producing about 17,000 shells; Joomla JCE, 560,000 targets producing 77 (SOCRadar ). Mass scanning is cheap; landing a shell is not uniform.

The backdoor prevalence figure, and its date

The most quoted statistic in this field comes from Sucuri’s 2023 Hacked Website Report :

In 2023, 49.21% of compromised websites were discovered to contain at least one backdoor at the time of infection. Our team successfully removed 21,062 backdoors from these infected sites.

The same report records that 95.5% of the infections Sucuri cleaned were on WordPress, that 39.1% of infected sites were out of date at the point of infection, and that an average of 610 files were cleaned per request.

Say the year. There is no Sucuri Hacked Website Report for 2024, 2025 or 2026; the 2023 edition is the last one containing cleanup data. The 2024 SiteCheck report is remote-scan data only — 70.8 million scans, 1,176,701 infected sites, a 1.66% infection rate — and contains no backdoor-prevalence figure at all. Writing “half of hacked sites contain a backdoor” without the year is the easiest factual error available in this subject.

What actually lands on disk

Campaign names age badly. File-level indicators do not, and they are what a scanner sees.

Polyglots and handler abuse. Wordfence’s Ninja Forms write-up contains verbatim captured requests, and they are the clearest real-world evidence that handler abuse is not a theoretical technique:

• An .htaccess uploaded disguised as an image — the destination filename carried %2ehtaccess while the upload declared itself image.jpg — containing AddType application/x-httpd-php .txt. That single line makes every .txt file in the directory execute as PHP.
• A %PDF-1.4 polyglot stored as nf_lab_10e31d63.php.
• A GIF89a polyglot, declared image/jpeg, path-traversed two directories up and written as wp_cache.php.

(Wordfence, Ninja Forms .) Wordfence’s own explanation of why this works is worth repeating: some validators check magic bytes, some check extensions, some trust the client’s MIME type — and a well-built polyglot satisfies several checks at once.

Predictable drop paths. Elementor Pro exploitation lands in /wp-content/uploads/elementor/forms/ with a uniqid() filename and an attacker-chosen .php extension (Wordfence ). Wordfence’s indicator-of-compromise advice for that campaign reduces to a single rule: the presence of any .php file in that location is a strong indicator of compromise. Super Forms exploitation dropped a browser-based uploader named Mushr00w_upl.php (Wordfence ); the Hunk Companion chain dropped /htdocs/aea74fff3c02.php.

Balada Injector is the long-running counter-argument to path-based allow-listing: Sucuri documents 176 distinct backdoor paths, including a plugin file named wp-felody.php (Sucuri ).

mu-plugins deserve particular attention because they auto-load and never appear in the plugins UI. Sucuri documented the pattern twice in 2025 (March , July ); the July case stores its payload in wp_options under the key _hdra_core and creates an administrator account named officialwp.

Named shell families, carefully. The families that appear in primary vendor incident reporting are WSO/FilesMan, b374k, BestShell, Godzilla and VShell/SNOWLIGHT. Two names you will see repeated in blog posts — p0wny and IndoXploit — did not appear in any Wordfence, Patchstack or Sucuri source we read, so we do not attribute them to any WordPress campaign. p0wny-shell is still useful as a generic illustration of the genre, from its own README: “a very basic, single-file, PHP shell … used to quickly execute commands on a server when pentesting a PHP application”, with the project’s own warning that “THIS SCRIPT IS A SECURITY HOLE.” One file in the web root, and the server is someone else’s.

The counter-example we are obliged to publish

Sign1 was database-only. It infected roughly 39,000 sites and left no file artifacts at all (Sucuri ); Sucuri’s remote scanner recorded 96,084 Sign1 detections across 2024 (SiteCheck 2024 ). A filesystem scanner would not have caught it.

We include this because a threat summary that only lists cases favourable to the product being sold is a sales deck. The honest framing is narrower and still useful: file-write monitoring addresses file-based persistence, which is most of it and the part that survives a site cleanup, while database-resident injections need a different control.

Two more things patching does not cover

Supply chain. Four documented incidents run from WordPress.org credential stuffing in 2024 through a ShapedPlugin build-pipeline compromise to a poisoned BdThemes API response . None of these is stopped by patching promptly, because the malicious code arrives through the update mechanism, signed and expected. File integrity is the layer that sees it.

Age. We parsed the full CISA KEV catalogue (v2026.09.02, 1,694 entries) and found only six WordPress-related entries. None of the widely cited plugin CVEs — Bricks, LiteSpeed Cache, GiveWP, the Hunk Companion chain, the 2026 Elementor Pro and Ninja Forms bugs — is among them; only the July 2026 WordPress core CVEs were added, with a three-day remediation due date. If you see “this plugin CVE is in KEV” in an article, it is checkable, and it is usually wrong. The useful inverse: CVE-2020-25213 (WP File Manager, added to KEV in 2021) still appears in SOCRadar’s 2026 WP-SHELLSTORM kit — a six-year-old vulnerability still being mass-exploited.

A note for anyone quoting severity: six of the CVEs in this space carry conflicting CVSS scores between assigners, notably CVE-2026-60137 at 5.9 from WPScan against 9.1 from CISA-ADP. Always name the assigner.

What this means for CyberPanel operators

1. Treat .php in an upload directory as an incident, not a finding. It is the single highest-value file-level indicator in this whole data set, and it comes from the vendors’ own IoC advice rather than from us.
2. Watch mu-plugins and .htaccess, not just plugin directories. Both auto-apply, neither is visible in the WordPress admin UI, and both appear in documented 2024–2026 campaigns.
3. Assume the write happens before the patch. With a five-hour median to first exploitation and cases beginning before the advisory, the control that helps is the one that notices a new file, not the one that waits for a nightly sweep. We work through that argument in why webshell detection belongs on the server .
4. Keep a database-side control in the plan. Sign1 is the reminder that filesystem monitoring has a defined edge. Site-level scanning and database inspection remain part of a complete answer.
5. Date every statistic you repeat. The 49.21% backdoor figure is 2023. The Wordfence annual series stops at 2024. Reusing either as current is the mistake most likely to cost you credibility with a customer who checks.

Shelltrap watches file writes under your customer roots in real time, scores what it finds with ClamAV, YARA, hash sets and heuristics in a sandboxed worker, and can hold a web upload for inspection before the application sees it. See the installation documentation for what that requires on your host, or the pricing page for commercial terms.