You don’t need to be a high-value target to get hit by a large-scale automated attack. You don’t need valuable data, or to be well-known, or to have done anything wrong. All it takes is having a public WordPress site on the Internet. Here’s what happened, layer by layer, when a site protected by SeenSecure received a burst of over 300 requests per minute within seconds.
It’s not a person, it’s a scanner
An attack like this is almost never launched by someone sitting at a keyboard deciding what to try. It’s a script working through a list of thousands of known paths — old plugin folders, demo files, forgotten test scripts — and testing them against millions of domains, one after another, tirelessly and indiscriminately. The target isn’t “your” WordPress specifically: it’s any WordPress that answers “yes” to one of those paths.
In this particular case, the requests included patterns instantly recognizable to anyone who’s spent time in WordPress security:
- Requests to demo files from third-party libraries (like
getid3) that, in older versions of certain plugins, allowed reading or even writing files on the server. - Abandoned test scripts from payment/CRM integrations (like Infusionsoft) that sometimes expose internal functions without authentication.
- Path traversal attempts like
../../../etc/passwd, trying to escape the site’s folder to read system files. - SQL injection syntax payloads, probing whether some URL parameter reaches a database query unsanitized.
None of these techniques are new or sophisticated. They are, literally, the same categories of flaw the Morris Worm exploited back in 1988 — except today they’re tested against millions of sites at once, automatically, for free, with zero effort from whoever runs the scanner.
Layer by layer: what stopped each attempt
A site with no dedicated protection has to trust that WordPress itself, the plugin in question, and the server are all perfectly up to date and configured correctly — a risky bet when a single forgotten file is enough to open the door. Here’s where the chain breaks at each layer:
- Rate Limiting: as soon as a single IP exceeds the allowed requests-per-minute threshold, it gets cut off — without waiting to analyze exactly what it’s asking for. It’s the first barrier, and the cheapest to maintain under heavy load.
- Firewall (WAF) rules: every remaining request is compared against known attack patterns — path traversal, SQL injection, XSS. A match gets blocked before it ever reaches WordPress.
- Sensitive file protection: paths to demo files, backups, logs, or dependency manifests are blocked at the server level, without even executing PHP.
- Block persistence: an IP that triggers several of these alarms in a short time gets blocked for a period, so its next requests never even get evaluated — they’re cut off at the very first step, at near-zero cost to the server.
The result, in this specific case: over 300 requests per minute passing through those layers, and zero requests that ever executed unauthorized code or accessed a file they shouldn’t have.
Why this isn’t an isolated case
What’s unsettling about this kind of attack isn’t its sophistication — it has none — it’s how normal it is. This exact pattern repeats, with minor variations, against practically every public WordPress site, every day, around the clock. The difference between a site that gets compromised and one that never even notices it was probed usually isn’t “more security” in the abstract — it’s having layers that complement each other: one that cuts by volume, another by pattern, another by reputation, and a log of all of it so you know exactly what happened if something slips through.
If you want to see this same kind of traffic on your own WordPress site — you’re probably receiving it right now without knowing — SeenSecure’s real-time Traffic Monitor shows every blocked request, with the exact reason in plain language, no technical log-reading required to understand what’s going on.