Is Your WordPress Website Being Used in a DDoS Attack?

Most people worry about their website being the target of an attack. A more common and less obvious problem is your website being one of the attackers.

Photo by Brett Sayles on Pexels

WordPress sites get recruited into attacks against other people constantly, usually without the owner noticing anything beyond the site feeling slow. The bandwidth is yours, the server load is yours, and the abuse complaint comes to you.

The classic route: XML-RPC pingbacks

WordPress ships with xmlrpc.php, a remote interface that predates the REST API. One of its features is the pingback, which notifies another blog that you have linked to it.

The flaw is that anyone can ask your site to send a pingback to any URL. So an attacker sends your site a request saying “notify this address”, and your server dutifully makes a request to a victim of their choosing. Do that across thousands of WordPress sites at once and the victim receives a flood of traffic from thousands of legitimate, unrelated servers.

Your site is not compromised. It is doing exactly what it was designed to do, on behalf of someone else.

The same file enables a second problem. The system.multicall method lets a caller bundle many operations into one request, which means an attacker can attempt hundreds of password guesses in a single HTTP request. That turns a slow brute force into a fast one and slips past protections that count failed logins per request.

How to tell

Look in your access logs for requests to xmlrpc.php:

grep xmlrpc.php ~/access-logs/example.co.uk | wc -l
grep xmlrpc.php ~/access-logs/example.co.uk | awk '{print $1}' | sort | uniq -c | sort -rn | head

A handful is normal. Thousands, especially POSTs from a small number of addresses, is not.

Other signs worth taking seriously: unexplained outbound traffic, your host contacting you about resource usage, your server appearing on a blocklist, or a site that is intermittently slow with no obvious cause.

Fixing it

Work out whether you need XML-RPC at all. Most sites do not. It was needed for the old WordPress mobile apps, for remote publishing tools, and by Jetpack. If you use none of those, disable it entirely.

The cleanest way is to block it at the web server before WordPress loads. In .htaccess:

<Files "xmlrpc.php">
  Require all denied
</Files>

That stops the request costing you any PHP at all, which is the point. Blocking it with a plugin still loads WordPress first.

If you do need it, at minimum turn off pingbacks. Under Settings then Discussion, untick the options for notifying other blogs and allowing link notifications. You can also disable just the pingback method with a small filter rather than the whole interface.

Rate limit it if you cannot block it. A firewall rule or a Cloudflare rate limiting rule on that one path removes the amplification value while leaving the feature working.

The other ways a site gets recruited

XML-RPC is the famous one, but it is not the only route.

A genuinely compromised site. If an attacker has uploaded a script through a vulnerable plugin, your site becomes a general purpose tool for whatever they want: attacking others, sending spam, hosting phishing pages. This is a different and more serious situation than pingback abuse, and the fix is a proper cleanup and finding how they got in.

Open endpoints being hammered. Anything expensive that can be triggered without logging in, including search, is worth rate limiting. On a shop, an unauthenticated search that runs a heavy query is an easy way to make your own site fall over.

User enumeration. The REST API exposes a users endpoint that lists usernames by default. Not an attack in itself, but it hands over half of every login attempt.

WP-Cron under load. WordPress fires scheduled tasks on page requests. Under a flood of traffic that can mean scheduled work running far more often than intended, turning a small attack into a large load problem. Moving to a real server cron and setting DISABLE_WP_CRON removes that amplifier.

Reducing the surface generally

Keep everything patched, and delete plugins and themes you are not using rather than deactivating them. Deactivated code is still on disk and, depending on the flaw, still reachable.

Two factor authentication on every admin account. Most compromises start with a credential rather than an exploit.

Put something in front of the site. A CDN or WAF absorbs most of this before it reaches you and can rate limit specific paths. It is the single most effective step if you are being hit persistently.

Monitor outbound as well as inbound. Almost nobody does, which is why sites participate in attacks for months undetected.

Why it matters even though you are not the victim

The costs land on you regardless. You pay for the bandwidth and the CPU. Your site is slow for real customers while it happens. Your server’s IP address can end up on blocklists, which affects your email deliverability as well as your website. And your host will contact you about it, because the abuse reports arrive at their door.

Being an unwitting participant is not a defence anyone downstream cares about.

Where to start

Check your logs for xmlrpc.php. If the count is high and you do not use anything that needs it, block it in .htaccess and watch your load. It takes two minutes and on a busy site the difference is immediately visible.

If you are on our WordPress hosting and want us to check whether your site is being used this way, ask and we will look at your logs with you.