How to Disable XML-RPC in WordPress: Complete Security Hardening Guide

If you want to disable XML-RPC in WordPress, you’re already thinking like a security-first site owner — and this guide is going to give you every tool you need to do it right. XML-RPC is a legacy remote-access protocol that’s been open on every WordPress installation by default since version 3.5, and attackers have been weaponizing it for over a decade. Leaving it enabled without a clear reason is one of the fastest ways to hand the keys to your site to a botnet.

The threat isn’t theoretical. Wordfence blocked 55 billion password attack attempts across its network in 2024 alone. A significant chunk of those attacks ran through xmlrpc.php — the endpoint that powers XML-RPC — using a technique that lets attackers test up to 1,999 passwords in a single HTTP request. Your firewall doesn’t even see it coming.

This guide covers four concrete methods to disable XML-RPC in WordPress, server-level firewall blocking, CDN rules, what to do when something breaks after you disable it, and the rare edge cases where you genuinely shouldn’t. Whether you’re a beginner reaching for a plugin or an admin editing Nginx configs, there’s a method here for you.

What Is XML-RPC in WordPress?

XML-RPC (Extensible Markup Language Remote Procedure Call) is a protocol that lets external applications talk to your WordPress site remotely using HTTP requests formatted in XML. It lives in a single file: xmlrpc.php in your WordPress root directory. Before the REST API existed, XML-RPC was how the WordPress mobile app, desktop blogging clients, and services like IFTTT communicated with your site.

WordPress first added XML-RPC support back in 2003. By WordPress 3.5 (released December 2012), it was switched on by default with no toggle in the admin dashboard to turn it off. The UI checkbox was removed because the core team assumed developers would manage it themselves. That assumption left millions of sites permanently exposed.

XML-RPC vs the WordPress REST API

The WordPress REST API, introduced in WordPress 4.7 (2016), replaced XML-RPC as the modern standard for remote WordPress communication. The REST API uses JSON instead of XML, supports application passwords and OAuth authentication, enforces nonce verification, and allows granular per-endpoint permission control. XML-RPC has none of that. It uses a single authentication method (username + password passed in plaintext XML), has no rate limiting built in, and exposes powerful methods — including content publishing and user management — to anyone who can reach xmlrpc.php.

For almost every modern WordPress use case, the REST API handles the job better and safer. The only reason to keep XML-RPC alive is compatibility with older systems that haven’t been updated to use the REST API.

Why XML-RPC Is a Dangerous Security Risk

XML-RPC doesn’t just have one attack vector. It has two major ones, and both are brutally effective.

Brute Force Amplification via system.multicall

The system.multicall method is an XML-RPC feature designed to bundle multiple function calls into a single HTTP request — a legitimate performance optimization. Attackers turned it into a brute force superweapon. By packing up to 1,999 username/password combinations into one system.multicall request, an attacker can test thousands of credentials with just three or four HTTP requests total.

Your login rate limiter counts HTTP requests. It sees three requests. It blocks nothing. Meanwhile, 6,000 password attempts just fired through your front door. As Cloudflare’s security researcher Pasha Kravtsov noted, “This form of brute force attack is harder to detect, since you won’t necessarily see a flood of requests.” Standard brute force protection tools that monitor request volume are completely blind to this attack when XML-RPC is open.

DDoS Amplification via Pingback Abuse

XML-RPC’s pingback feature lets WordPress automatically notify other sites when you link to them. That’s useful for blog engagement. It’s catastrophic for security. An attacker can send a single pingback request to thousands of WordPress sites simultaneously, instructing each one to fire an HTTP request at a target URL. Every site becomes an unwitting attack drone in a distributed denial-of-service flood.

“One attacker can use thousands of popular and clean WordPress sites to perform their DDoS attack while being hidden in the shadows, and that all happens with a simple pingback request to the XML-RPC file.”

— Daniel Cid, Founder of Sucuri & VP of Engineering, GoDaddy Security

The 162,000-Site DDoS Attack: A Real Case Study

In March 2014, Sucuri documented a DDoS attack in which more than 162,000 legitimate, uncompromised WordPress sites were weaponized through XML-RPC pingback abuse to flood a single target. The site owners had no idea their servers were attacking someone else. Their sites weren’t hacked — they just had XML-RPC on by default, the way WordPress ships.

That was 2014. The attack surface hasn’t shrunk. According to Patchstack’s State of WordPress Security 2026 report, 11,334 new WordPress ecosystem vulnerabilities were discovered in 2025 — a 42% increase from the year before — and the median time from public disclosure to active mass exploitation is just five hours. XML-RPC is a decade-old attack vector sitting open on most WordPress installs right now.

How to Check If XML-RPC Is Enabled on Your Site

Before you disable XML-RPC in WordPress, confirm it’s actually active on your site. There are two quick ways to check.

The Browser Test

Visit https://yourdomain.com/xmlrpc.php in your browser. If XML-RPC is enabled, you’ll see this response: “XML-RPC server accepts POST requests only.” That means the endpoint is live and accepting connections. If you get a 403 or 404, it’s already blocked or the file doesn’t exist.

Checking Your Server Logs for Active Attacks

Open your server’s access log (typically /var/log/apache2/access.log or /var/log/nginx/access.log) and search for POST requests to /xmlrpc.php. Run this command:

grep "POST /xmlrpc.php" /var/log/apache2/access.log | wc -l

If that number is in the hundreds or thousands, you’re already under active attack. Time to disable XML-RPC in WordPress right now — not after you finish reading.

How to Disable XML-RPC in WordPress (4 Methods)

Pick the method that matches your technical comfort level. All four achieve the goal: block access to xmlrpc.php and stop attackers from using it as an entry point.

Method 1: Use a Security Plugin (Easiest)

If you want to disable XML-RPC in WordPress without touching code, install Wordfence Security or Solid Security (formerly iThemes Security). Both have a one-click toggle to disable XML-RPC. In Wordfence, navigate to Wordfence → All Options → XML-RPC and check “Disable XML-RPC authentication.” In Solid Security, go to Security → Settings → WordPress Tweaks → XML-RPC and set it to “Disable XML-RPC.”

You can also use the dedicated Disable XML-RPC plugin by John Blackbourn — it’s a single-purpose plugin that does exactly what the name says with no configuration needed. Install, activate, done.

Method 2: PHP Filter in functions.php (Recommended for Developers)

This is the cleanest code-only method to disable XML-RPC in WordPress. It uses a WordPress filter hook to return false for the xmlrpc_enabled check. Add this to your child theme’s functions.php or a custom code snippets plugin:

<?php
// Disable XML-RPC in WordPress
add_filter( 'xmlrpc_enabled', '__return_false' );

This filter disables authentication via XML-RPC but leaves the file accessible (returning a 403). For most sites that’s sufficient. If you want to block all access to the file entirely, use Method 3 or 4 instead. For context on working with WordPress config files, see our guide on understanding your wp-config.php file.

Method 3: Block via .htaccess (Apache Servers)

This method blocks all HTTP requests to xmlrpc.php at the server level before WordPress even loads — which means lower resource usage and a harder stop. Make sure you understand WordPress file permissions before editing .htaccess. Add this block to your .htaccess file, above the default WordPress rules:

# Disable XML-RPC in WordPress — block all access to xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

Save the file and test by visiting https://yourdomain.com/xmlrpc.php. You should receive a 403 Forbidden response. If you get a 500 error, check the syntax — a misplaced character in .htaccess will take down your site.

Method 4: Block via Nginx Configuration

If your server runs Nginx (which powers a large share of WordPress hosting and is used by platforms like Kinsta and SpinupWP), use a location block in your server config. Add this inside your server {} block:

# Disable XML-RPC in WordPress — Nginx block
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

Return code 444 is Nginx-specific — it closes the connection without sending any response, which is more efficient than a 403 and gives attackers less information. After editing, test your Nginx config with nginx -t and reload with systemctl reload nginx.

How to Block XML-RPC at the CDN and Firewall Level

Server-level blocking is good. CDN and WAF-level blocking is better — it stops the traffic before it ever touches your origin server, meaning zero load on your WordPress install.

Cloudflare WAF Rule

If your site runs behind Cloudflare (free tier works), create a custom WAF rule to block requests to xmlrpc.php. In the Cloudflare dashboard, go to Security → WAF → Custom Rules → Create Rule and set:

Field: URI Path
Operator: equals
Value: /xmlrpc.php
Action: Block

This blocks all traffic to /xmlrpc.php at the edge, regardless of HTTP method. Attackers trying to use XML-RPC against your site receive a Cloudflare 403 page and your origin server never sees the request. This is the most efficient way to disable XML-RPC in WordPress when you’re already using a CDN.

Sucuri Firewall

Sucuri’s WAF has an XML-RPC toggle built into the dashboard under Security → Hardening → Block XML-RPC. Enable it and Sucuri handles the blocking at the proxy level before requests reach your server.

Server-Level Firewall with fail2ban

For VPS and dedicated server users, fail2ban can auto-ban IPs that repeatedly probe xmlrpc.php. Create a filter that watches for POST requests to the endpoint and a jail rule that bans offending IPs after a configurable number of attempts. This pairs well with the Nginx block — the location block denies the request, fail2ban sees the attempt in the log and bans the IP at the firewall level.

When You Should NOT Disable XML-RPC

The honest answer: very few modern WordPress sites have a legitimate reason to keep XML-RPC open. But there are real exceptions you should check before you disable XML-RPC in WordPress.

Jetpack Plugin

Jetpack requires XML-RPC to maintain its connection to WordPress.com. If you use Jetpack for stats, security scanning, CDN, or any of its other features, fully blocking xmlrpc.php will break it. The workaround: whitelist Automattic’s IP ranges in your firewall rules so only their servers can reach the endpoint. This lets Jetpack function while keeping the file closed to the rest of the internet.

Legacy Mobile Apps and Third-Party Integrations

Old versions of desktop blogging clients (MarsEdit, Blogo), certain IFTTT workflows, and custom-built automation tools may still call XML-RPC. Audit your integrations before you disable XML-RPC in WordPress. If a tool is still actively used and hasn’t been updated to the REST API, you’ll need to either whitelist the integration’s IP or push the vendor to modernize their implementation.

The Default WordPress Mobile App

The current official WordPress mobile app uses the REST API, not XML-RPC. If you’re running a recent version of the app, you’re already clear to disable XML-RPC in WordPress without affecting mobile publishing.

Troubleshooting After Disabling XML-RPC

Something broke after you disable XML-RPC in WordPress? Here’s the fast diagnostic process.

Identify What’s Using XML-RPC

Before you re-enable anything, check your server logs for which services were hitting xmlrpc.php with successful requests (not attack traffic). Legitimate uses will show up as authenticated POST requests from recognizable IP ranges (WordPress.com’s IPs, your blogging app’s IP, etc.).

How to Re-Enable XML-RPC Temporarily

If you need to roll back quickly, reverse the method you used. Remove the add_filter line from functions.php, delete the <Files xmlrpc.php> block from .htaccess, or comment out the Nginx location block and reload. Then identify the affected integration and plan a proper whitelisting solution instead of leaving it open permanently.

Test Your Site After Every Change

After you disable XML-RPC in WordPress, test all publishing workflows, third-party integrations, scheduled automations, and any API-connected tools. Use the official WordPress security hardening documentation as a reference for what else to audit while you’re in hardening mode. And keep your core installation current — read our guide on how to update WordPress safely to avoid introducing new vulnerabilities while closing old ones.

XML-RPC Security Beyond Just Disabling It

If you want to fully secure your WordPress site, disabling XML-RPC is one layer — a critical one, but not the whole fortress. Here’s what should come next.

Add Two-Factor Authentication

Even with XML-RPC disabled, your WordPress login page is still a target. Setting up two-factor authentication makes stolen or brute-forced credentials useless without the second factor. It’s the single highest-ROI security upgrade you can make after closing XML-RPC.

Monitor for Attack Attempts

After you disable XML-RPC in WordPress, keep monitoring your server logs or a security plugin’s logs for continued probing of xmlrpc.php. If you’re blocking at the server level, these attempts cost you almost nothing — but knowing your attacker’s IP ranges can help you build preemptive firewall rules. Install a plugin like Wordfence or set up log monitoring alerts for continued POST requests to the endpoint.

Rate Limiting as a Complementary Defense

Even with XML-RPC closed, rate limiting your WordPress login page is essential. Most brute force tools will pivot to wp-login.php once xmlrpc.php stops responding. Add rate limiting at the Nginx level or through your WAF to cap login attempts per IP per minute.

The Full Security Stack

Disable XML-RPC in WordPress. Enforce 2FA. Keep your core, themes, and plugins updated. Set correct file permissions. Limit admin-level user accounts. Audit your plugins for known vulnerabilities — per Patchstack’s 2026 report, 46% of WordPress vulnerabilities had no patch available at the time of public disclosure. No single security measure is enough alone, but each layer you add increases the attacker’s cost to compromise your site.

The three-step action plan: check if XML-RPC is active on your site right now, pick the disable method that fits your setup, and pair it with two-factor authentication and a WAF rule for a complete defensive layer. To go deeper on locking down your WordPress install, read the full WordPress security hardening guide — and browse our security tools in the Arsenal for no-subscription options built for site owners who take this seriously.

Got a question about disabling XML-RPC in WordPress or ran into an edge case we didn’t cover? Drop it in the comments — we read every one.