New 24/7 monitoring and daily cloud backups now included in every Shield Pro plan.

XML-RPC

Learn how to disable WordPress XML-RPC.

xmlrpc.php powers remote publishing and some integrations but is a common brute-force and DDoS amplification target. This tutorial shows how to disable XML-RPC without breaking services that still depend on it.

Time: 10-20 minutes Level: Beginner
Neil McNaught, founder of BugShield and WordPress author
Written by
Written by
Updated
Updated

What this problem looks like

XML-RPC lets remote clients call WordPress methods over HTTP POST. Most modern sites do not need it. Attackers use it for password guessing and pingback floods.

Blocking at Apache or nginx is more efficient than PHP plugins because requests never reach WordPress. Test Jetpack and mobile apps after blocking.

Step 1: Decide if you need XML-RPC

Jetpack, some mobile apps, and legacy remote clients use xmlrpc.php. If you use none of these, disable it. WooCommerce REST API does not require XML-RPC.

  • Jetpack: may require XML-RPC unless using modern connection methods.
  • WordPress mobile app: historically used XML-RPC.
  • Standard REST API: uses /wp-json/ instead.

Step 2: Block xmlrpc.php in .htaccess

Find .htaccess in your site root, next to wp-admin and wp-content. Add this block on Apache hosts:

apache
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Step 3: Disable via filter in a small plugin or functions.php

If you cannot edit server config, add this to a custom plugin or child theme:

php
add_filter( 'xmlrpc_enabled', '__return_false' );

Step 4: Remove pingback methods only

If you must keep XML-RPC for one service but want to stop pingback abuse, disable pingback methods with a filter rather than blocking the entire file.

Step 5: Verify the block

POST to https://example.com/xmlrpc.php should return 403 or 404. Confirm Jetpack still connects if you rely on it.

Only run the command below if you have SSH access to the server.

bash
curl -I https://example.com/xmlrpc.php

When to stop DIY and hire help

If brute-force traffic continues after disabling XML-RPC, attackers may target wp-login.php directly. BugShield hardens WordPress login surfaces at a confirmed fixed price.

Questions answered

WordPress XML-RPC FAQs

Answers about XML-RPC uses, attack reduction, Jetpack compatibility, server rules, and testing before disabling it.

Does disabling XML-RPC break the REST API?

No. REST API uses /wp-json/. XML-RPC is a separate legacy endpoint.

Will Wordfence block XML-RPC enough?

Server-level blocks stop traffic before PHP runs. Plugin blocks work but use more server resources under attack.

Can I disable only pingbacks?

Yes. Pingbacks are the most abused method. Full disable is simpler if you do not use remote clients.

Is XML-RPC required for WooCommerce?

No. WooCommerce uses REST API and webhooks. Safe to disable for most shops.

What is WordPress XML-RPC used for?

The xmlrpc.php endpoint supports remote publishing and some integrations, including parts of Jetpack and older mobile or desktop clients.

How do I know whether my site still needs XML-RPC?

Check active integrations, publishing apps, Jetpack features, and server access logs for legitimate XML-RPC requests before blocking the endpoint.

Is it better to disable XML-RPC in WordPress or at the server?

A server or firewall block rejects traffic before PHP loads and uses fewer resources. A WordPress filter can be easier when only certain XML-RPC methods need restriction.

Does disabling XML-RPC stop all WordPress brute-force attacks?

No. It removes one route, but attackers can still target wp-login.php and other exposed services. Use strong passwords, two-factor authentication, and rate limiting too.

Will disabling XML-RPC break pingbacks and trackbacks?

It can. If you only want to block pingback abuse, disable the pingback methods while leaving required remote-publishing functions available.

How do I test that WordPress XML-RPC is disabled?

Request /xmlrpc.php without sending a real login. A server-level 403 or 404 confirms the block, while the normal message indicates the endpoint still responds.

Would you rather a developer fixed it?

Request a fix at a confirmed price and speak directly with the BugShield developer working on your site.

Request a Fix