WordPress Sites Get Attacked Just for Being Online: 422 Attacks in 7 Hours
A WordPress site does not need visitors, content or backlinks to get attacked. It only needs to exist. On 6 September 2026 we put 21 empty WordPress honeypots online; within seven hours they took 422 attacks from 85 IP addresses, the first one 15 minutes after go-live.
Warning for every site owner: nobody knew these 21 sites existed. No link, no search engine, no visitor. They still received about 20 attacks each in one afternoon, and all 21 were hit. Your site gets the same traffic from the day it goes online, not once it becomes popular. Protect wp-login.php, xmlrpc.php and the REST API before launch, not after the first incident.
None of the 21 domains was linked, submitted to a search engine or mentioned anywhere. The only public trace was a freshly issued TLS certificate. To watch this on your own server, follow the honeypot server setup guide; an instance is running in about ten minutes.
How fast do attackers find a new WordPress site?
The fleet went live between 12:30 and 12:45 UTC. The first detection on a brand-new host (web00) was logged at 12:49:57 UTC. Within the 13:00 UTC hour the 21 hosts recorded 120 attacks, the largest wave of the day until a second peak of 150 attacks in the 16:00 UTC hour.
How did anyone know the hosts existed? Every certificate issued by Let’s Encrypt is published to public Certificate Transparency logs within seconds. Scanners subscribe to those log feeds and probe each new hostname as it appears. That is the most likely route here: no backlinks, no sitemap ping, no crawler request before the certificate was issued, and a full scan 15 minutes later.
What 422 attacks on a new WordPress site look like
All numbers cover 6 September 2026, 00:00 to 19:30 UTC, across all 21 hosts. Our own monitoring IPs are excluded. The request mix was 335 GET, 80 POST, 4 HEAD and 3 PROPFIND.
| Path | Hits | What the request is after |
|---|---|---|
/ | 91 | Front page fetch by a scanner, flagged via user agent and behaviour |
/?rest_route=/batch/v1 | 64 | wp2shell, CVE-2026-63030 REST batch exploit |
/.env | 47 | Environment file with database and API credentials (plus 10 hits on .env.local, .env.example, .env.production) |
/xmlrpc.php | 28 | XML-RPC abuse, multicall login attempts |
/author/admin/ | 23 | User enumeration |
/wp-login.php?action=lostpassword | 22 | Password reset abuse |
/secure-vault-q4m8/ | 16 | Spider trap: a link that is invisible to humans (see below) |
/wp-config.php.bak | 15 | Backup copy of the WordPress config |
/.git/config | 11 | Exposed Git repository |
/wp-content/debug.log | 11 | Debug log with paths and stack traces |
wp2shell is the number one attack, ahead of .env grabbing
The single most frequent detection was the REST batch exploit behind wp2shell: 69 detections in seven hours, on hosts that had existed for less than a day. That puts a core vulnerability disclosed in July ahead of the classic .env probe (40 detections; the path itself was requested 47 times), XML-RPC abuse (27) and wp-login brute force (24). We covered the attack chain and the firewall rules that block it in the wp2shell write-up.
Mapped to ReportedIP threat categories, the day breaks down as follows:
- Bad Web Bot (category 19): 82 reports
- WP REST API Abuse + WP Core Exploit (34, 37): 58 reports
- Port Scan + Hacking + WP Config Exposure (14, 15, 58): 53 reports
- Port Scan + Hacking (14, 15): 30 reports
- Brute Force + WP Login Brute Force (18, 31): 24 reports
One scanner, 21 targets: why fleet-wide correlation matters
34 of the 85 attacker IPs (40 percent) hit more than one host. One IP, 159.69.198.144 on a Hetzner range, scanned all 21 hosts with 66 requests in total. A second one, 157.143.67.218, reached 20 of 21. 130.12.180.117 covered 17 hosts, and three addresses from one OVH range (158.69.55.148, 158.69.117.45, 158.69.55.82) produced 46 hits between them.
- 51 IPs touched exactly one host
- 15 IPs touched two hosts
- 7 IPs touched three hosts
- 12 IPs touched between 4 and 21 hosts
A single site sees one probe and cannot tell a stray request from a campaign. Twenty-one sites seeing the same IP within a few minutes can. The confidence score rewards this through its reporter diversity term: an address reported by several independent sources climbs faster than one reported many times by a single source.
The spider trap: 16 visits to a link no human can see
Every honeypot front page contains a link to /secure-vault-q4m8/ that is hidden with display:none. A person browsing the site never sees it. A search engine that renders the page ignores it. The only client that requests it is a bot that extracts every href from the HTML and follows them all. That happened 16 times on day one, and each hit was reported with the honeytoken category. The mechanism is described in the decoy paths article.
The user agents confirm it. 192 requests carried a truncated fake Chrome string (Windows NT 10.0 without the Chrome token), the largest single scanner fleet of the day. 66 requests came from curl/7.74.0, 28 from an Android Nexus 5 string (a 2015 device), 5 from l9scan (leakix.net). 32 requests carried ClaudeBot/1.0, which the bot classifier files under AI agents rather than attackers.
Context: one host alone has collected 12,357 attacks
One of the 21 hosts, web05, had already been running as a single honeypot since the beginning of September and stands at 12,357 logged attacks. The other 20 are on day one. We will publish the fleet numbers again once they cover a full month; the quarterly figures live in the WordPress attack report.
What this means for your own WordPress site
The 21 honeypots are ordinary WordPress front ends behind ordinary domains. Nothing about them attracted the scanners except being reachable. The same 85 addresses that probed them probe every other WordPress site they find in the certificate logs, including yours. Three consequences for your own site:
- Secure the site before it has traffic. The attacks start before the first visitor arrives. Login, XML-RPC and the REST batch endpoint need protection on install day.
- Block by reputation, not by incident. 40 percent of the attacker IPs hit several hosts. An address that has already been reported by other sites can be blocked before it reaches your login form. That is what ReportedIP Hive does with the community data.
- Whitelist your own monitoring. An uptime check from curl looks exactly like a scanner. Add its IPs before it runs, or you report yourself.
Run your own honeypot with the ReportedIP Honeypot Server
All 21 hosts run the ReportedIP Honeypot Server 1.3.10, a standalone PHP application that emulates a WordPress, Drupal or Joomla installation. It needs PHP 8.2 with pdo_sqlite and curl, has no Composer dependencies, stores everything in SQLite and ships with a Dockerfile.
- 39 threat analyzers for SQL injection, path traversal, brute force, credential stuffing, XML-RPC abuse, plugin exploits, config file access and webshell probes
- Honeytokens: the fake
.env,.git/configand phpMyAdmin leaks embed per-IP canary credentials; replaying one is a confirmed-malicious event - Spider trap and tarpit: hidden links, a robots.txt bait path, a blind-SQLi tarpit and a sticky fake admin that captures uploaded plugin payloads
- Automatic reporting to the reportedip.com API with rate limiting and exponential backoff, plus webhooks for your SIEM, Slack or AbuseIPDB
- Admin dashboard for attacks, payloads, triggered honeytokens and whitelists
Reporting needs a Community Access Key. Every ReportedIP account includes one: register, then copy the key from your dashboard. One setup detail matters more than the rest: route every request, including dotfiles and robots.txt, to public/index.php. Managed hosting panels often answer /.env with a 403 from the web server, and then the source-leak trap never fires. curl -s https://your-honeypot/.env should return the fake file, not an error page.
Honeypot reports go into the same pool as reports from Hive-protected sites: the confidence score per IP and the dynamic blacklist that Hive installations, fail2ban and firewalls pull from.
Frequently asked questions
How did scanners find domains that were never published?
Through Certificate Transparency logs. Every publicly trusted TLS certificate is logged there, and the logs are searchable in real time. A new hostname with a fresh certificate is visible to anyone watching the feed, which is why the first probe arrived 15 minutes after go-live.
Is a request for /.env on my WordPress site an attack?
Yes. No browser, plugin or search engine has a reason to request that file. On 6 September it was the third most common path across the fleet with 47 hits, plus 10 for .env variants. Make sure your web server returns nothing useful for it.
Will the honeypot report my own uptime checks?
It will if you do not whitelist them. Add the IPv4 and IPv6 addresses of your monitoring and admin systems to the whitelist during installation, before the first status check runs. A curl-based uptime probe looks like a scanner to the analyzers.