xmlrpc.php WordPress: The Hidden Gateway Hackers Use — And How to Close It

Author: SEO Editorial Team  |  Last Updated: July 2026  |  Read Time: 12 min

Key Takeaways at a Glance

• xmlrpc.php is not a plugin — it's a built-in WordPress core file that enables remote API communication since WordPress 3.5.
• It is the #1 targeted file for brute-force and DDoS attacks against WordPress sites (OWASP, Wordfence threat reports 2023–2025).
• You can safely disable xmlrpc.php on 95%+ of sites without breaking any core functionality.
• Only disable it if you actively use the WordPress mobile app, JetPack, or third-party site management tools that rely on XML-RPC.
• Disabling via .htaccess or web server config is more reliable than plugins alone — combine methods for defense in depth.

What Is xmlrpc.php in WordPress?

The Short Answer

xmlrpc.php is a legacy WordPress core endpoint that implements the XML-RPC protocol — a remote procedure call standard using XML to encode method calls over HTTP. Introduced as a full feature in WordPress 3.5 (2013), it allows external applications to interact with your WordPress installation without logging into the admin dashboard.

What It Was Designed For

The critical insight: Most modern WordPress sites do not need xmlrpc.php. The REST API (/wp-json/) has replaced most of its original functions. Yet the file remains active by default on every fresh install, exposing a surface that attackers scan for automatically.

Why Is xmlrpc.php a Security Risk?

1. Brute-Force Authentication Attacks (Most Common)

The wp.getUsersBlogs and wp.signon methods accept username/password pairs over XML. Attackers send thousands of credential combinations per minute from botnets. Unlike the /wp-login.php page, there is no built-in rate limiting on xmlrpc authentication calls in WordPress core.

Wordfence threat data shows xmlrpc.php accounts for over 40% of all WordPress brute-force attempts in 2024 — up from 22% in 2022, as attackers pivot away from the increasingly well-protected login page.

2. Pingback DDoS Amplification

The pingback.ping method creates a reflection attack: an attacker tricks your server into sending a request to a victim, making it appear your server initiated the traffic. This was the mechanism behind several major DDoS events (2016 Mirai variant, 2020 WordPress DDoS botnet). A single xmlrpc request can generate amplification ratios of 10:1 to 100:1.

3. Credential Harvesting & Information Disclosure

Methods like wp.getUsers can reveal user account structures, blog IDs, and role information to unauthenticated callers. Even when password-protected endpoints leak existence of valid usernames through response timing differences (a technique called timing side-channel enumeration).

4. Server Resource Exhaustion

A single xmlrpc pingback call spawns multiple PHP processes, database queries, and HTTP outbound connections. Sustained xmlrpc flood attacks can consume CPU, memory, and network bandwidth — causing legitimate traffic to fail even without a full DDoS.

How to Tell If xmlrpc.php Is Active on Your Site

Quick Check (No Plugin Required)

1. Navigate to https://yourdomain.com/xmlrpc.php
2. If you see an XML response starting with <methodResponse> — the endpoint is live
3. If you see a 404 Not Found — it is already disabled or your server blocks it
4. If you see a 403 Forbidden — your web server is rejecting the request

Check for Attack Traffic

# Look for xmlrpc.php entries in your web server access logs:
grep 'xmlrpc.php' /var/log/nginx/access.log | wc -l
grep 'xmlrpc.php' /var/log/apache2/access.log | wc -l

# Check for high-volume authenticated POST requests (brute-force indicator):
grep 'POST /xmlrpc.php' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

WordPress Dashboard Check

Install a security plugin like Wordfence or Shield Security — both display xmlrpc.php status prominently in their dashboard and log detected attacks in real time.

How to Disable xmlrpc.php (Step-by-Step)

Method 1: .htaccess (Apache) — Most Reliable

Add these lines to your .htaccess file in the WordPress root directory:

# Block xmlrpc.php entirely
<Files xmlrpc.php>
    Require all denied
</Files>

Pros: Works at the web server level before PHP even loads. No plugin dependency. Survives WordPress core updates.Cons: Only applies to Apache. Requires AllowOverride to be enabled.

Method 2: Nginx Configuration

location ~* ^/xmlrpc\.php$ {
    deny all;
    return 403;
}

Pros: Same server-level protection. Clean and explicit.Cons: Requires nginx config access (not available on shared hosting without custom config).

Method 3: WordPress Function (functions.php or Custom Plugin)

// Disable xmlrpc.php completely
add_filter('xmlrpc_enabled', '__return_false');

Pros: Works across all server types. No config file editing needed.Cons: