What a Real WordPress Site Attack Looks Like (And How We Stopped It)
Most articles about WordPress security talk in generalities: keep your plugins updated, use strong passwords, install a firewall. This post is different. This is a real WordPress site attack that hit one of our client sites on July 13, 2026, told with the actual numbers, the actual IP addresses, and the actual fixes we deployed the same day. If you have ever wondered what a WordPress site attack actually looks like from the inside, here it is.
A client site got hit with over 74,000 requests in one hour from automated scanners hunting for known WordPress vulnerabilities, followed by a second wave probing for leftover backdoors. The site went offline, but it was never breached: every malicious request was blocked or challenged before it could do anything. The real cause of the outage was two gaps most WordPress sites share: no rate limiting and almost no caching. We closed both within hours and added daily security monitoring so we catch the next one before it becomes an outage.
What Happened When a Client Site Got Hit With 74,000 Requests in One Hour?
On the morning of July 13, 2026, one of our client sites took two separate waves of automated attack traffic within about two hours of each other. Here is the breakdown.
Wave 1: A Vulnerability Scanner Sprayed the Site With 74,000 Requests
Four servers hosted on Google Cloud sent a coordinated flood of automated requests at the site between 8:44 and 8:58 AM ET. A normal hour for this site runs 500 to 1,200 requests. This hour ran over 74,000, with two of the four addresses responsible for nearly all of it.
This was an automated vulnerability scanner: software that sprays a long list of known exploits at a website hoping something sticks. It probed for backup copies of the WordPress configuration file (which can contain database passwords), known security holes in older plugins and themes, and server exploits that have nothing to do with WordPress at all, including attempts to read the server’s password file. The scanner rotated through fake browser identities to disguise itself. Nothing about the pattern suggests this site was singled out. This is opportunistic software scanning the internet at large, and it is scanning your site too, right now, whether you notice it or not.
| IP address | Requests | Activity |
|---|---|---|
| 34.48.148.135 | ~47,700 | Vulnerability scanning; config file probing |
| 34.21.127.150 | ~26,000 | Plugin/theme exploit attempts; server exploits |
| 34.150.192.133 | ~3,600 | Vulnerability scanning |
| 34.186.109.79 | ~2,700 | Vulnerability scanning |
Wave 2: A Second Attacker Hunted for Leftover Backdoors
About 90 minutes later, two servers hosted on Microsoft Azure, routing through Brazil, probed the site for pre-existing backdoors: files that would have been left behind if the site had been compromised at some earlier point. One of them tested 121 different backdoor locations in four seconds.
They found nothing. That is the detail that matters most here. It means there was no prior compromise sitting on the site waiting to be exploited, which is not something every WordPress site can say.
Why Do Most WordPress Attacks Like This Go Unnoticed?
Here is what makes this incident worth writing about instead of just fixing quietly: this exact pattern happens to WordPress sites constantly, and most site owners never know it happened.
Cloudflare and similar firewalls are good at blocking requests that are obviously malicious, and they did their job here. But the majority of an attack like this does not look malicious on a request by request basis. It just looks like a large amount of ordinary traffic. Unless someone is actively watching the logs, that traffic passes straight through, and a site owner only finds out something happened when the site goes down, if they find out at all.
How We Stopped It (And What We Fixed the Same Day)
The site went offline because of two gaps, not because the attack was especially sophisticated. Here is exactly what we found and fixed.
1. There Was No Rate Limit
Nothing was stopping a single computer from making an unlimited number of requests. One address alone made roughly 47,000 in under fifteen minutes. We deployed a rule that automatically blocks any single visitor address that goes over 150 requests in a 10 second window. The attacker responsible for this outage was sending roughly 580 requests every 10 seconds, so this rule would now stop that traffic within seconds of it starting. We tested it against live traffic afterward to confirm real visitors, even ones loading image heavy pages, never come close to the limit.
2. The Site Was Barely Caching Anything
Only about 15% of the site’s content was being served from Cloudflare’s global network. The other 85%, every image, font, and file, was being fetched from the origin server on every single page view. That meant the server was doing far more work than it needed to even during normal traffic, which left it almost no headroom when the flood arrived. We configured Cloudflare to cache images, fonts, PDFs, and media files for up to a month, which cut the server’s workload dramatically and made the site faster for every visitor, not just during an attack.
3. Nobody Was Watching in Real Time
The site is now on daily security monitoring that reviews Cloudflare’s security events across every site we manage. If a pattern like this starts building again, we see it as it develops instead of finding out when the site goes down.
What This Means for Your Own WordPress Site
If you run a WordPress site, three questions are worth asking yourself right now:
- Do you have a rate limit in place? If not, a single automated scanner can generate unlimited requests against your server with nothing to slow it down.
- How much of your site is actually cached? If most of your images, fonts, and files are being pulled from your own server on every page view, you are running with far less headroom than you think, attack or no attack.
- Would you know if this happened to you? Most site owners only find out about an attack when the site is already down. By then the disruption already happened.
None of this requires a security background. It requires someone checking, and someone who knows what to do with what they find.
Want Us to Check These Three Things on Your Site?
We will look at your rate limiting, caching, and monitoring setup and tell you exactly where the gaps are, free.
The Real Lesson: Reactive vs Proactive Website Support
Reactive website support is a cost you can’t afford. This client’s site came back online the same day with no data loss and no breach, and that is a good outcome, but it is a good outcome that came from having someone already watching. The fixes described in this post took a few hours to deploy because they were deployed by people who already knew the site, already had access, and already understood what normal traffic looked like for it.
The best time to have WordPress support in place is before you need it. We manage 105+ active client sites, and the sites that never go down are not the ones that never get attacked. Every WordPress site gets attacked. They are the ones with someone watching.
Frequently Asked Questions
How common are attacks like this on WordPress sites?
Very common. Automated vulnerability scanners run constantly across the internet, probing sites for known weaknesses in plugins, themes, and configuration files. Most WordPress sites get scanned regularly. What varies is whether the volume is high enough to cause an outage and whether anyone notices before it does.
Does a high-traffic attack mean my site was hacked?
Not necessarily. In this incident, the site went offline from sheer traffic volume overwhelming the server, not from an attacker gaining access. A firewall correctly blocked the requests that were obviously malicious, and the requests that got through were stopped by other means. Every WordPress attack is different, so it is worth having someone confirm there was no breach rather than assuming either way.
What is rate limiting and does my site need it?
Rate limiting automatically blocks a single visitor address once it exceeds a set number of requests in a short window, for example 150 requests in 10 seconds. Without it, one computer can send unlimited requests at your server with nothing to slow it down. Most WordPress sites do not have this configured by default.
How do I know how much of my site is actually cached?
If you use Cloudflare or a similar service, its analytics will show what percentage of requests were served from cache versus fetched from your origin server. A well configured site should be serving the large majority of static files, images, fonts, and media, from cache rather than the server itself.
Can a WordPress maintenance plan actually prevent this?
A maintenance plan will not stop an attacker from trying. It changes what happens when they do: rate limiting, proper caching, and daily security monitoring are what keep an attack attempt from turning into an outage. That is the difference between a site that absorbs the traffic and a site that goes down.
What should I do if I think my WordPress site is under attack right now?
Do not wait to find out. Reach out for a free assessment and we will check your site’s current traffic, security event logs, and configuration to tell you exactly what is happening and what to do about it.