xmlrpc.php in WordPress: What It Is, Security Risks, and How to Disable It

Key Takeaways

• Leaving xmlrpc.php open exposes your site to brute-force and DDoS attacks, while manually disabling it via .htaccess risks breaking your website.
• Security plugins can block XML-RPC requests, but they add unnecessary database bloat and slow down your overall page load speeds.
• Secure your site effortlessly using the Cloudways 1-click XML-RPC toggle, and catch hidden payloads with the Malware Protection add-on for just $4/month per application.

Server logs sometimes show sudden spikes in resource usage, where thousands of automated requests hit a specific file called xmlrpc.php. This activity quickly maxes out server CPUs and indicates an active brute-force attack rather than a surge in legitimate traffic.

The xmlrpc wordpress file was originally created to help external applications interact with a site. It is now largely obsolete and functions mostly as an open door for bots to test passwords.

Securing exposed endpoints like XML-RPC is a critical first step in comprehensive website security. The simplest way to stop these attacks and preserve your server resources is to shut the file down completely.

In this blog, we will look at the original purpose of this outdated file, outline the specific security risks it introduces, and provide step by step instructions on how to disable it safely.

What is xmlrpc.php in WordPress?

Before the REST API became the standard, xmlrpc.php was the primary way WordPress communicated with external applications.

If you wanted to publish a post from a mobile app or a third party blogging tool, this file handled the connection.

It allowed users to bypass the main admin dashboard while still interacting with their site. It also managed pingbacks and trackbacks. Whenever you linked to another blog in your content, the XML-RPC protocol sent an automated notification to that website.

The underlying technology has changed significantly since those early versions. The WordPress REST API has largely replaced XML-RPC and handles external communication much more securely.

As a result, this legacy file is now outdated. For almost all modern websites, it serves no actual purpose and simply leaves an unnecessary access point open on your server.

The Security Risks: Why You Should Disable xmlrpc.php

As we mentioned earlier, leaving this unnecessary access point open on your server is exactly why the file is such a massive liability.

Hackers exploit specific functions built into xmlrpc.php to bypass standard security limits and compromise WordPress environments.

Brute Force Login Attacks

Standard login pages throttle password attempts. If a script tries to guess an admin password on wp-login.php, basic security measures block the IP address after a few failed attempts. XML-RPC circumvents these protections entirely.

Hackers use a command called system.multicall to bundle hundreds of password guesses into a single HTTP request.

This technique allows them to cycle through massive credential lists rapidly without triggering login lockouts. These brute force requests are almost always carried out by an automated botnet attack.

DDoS Attacks and Server Crashes

The pingback feature was originally designed for blog notifications, but the protocol lacks verification. An attacker can spoof your website IP address and send pingback requests to thousands of other WordPress sites simultaneously.

Every single one of those external sites immediately responds by pinging your server back. This sudden and massive wave of inbound traffic exhausts your server CPU and memory, causing the site to crash.

Malware Infections and Site Takeovers

A crashed server is a temporary performance issue, but a successful brute force attack is a critical breach. If the multicall exploit successfully guesses your admin credentials, the attacker gains full control over your hosting environment.

Once they guess your password via XML-RPC, their first move is to install a hidden WordPress backdoor. They use this persistent access to drop malicious payloads, modify core files, or redirect your organic traffic to malicious domains.

Automate Your Malware Defense

Stop hidden backdoors in their tracks. The Cloudways Malware Protection add-on automatically isolates and removes malicious payloads at the OS level before they can execute.

Enable Protection

How to Check if xmlrpc.php is Running on Your Site

You have three straightforward ways to verify if this endpoint is active on your WordPress installation.

1. The Browser Test

The fastest method requires no external tools. Open your web browser, type in your domain, and add /xmlrpc.php to the end of the URL.

If the page loads a blank screen with a single line reading “XML-RPC server accepts POST requests only,” the file is exposed and active. If you see a 403 Forbidden or a 404 Not Found error, your server is already blocking access.

2. Online Validation Tools

You can also run a diagnostic check using a free online XML-RPC validator. These web applications simulate the exact type of external requests a bot would make.

If your site is secure and the file is blocked, the tool will fail to connect.

If the endpoint is left wide open, the validator will successfully pass the check and confirm the vulnerability.

3. The Command Line Method

If you prefer working in the terminal, you can send a direct POST request using a cURL command. Paste the following line into your terminal, replacing the dummy URL with your actual domain name:

curl -d "system.listMethods" https://yourdomain.com/xmlrpc.php

If the file is enabled, your server will fire back a raw, structured XML response listing the available methods.

How to Disable xmlrpc.php (The Manual Methods)

If you manage your own server or use a basic shared host, you have two traditional ways to disable this endpoint manually.

Method 1: Disabling via a Plugin

The simplest manual fix is installing a dedicated security plugin like Disable XML-RPC. Once installed and activated, the plugin automatically blocks incoming requests to the file.

That is it!

But…the main drawback to this approach is database bloat. Adding single purpose plugins adds unnecessary overhead to your WordPress installation.

Every additional plugin forces your server to process more code on every page load, which eventually slows down your website performance.

Method 2: Disabling via .htaccess or Server Rules

If you want to avoid bloated plugins and are looking for a lightweight Wordfence alternative, server level blocking is preferred. You can block access entirely by modifying your core server configuration files.

For Apache servers, log in to your site via SFTP or your host’s file manager. Locate the .htaccess file in your root folder (typically public_html) and paste the following snippet:

<Files "xmlrpc.php">
Require all denied
</Files>

If you are running an NGINX server, you will need to add this code block to your server block instead:

location = /xmlrpc.php {
    deny all;
}

The Risk: Editing core server configuration files manually is highly risky. Missing a single bracket, using the wrong syntax, or pasting the code in the wrong section will immediately trigger a 500 Internal Server Error and take your entire website offline.

Always create a backup of your .htaccess or server block file before making any changes. If you are a Cloudways user, you can quickly create a full on demand backup in a single click from the Application Management panel.

Automated Defense Against XML-RPC Exploits: The Cloudways Malware Protection Add-on

If you host your WordPress site on Cloudways, you do not need to risk breaking your site with manual server edits. You get access to platform-level tools that block the XML-RPC entry point, filter out malicious traffic, and automatically stop malware payloads.

Catching the Payload with Malware Protection

If an attacker successfully bypasses your login limits via an XML-RPC brute force exploit, their immediate next step is dropping a backdoor onto your server. Finding these hidden scripts manually requires deep technical knowledge and wastes valuable time.

The Cloudways Malware Protection Add-on acts as your automated failsafe against these breaches. Powered by Imunify360, it operates at the OS level to harden your entire server environment.

• Active Threat Blocking: It uses runtime application self-protection (RASP) to instantly isolate hidden backdoors dropped by attackers. It stops the malicious code from executing before the hacker can take control.
• Automated Cleanup: It scans your entire server to locate hidden scripts resulting from a breach and cleans the infected code without damaging your legitimate core files.

Activating it takes just a few clicks, and the initial scan runs entirely in the background.

Step 1: Navigate to Application Security

Log into the Cloudways platform and select your target application. Click on Application Security from the left management menu.

Step 2: Turn on the Add-on

Select the Malware Protection tab and click the Enable Protection button. This activates real-time monitoring and starts a comprehensive background scan across your directories and database.

Step 3: Monitor the Results

You can track the automated cleanup across three simple tabs:

• Malicious: Shows the exact file paths of isolated threats and confirms if they were cleaned, quarantined, or removed.
• Scan History: Provides a log of past scans and allows you to trigger manual checks.
• Proactive Defense: Logs the runtime events where malicious PHP scripts were blocked from executing.

The 1-Click XML-RPC Toggle

While Malware Protection handles the dropped payloads, you should still close the XML-RPC entry point completely. Cloudways provides a built-in toggle that applies server-level rules instantly, saving you from risky .htaccess edits.

• Go to Application Settings in your dashboard.
• Under the WordPress Settings tab, find the XML-RPC toggle.
• Switch it to Disabled.

Stopping Bot Traffic at the Edge

Disabling the file stops hackers from logging in, but automated scripts will still repeatedly ping the closed endpoint. Thousands of these failed requests will continue to drain your server CPU.

The Cloudways Cloudflare Enterprise Add-on resolves this. Its enterprise-grade web application firewall acts as an edge filter. It identifies malicious traffic and blocks those XML-RPC brute-force requests before they ever reach your server.

Learn more about how edge filtering protects your resources in our WAF vs. firewall comparison.

When Do You Actually Need to Keep xmlrpc.php Enabled?

For 99% of modern WordPress websites, the answer is never.

Since the introduction of the WordPress REST API in version 4.7, almost all remote publishing tools, mobile apps, and major plugins have migrated to the newer, faster, and more secure JSON-based API.

The only time you should leave this file active is if you are dealing with a highly specific edge case:

• You are using a custom, legacy remote publishing application that has not been updated in years.
• You are running a specific, outdated plugin that explicitly requires the XML-RPC protocol to function and cannot be replaced.

A good rule of thumb: If you are not entirely sure whether you need xmlrpc.php, you do not need it. You are perfectly safe to disable it.

Wrapping Up!

The xmlrpc.php file has been around since early WordPress days, but it’s no longer relevant for most sites. Today, it mainly creates security risks by giving attackers an easy way to launch brute-force and DDoS attacks.

Leaving it open is a risk you do not need to take.

Whether you block it manually through your .htaccess file or use the 1-click toggle in your Cloudways dashboard, disabling this endpoint should be a standard part of your security checklist.

For complete peace of mind, pair this preventative step with the Cloudways Malware Protection Add-on to ensure any automated threats are caught and cleaned before they can execute.