Rapport sur les attaques contre WordPress : 1,69 million d'attaques, mai-juillet 2026
Between May 1 and July 21, 2026, the ReportedIP community network recorded 1,692,650 attacks from 206,388 unique IP addresses — measured, not estimated, by honeypot servers and WordPress sites running the Hive security plugin. This is the first quarterly ReportedIP WordPress Attack Report; every figure below comes straight from the live dataset and is free to cite under CC BY 4.0.
The single busiest day was June 17 with 29,217 attacks. Login brute-force was by far the most common WordPress-specific technique, and one incident stood out: the wp2shell unauthenticated RCE (CVE-2026-63030), for which Hive shipped a same-day virtual patch on every plan.
How many attacks, and where do the numbers come from?
Two sources feed the dataset. A fleet of eight honeypot servers imitates WordPress, Drupal and Joomla endpoints and logged 1,505,488 of the attacks; production WordPress sites running Hive in Community Network mode reported the other 186,292 through the public API. Reports are aggregated, deduplicated for bursts, weighted by recency and reporter diversity, and scored into a 0–100 confidence value. No site-visitor personal data is collected, and reporter identity is never published — only aggregate counts leave the network.
- 1,692,650 total attacks (individual reports plus burst-aggregated events)
- 206,388 unique attacking IP addresses
- 29,217 attacks on the peak day (June 17, 2026)
- ~20,600 attacks per day on average across the 82-day window
Did attack volume rise or fall over the quarter?
Attack volume stayed high and remarkably steady. Across all eleven full weeks of the window, weekly attacks held between 133,462 and 179,476, peaking in the week of June 15–21 — the same week as the June 17 peak day. There was no quiet period — automated WordPress attacks are a constant background load, not an occasional event.
What do attackers target on WordPress sites?
Most traffic is generic hacking and credential brute-force that hits any exposed login. But the WordPress-specific breakdown shows where CMS operators should focus. Login brute-force against wp-login.php dwarfs everything else, and reconnaissance — user enumeration and version/plugin scanning — is a large, often-ignored share.
| WordPress attack vector | Attacks (report window) |
|---|---|
Login brute-force (wp-login.php) | 130,856 |
| XML-RPC abuse | 23,602 |
| Version & plugin scanning | 23,269 |
| Plugin exploit attempts | 15,998 |
| Énumération des utilisateurs | 13,768 |
| Core exploit attempts | 6,227 |
Case study: how wp2shell played out
On July 19, 2026, the wp2shell technique was disclosed — an unauthenticated remote code execution chain against WordPress core, tracked as CVE-2026-63030. It abuses the REST batch endpoint’s route parsing to smuggle a privileged sub-request past authentication. Our REST-abuse sensor logged the expected uptick in batch-endpoint probing in the days around disclosure.
The same day, ReportedIP Hive 2.1.25 shipped two firewall rules — waf_rest_batch_desync et waf_rest_batch_nested — that block the route-confusion primitive at the WAF layer. Both are part of the free Paranoia-Level-1 baseline bundled with the plugin on every plan, free included — a site is covered as soon as it updates to 2.1.25, with no rule-sync subscription required (release v2.1.25, July 19). The rules match the structural shape of the malformed request rather than a fixed payload string, so common evasions (extra slashes, protocol-relative or absolute URLs) do not slip past — a behaviour locked by regression tests in the plugin’s test suite. Sites on 2.1.25 or later were protected against this attack class regardless of when they applied the WordPress core patch.
Where Hive PRO goes further
The baseline that blocked wp2shell is free. What PRO adds is depth and speed on the post-exploitation stage. An RCE like wp2shell is typically followed by a webshell upload to establish persistence; Hive PRO ships the extended PL2 firewall signatures — including the webshell and upload-abuse rule group — through a daily, Ed25519-signed rule sync. Free installs receive new rules bundled with plugin releases; PRO installs receive them as they ship, which shortens the exposure window when a technique is actively being weaponised.
How the data was collected
All figures are drawn from the reportedip_ip_reports table over the window May 1 – July 21, 2026, counting individual reports plus their burst-aggregation multiplier. Category figures use the platform’s 30 catégories de menaces. Honeypot and Hive reports are anonymised on ingestion: no site-visitor user agents by default, no reporter IP or identity in any published number. The community blacklist derived from this data lists an IP only at a confidence of 75 % or higher, after a 48-hour cool-down.
Use these numbers
Every figure and chart in this report is licensed under CC BY 4.0 — reuse them in articles, papers or talks with a link to reportedip.de as attribution. For a custom time window, a country breakdown, raw aggregates or a quote, contact Patrick Schlesinger at [email protected]. Full methodology and the report archive live on the Threat Reports page.
What this means for WordPress operators
- Assume constant load. There is no low-traffic window — automated attacks ran at 133k+ per week for the entire quarter.
- Rate-limit the login and XML-RPC. These two account for the bulk of WordPress-specific attempts and are trivially throttled.
- Virtual-patch faster than you can core-patch. The wp2shell window shows the gap between disclosure and patching — a WAF closes it. Install Hive; the firewall baseline is free.
- Run current versions. The rules that stopped wp2shell only exist from 2.1.25 onward; PRO’s daily rule sync keeps that edge current. Compare plans.
The next ReportedIP WordPress Attack Report covers Q3 2026. Every Hive install and honeypot sharpens the dataset — install the plugin or run a honeypot to contribute.