How to Disable XML-RPC in WordPress (and Why)
Learn how to disable XML-RPC in WordPress to protect your site against brute-force attacks, eliminate server strain, and boost overall security effortlessly.
Why XML-RPC Is a Serious WordPress Security Liability
XML-RPC is an outdated remote communication protocol enabled by default in core WordPress installations via the xmlrpc.php file. Originally built to let external mobile apps, blogging clients, and desktop editors publish content remotely, it has become one of the most routinely abused attack vectors across the web. Most modern integrations rely on the faster, modern WordPress REST API instead, rendering legacy XML-RPC unnecessary for virtually all contemporary website setups.
The primary threat stem from brute-force amplification attacks targeting authentication routines. Attackers use XML-RPC system.multicall methods to test hundreds of password combinations within a single HTTP request, effectively bypassing standard login rate limits and security plugins. A sustained attack of this nature consumes massive server RAM and CPU cycles, often taking small business hosting accounts entirely offline before firewalls detect unauthorized login attempts.
Furthermore, attackers weaponize WordPress XML-RPC pingback features to orchestrate distributed denial-of-service (DDoS) campaigns against third-party targets. Your web server can silently participate in overwhelming external sites while exhausting its own outgoing bandwidth. Disabling this endpoint plugs these critical vulnerabilities immediately without requiring code rewrites or complex hosting migrations.
How to Disable XML-RPC Using Server Configuration Rules
The most effective way to turn off XML-RPC is blocking requests at the web server level before they ever reach PHP or touch your MySQL database. If your site runs on Apache or LiteSpeed, you can achieve this by appending a simple rule to your root .htaccess file. Place the code block above any standard WordPress rewrites to ensure early termination of suspicious incoming payloads.
Add an Files directive in .htaccess targeting xmlrpc.php that requires all granted conditions to fail or denies access explicitly using Apache 2.4 syntax. Once saved, any external request sent to xmlrpc.php receives an immediate 403 Forbidden status code, which consumes virtually zero server processing power and shields core files from exploratory scraping bots.
If your host uses Nginx, you must place a dedicated location block inside your domain server configuration file. Define location = /xmlrpc.php and set the directive to return 403 or deny all. After applying this block, run a quick configuration test using nginx -t and reload the service to enforce the rule across all active worker threads instantly.
Disabling XML-RPC via Plugins or Custom Functions
For site owners who lack FTP credentials, command line access, or comfort editing server configuration files, WordPress plugins offer a reliable alternative. Dedicated plugins such as Disable XML-RPC or comprehensive security suites like Wordfence and Solid Security provide one-click toggle switches to deactivate the protocol, requiring no manual file edits whatsoever.
Alternatively, developers can disable remote authentication hooks by inserting a filter directly into the active child theme functions.php file or a custom must-use plugin. Adding add_filter('xmlrpc_enabled', '__return_false') will instruct WordPress to reject incoming XML-RPC commands whenever the core framework initializes, maintaining clean version-controlled site management across team workflows.
Keep in mind that software-level filtering still spins up the WordPress core and executes database connections to serve the rejection response. While this method safely neutralizes brute-force password guessing and illicit remote publishing, server-level blocking remains substantially superior for mitigating high-volume volumetric denial-of-service floods on shared hosting environments.
Compatibility Trade-offs and Troubleshooting Edge Cases
Before completely locking down xmlrpc.php, audit your active plugins and third-party integrations to prevent accidental service disruption. The official WordPress mobile app relies on XML-RPC if your server blocks REST API endpoints, and legacy automation platforms like IFTTT or older Zapier connectors may depend on it to publish queued syndication updates automatically.
The most prominent plugin affected by an unconditional XML-RPC block is Automattic's Jetpack suite. Several Jetpack modules require constant bidirectional communication between your host and the WordPress.com cloud infrastructure. If your business depends on Jetpack features, consider whitelisting Automattic's official IP ranges in your server configuration rather than issuing a blanket block on the endpoint.
After implementing your chosen block, verify its status using a command-line curl request or an online XML-RPC testing utility. Send a POST request to yoursite.com/xmlrpc.php and confirm the server returns an HTTP 403 Forbidden or 404 Not Found response. If the endpoint still returns a 200 OK code, clear your CDN and server-side cache layers to ensure edge proxies serve the updated security directives.
Questions readers ask about this topic
Will disabling XML-RPC break my WordPress website?
Does Jetpack work without XML-RPC?
Is XML-RPC still necessary in modern WordPress versions?
How can I check if XML-RPC is active on my site?
Where to go next on Hostilo
One email a month. Hosting deals, new reviews, no fluff.
The WordPress performance checklist that actually works
Boost your WordPress speed with our performance checklist. Learn actionable tips that improve Core Web Vitals and user experience, ranked by real-world impact.
How to speed up WordPress: the only checklist you need
Learn how to speed up WordPress by focusing on the three changes that matter most: hosting, caching, and a CDN. Our guide ranks optimizations by impact.