In April 2013, a distributed botnet of over 90,000 servers launched sustained brute-force attacks against WordPress sites globally. The scale was unprecedented — and it changed how the industry thought about login security.
In April 2013, major hosting providers and security companies began reporting an unusually intense and coordinated wave of brute-force attacks targeting WordPress installations worldwide. CloudFlare, HostGator, and others documented a sustained campaign originating from a botnet estimated at over 90,000 compromised servers — not home computers or cheap VMs, but actual web servers with substantial bandwidth.
The attack was notable for two reasons: its scale was far beyond anything previously seen targeting WordPress specifically, and it used infrastructure rather than consumer devices, meaning each attacking node had fast, reliable connections capable of sending large volumes of requests.
The attacking botnet was primarily composed of servers that had themselves been compromised — many of them running vulnerable versions of WordPress. Attackers had already built a large network of compromised sites and were using that network to attack more sites, with the goal of growing it further.
Each node in the botnet was instructed to attempt logins on WordPress sites using the username "admin" — the default WordPress username — combined with a list of common passwords. The distributed nature of the attack meant per-IP rate limiting was less effective: with 90,000 nodes each making a small number of attempts, no single IP address triggered conventional lockout thresholds.
The attack's reliance on the "admin" username reflected the reality that a large portion of WordPress sites — including many that had been running for years without configuration changes — still used it as their administrator account. WordPress had historically created this default, and while newer versions prompted users to choose their own username, the installed base remained.
Matt Mullenweg, WordPress's co-founder, made a public post during the attack specifically urging site owners to change their username from "admin" and enable two-factor authentication. The advice was sound — sites without an "admin" user were effectively immune to this specific campaign.
Many sites that were never at risk of being compromised were still affected. The volume of login requests overwhelmed hosting infrastructure. Shared hosting providers saw server-wide performance degradation as the constant stream of PHP processes handling wp-login.php requests consumed resources across all accounts on affected machines.
Some hosting providers temporarily blocked wp-login.php access entirely for all accounts on their shared servers — a blunt but effective measure that locked out legitimate site owners along with the bots.
The April 2013 attack accelerated several shifts in how WordPress security was approached:
The April 2013 campaign was a spike, not an anomaly. Brute force activity against WordPress login pages has been a constant background noise since WordPress became the dominant web platform. The 2013 attack was unusual only in its coordination and scale — the underlying behaviour, automated tools systematically testing WordPress credentials, happens continuously at lower intensity against every publicly accessible WordPress site.
If your site has a publicly accessible wp-login.php and no login rate limiting, it is being tested right now. Not occasionally. Continuously.
The distributed nature of the 2013 attack is exactly why rate limiting at the IP level isn't sufficient on its own. At DownUnder WP, wp-admin access requires a valid portal session by default — removing the login form from public view entirely rather than just rate-limiting it.
Australian WordPress hosting from $5/month
Your own containerised environment on Australian NVMe servers. Simple, fast, and genuinely cheap.