Block WordPress xmlrpc.php access

If you run a WordPress site, you’ve likely noticed repeated hits to /xmlrpc.php in your security logs. These requests come from bots probing for weaknesses, often trying brute-force logins or launching DDoS-style amplification attacks.

Even a simple “Access Denied” or “Forbidden” response from your server still uses CPU and RAM. When thousands of these requests arrive daily, they add up to real resource waste, slower performance, and cluttered logs.

Blocking this file at the edge with Cloudflare changes everything. Cloudflare stops the requests before they ever reach your origin server, no PHP execution, no WordPress loading, and zero extra load on your hosting.

This simple move delivers immediate benefits: cleaner logs, lower resource usage, and one less attack vector.

Why xmlrpc.php Attracts? 

The xmlrpc.php file is a legacy WordPress feature for remote publishing and pingbacks. While the modern REST API has largely replaced it, the old endpoint remains active by default on most sites.

Attackers love it because:

• It supports system.multicall, letting them test hundreds of username/password combinations in a single request.
• Pingback functionality can amplify traffic in DDoS attacks.
• Bots hit it constantly, even if you’ve disabled the feature inside WordPress.

Security plugins like Defender Pro often log “IXR Class Error” entries when these bots arrive. By the time you see the log, the damage (in the form of wasted resources) has already happened.

Moving the block to Cloudflare’s Web Application Firewall (WAF) fixes this at the network level.

Cloudflare Custom Rule

Cloudflare makes this straightforward, even on free plans.

1. Log in to Cloudflare and select the domain you want to protect.

2. Go to Security > Security Rules

3. Click Create rule.

4. Give it a clear name, such as “Block XMLRPC Attacks”.

5. Set the matching condition:

   • Field: URI Path
   • Operator: equals (or contains for broader coverage)
   • Value: /xmlrpc.php 

6. Choose the action:

   • Block, for maximum protection if you don’t need the endpoint.

7. Click Deploy.

Cloudflare now handles these requests at the edge.

Jetpack and Mobile App Users

Some tools still rely on xmlrpc.php:

• Jetpack uses it for certain connections (especially with the ?for=jetpack query string).
• The official WordPress mobile app can also depend on it for some functions.

A full block may break these features. In those cases:

• Switch the action to Managed Challenge instead of Block.
• Or create a more advanced rule that allows specific Jetpack IP ranges while blocking everything else. Cloudflare already has built-in protection (managed rule WP0007) that whitelists genuine Jetpack traffic.

If you’re unsure whether you need XML-RPC, test after deploying. Most modern sites function perfectly without it.

Confirm the Rule

Visit https://yourwebsite.com/xmlrpc.php in a private browser window.

With the rule active, you should see a Cloudflare block or challenge page instead of the default message “XML-RPC server accepts POST requests only” or any WordPress error.

Check your security plugin logs (such as Defender Pro). You should see a sharp drop in IXR-related alerts because the requests never reach your server.

Extra Tips to Maximize Protection

• Combine this rule with other common WordPress hardening steps, such as rate limiting on /wp-login.php.
• If you want to redirect instead of block, some users forward /xmlrpc.php* to the homepage via a Page Rule (though a direct block is usually cleaner).
• Monitor Cloudflare analytics for blocked requests to confirm the volume you’re stopping.

Impact You’ll Notice

Site owners who implement this report:

• Fewer spikes in CPU/RAM usage during attack waves.
• Much cleaner security logs with fewer false alerts.
• Overall snappier site performance because the origin server stays focused on real visitors.

One well-known WordPress expert recently highlighted seeing 70k requests to xmlrpc.php in a single day on a site before blocking it.

If you’re not actively using XMLRPC for remote publishing, there’s almost no reason to leave it open.

Summary

Blocking /xmlrpc.php directly in Cloudflare WAF prevents malicious traffic from ever reaching your WordPress server. You save resources, reduce log noise, and cut off an entire category of automated attacks.

For most sites, a simple Block rule on the URI path does the job. If you use Jetpack or the mobile app, opt for a Managed Challenge or add targeted allow conditions instead.