A liability for most modern WordPress sites. Why it’s almost always worth disabling, what you’d actually lose, and the cleanest way to do it.

XML-RPC is one of those WordPress features that quietly stayed enabled for years after most sites stopped needing it. For attackers, it’s a gift. For most modern operators, it’s a liability you can usually turn off without losing anything you actually use.

What XML-RPC even is

It’s a connector that lets WordPress communicate with external apps and services using XML over HTTP. Once useful for posting from third-party clients or pinging other blogs — today, increasingly redundant.

The risks

  • Brute-force attacks: XML-RPC allows multiple authentication attempts in a single request, defeating most simple rate limits.
  • DDoS amplification: attackers can use methods like pingback.ping to weaponize WordPress sites against other targets.
  • Recon surface: by default, XML-RPC exposes endpoints that can leak username structures and installed plugin info.

What you actually give up

  • A few legacy mobile-blogging apps that haven’t moved to the WordPress REST API.
  • Pingbacks and trackbacks, which most operators have already disabled for spam reasons.
  • A small set of plugins that integrate over XML-RPC instead of REST. Check before you flip the switch.

How to disable it

  • Plugin: use a maintained one that disables XML-RPC cleanly.
  • functions.php: add add_filter('xmlrpc_enabled', '__return_false');.
  • Web server / WAF: block /xmlrpc.php entirely at Nginx, Apache, or your CDN/WAF.

What I’d actually do

If you don’t actively use XML-RPC, disable it at the WAF level. It removes an entire class of brute-force and DDoS surface area, with basically no ongoing tradeoff.