What is XML-RPC in WordPress, and why disable it?

XML-RPC is a remote communication interface built into WordPress that allows external applications and services to perform actions on a WordPress site through HTTP requests encoded as XML.

It predates the modern WordPress REST API and was originally important for remote publishing, desktop blogging clients, mobile applications, pingbacks and integrations that needed to communicate with WordPress without using the normal browser-based admin interface.

On a standard WordPress installation, the XML-RPC endpoint is normally available at:

https://example.com/xmlrpc.php

XML-RPC itself is not malware, a backdoor or a vulnerability simply because the file exists.

The security concern is that it exposes additional remote functionality, including authenticated methods, and attackers have historically abused that functionality for automated password attacks and other unwanted traffic.

This creates an important distinction:

If your site does not need XML-RPC, disabling or restricting it can reduce unnecessary attack surface. If something legitimately depends on XML-RPC, blindly blocking it can break that functionality.

The right decision therefore depends on understanding what XML-RPC does, which parts of it your site actually uses and how it fits into the rest of your WordPress security strategy.

What is XML-RPC?

XML-RPC stands for XML Remote Procedure Call.

It is a protocol that lets one system ask another system to execute a procedure remotely.

The request is generally:

• sent over HTTP;
• encoded using XML;
• directed to an endpoint capable of interpreting XML-RPC methods.

Instead of a person opening wp-admin, clicking through the interface and publishing a post manually, an external application can send an XML-RPC request asking WordPress to perform a supported operation.

WordPress implements this through its wp_xmlrpc_server class.

The WordPress implementation supports several historical APIs and WordPress-specific methods for operations involving areas such as:

• posts;
• pages;
• comments;
• media;
• options;
• users;
• taxonomies;
• pingbacks.

XML-RPC has been enabled by default in WordPress since version 3.5.

Why remote APIs exist at all

A WordPress website is not necessarily controlled exclusively by somebody sitting in front of its normal administration dashboard.

External software may need to:

• publish content;
• retrieve content;
• upload media;
• manage comments;
• synchronize with another service;
• perform automated operations.

Today, much of that type of integration is more commonly associated with the REST API.

XML-RPC represents an older generation of remote WordPress communication, but older does not automatically mean unused.

How WordPress XML-RPC works

Requests are normally sent to xmlrpc.php.

The request specifies a method and any required parameters. WordPress parses the XML, identifies the requested method, verifies credentials where authentication is required and returns an XML response.

Authenticated methods

Some XML-RPC methods require a valid WordPress account.

For example, an external publishing client may need permission to create or edit posts.

In those situations, XML-RPC becomes another authentication surface.

The user does not necessarily interact with wp-login.php, but WordPress still needs to establish whether the supplied credentials belong to an authorized account.

Unauthenticated methods

Not every XML-RPC method requires authentication.

This distinction becomes important when administrators attempt to disable XML-RPC with the WordPress xmlrpc_enabled filter.

The official WordPress documentation for the xmlrpc_enabled filter explicitly states that the filter controls methods requiring authentication.

It does not completely shut down every possible XML-RPC method.

For example, pingback-related functionality is not necessarily disabled simply by returning false from that filter.

This means there is a difference between:

• disabling XML-RPC authentication methods;
• removing selected XML-RPC methods;
• blocking access to xmlrpc.php entirely.

Those approaches should not be described as interchangeable.

Why does WordPress still include XML-RPC?

XML-RPC exists largely for compatibility and remote communication.

WordPress has supported remote publishing for a very long time, and removing the interface entirely would break software and integrations that still depend on it.

Remote publishing

Historically, desktop blogging applications could connect to WordPress and create or edit content without requiring users to work directly inside the WordPress dashboard.

The WordPress XML-RPC server still contains compatibility for APIs such as:

• Blogger API;
• MetaWeblog API;
• Movable Type API;
• WordPress-specific XML-RPC methods.

Mobile and external services

Some applications and services have also relied on XML-RPC for communication with self-hosted WordPress installations.

Jetpack is a well-known example.

WordPress.org support documentation and Jetpack support responses continue to note that Jetpack functionality can depend on access to XML-RPC. Blocking the endpoint completely can therefore interfere with features that use that communication channel.

Legacy integrations

A custom integration built years ago may still rely on XML-RPC even if a modern replacement could now be built with the REST API.

This is why administrators should not disable the interface on production merely because a security checklist says XML-RPC is old.

First determine whether anything depends on it.

Why is XML-RPC considered a security concern?

The problem is not that XML parsing automatically gives an attacker administrator access.

The problem is that an enabled remote interface increases the number of ways external clients can interact with the site.

That additional surface has historically been attractive for automated attacks.

XML-RPC can expose password authentication

If authenticated XML-RPC methods are enabled, attackers can attempt WordPress credentials through that interface.

This means protecting only the visible login form does not necessarily protect every password-authentication path.

An administrator might add CAPTCHA protection to wp-login.php, for example, while XML-RPC authentication remains available separately.

This is one reason login security needs to consider all relevant authentication surfaces.

See WordPress Brute-Force Attacks, Explained for the broader authentication threat model.

system.multicall historically increased attack efficiency

The XML-RPC specification includes a method called system.multicall.

WordPress’s XML-RPC implementation supports multicall processing, allowing multiple method calls to be packaged into one XML-RPC request.

Historically, attackers abused multicall behavior to make password-guessing campaigns more efficient because one HTTP request could trigger several authentication attempts internally.

This matters because simple defenses that count HTTP requests may underestimate how much authentication work a request actually represents.

Modern security controls should therefore understand XML-RPC behavior rather than assuming one request always equals one password attempt.

XML-RPC can consume server resources even when attacks fail

An attacker does not need to guess a valid password to cause operational problems.

Every request may require:

• web-server processing;
• PHP execution;
• WordPress bootstrap;
• XML parsing;
• authentication logic;
• database access;
• security-plugin processing.

A large number of abusive requests can therefore contribute to server load.

The current WordPress brute-force guidance recommends protecting or disabling XML-RPC when it is unnecessary, and restricting and rate-limiting it when it must remain available.

What about XML-RPC pingbacks?

Pingbacks are another reason XML-RPC appears frequently in WordPress security discussions.

A pingback is a mechanism through which one website can notify another website that it has linked to its content.

The receiving WordPress site can then verify the link and potentially display the relationship similarly to a comment or reference.

Pingbacks involve server-to-server requests

Pingback processing may cause WordPress to make an HTTP request to another URL in order to verify that a link exists.

Historically, this functionality has been abused to generate unwanted requests and participate in distributed traffic attacks.

That does not mean every WordPress site with pingbacks enabled is automatically part of an attack.

It means the functionality increases externally triggerable behavior and deserves review if the site has no legitimate reason to use it.

Disabling authenticated XML-RPC methods does not necessarily disable pingbacks

This is one of the easiest configuration mistakes to make.

The commonly shown WordPress filter:

add_filter( 'xmlrpc_enabled', '__return_false' );

disables XML-RPC methods requiring authentication.

According to the WordPress code reference, it does not control pingbacks or every unauthenticated/custom XML-RPC method.

If the objective is to eliminate specific methods or block the endpoint completely, additional controls are required.

Should you disable XML-RPC in WordPress?

For many modern WordPress sites, XML-RPC is not required.

If your site does not use any software that depends on it, disabling unnecessary XML-RPC functionality is a reasonable hardening measure.

The security principle is straightforward:

Functionality that is not required does not need to remain exposed.

Good candidates for disabling XML-RPC

Disabling XML-RPC is generally easier to justify when:

• all content is managed through the WordPress dashboard;
• no mobile or desktop publishing client depends on XML-RPC;
• Jetpack or another dependent service is not being used;
• no custom integration requires XML-RPC;
• the REST API or another supported interface handles remote integrations;
• server logs show persistent abusive traffic against xmlrpc.php.

When you should investigate before disabling it

Do not block XML-RPC blindly if the site uses:

• Jetpack;
• a WordPress mobile workflow that depends on XML-RPC;
• legacy desktop publishing software;
• remote management services;
• custom integrations built around XML-RPC;
• third-party services whose documentation requires xmlrpc.php.

Blocking the endpoint before checking dependencies can cause silent or confusing integration failures.

How can XML-RPC be disabled or restricted?

There are several levels of XML-RPC restriction.

The correct one depends on what you want to disable.

Disable authenticated XML-RPC methods in WordPress

WordPress provides the xmlrpc_enabled filter:

add_filter( 'xmlrpc_enabled', '__return_false' );

This can be useful when the objective is to disable XML-RPC methods that require authentication.

But again, it is not a complete endpoint block.

Remove individual XML-RPC methods

WordPress also provides the xmlrpc_methods filter, allowing plugins or custom code to modify the methods registered with the XML-RPC server.

This makes more granular controls possible.

For example, a site may want to remove particular functionality while leaving another required integration available.

Granular restriction can be preferable when XML-RPC remains necessary for a legitimate service.

Block xmlrpc.php at the web-server or WAF layer

If the site does not need XML-RPC at all, the endpoint can be blocked before WordPress processes the request.

This can be done using technologies such as:

• a hosting firewall;
• a web application firewall;
• a reverse proxy;
• Apache or Nginx rules;
• a CDN security rule.

This approach has an important performance advantage.

A request rejected before PHP executes consumes fewer application resources than a request that boots WordPress and is rejected later by a plugin.

The official WordPress brute-force guidance therefore recommends edge or server-level controls where practical for high-volume abusive traffic.

Rate-limit XML-RPC instead of completely blocking it

When a legitimate integration requires XML-RPC, complete blocking may not be appropriate.

In that case, consider:

• request rate limiting;
• IP reputation controls;
• WAF rules;
• temporary blocking of abusive clients;
• removing unnecessary XML-RPC methods;
• monitoring XML-RPC authentication attempts.

This can preserve required functionality while making large-scale automated abuse more expensive.

Does disabling XML-RPC make WordPress secure?

No.

Disabling XML-RPC removes or reduces one attack surface.

It does not secure the rest of WordPress automatically.

wp-login.php still exists

Attackers can still target the standard WordPress login system.

That means you still need:

• strong unique passwords;
• login rate limiting;
• two-factor authentication;
• account monitoring;
• appropriate administrator access policies.

Use A WordPress Login Hardening Checklist to review the wider authentication strategy.

A compromised password remains compromised

If an administrator reused the same password on another breached service, disabling XML-RPC does nothing to make that password safe.

An attacker may simply authenticate through the normal login page.

Other vulnerabilities remain unrelated

XML-RPC controls do not fix:

• vulnerable plugins;
• outdated themes;
• weak hosting credentials;
• unsafe file permissions;
• malicious administrator accounts;
• database exposure;
• cross-site scripting vulnerabilities;
• arbitrary file upload vulnerabilities.

XML-RPC hardening is one security decision among many.

XML-RPC vs the WordPress REST API

WordPress today also provides a modern REST API.

Both technologies allow external software to communicate with WordPress, but they are not the same interface and should not be treated as interchangeable security controls.

XML-RPC

XML-RPC:

• uses XML-formatted requests;
• typically communicates through xmlrpc.php;
• has existed in WordPress for many years;
• supports historical remote-publishing APIs;
• may still be required by legacy integrations and services.

REST API

The WordPress REST API:

• uses HTTP endpoints under the REST API namespace;
• normally exchanges JSON;
• is extensively used by modern WordPress functionality;
• supports modern plugin and application integrations;
• has its own authentication and authorization model.

Disabling XML-RPC does not disable the REST API.

Likewise, disabling or restricting REST functionality does not automatically close XML-RPC.

For modern API security, see WordPress REST API Security Basics.

Do not disable the REST API simply because XML-RPC can be disabled

The two interfaces have very different roles in modern WordPress.

The Block Editor and many plugins rely heavily on REST API functionality.

A blanket REST API shutdown can therefore break normal WordPress behavior.

Security decisions should be based on the actual functionality exposed, authentication model and site requirements rather than the assumption that every API is inherently dangerous.

How to determine whether your site needs XML-RPC

Before disabling anything, perform a dependency check.

Check installed plugins and services

Identify whether any plugin or external platform documents an XML-RPC requirement.

Pay particular attention to:

• Jetpack;
• remote publishing tools;
• site-management platforms;
• mobile applications;
• legacy integrations.

Inspect traffic to xmlrpc.php

Web-server, CDN and WAF logs can reveal whether XML-RPC is receiving traffic.

Look at:

• request volume;
• source IP addresses;
• POST frequency;
• response status;
• known legitimate service IPs;
• patterns associated with repeated authentication.

High traffic does not automatically mean XML-RPC is legitimately used.

Many sites receive automated requests simply because bots scan for the endpoint.

Test in staging

If you are uncertain, disable or restrict XML-RPC in a staging environment first.

Then test:

• publishing workflows;
• Jetpack connectivity;
• mobile applications;
• remote monitoring;
• external integrations;
• scheduled automation.

Production is a poor environment for discovering that a client’s obscure eight-year-old integration was apparently vital after all.

How TheOneWP fits into XML-RPC hardening

TheOneWP includes tools that can participate in a broader WordPress authentication and attack-surface strategy.

XML-RPC controls

TheOneWP can be used to control XML-RPC exposure when a site does not need the interface.

The important operational principle remains the same: confirm that no required integration depends on XML-RPC before blocking it.

Access Manager

Access Manager provides controls around authentication attempts and IP-based access behavior.

This complements XML-RPC hardening because attackers may target several authentication paths rather than only the visible login form.

Application-level blocking can help control authentication abuse, while high-volume traffic should ideally also be addressed at the CDN, WAF or server layer.

Two-Factor Authentication

Two-Factor Authentication adds a second factor to supported interactive WordPress authentication.

This addresses a different layer of the problem.

Disabling XML-RPC reduces exposure. Two-factor authentication reduces the value of a compromised password.

Custom Login URL and Restrict Login Identifier

Custom Login URL can reduce automated traffic aimed at the predictable default login URL, while Restrict Login Identifier controls the type of identifier accepted during the site’s supported login workflow.

Neither replaces strong passwords, 2FA or request throttling.

The value comes from combining independent defensive layers.

XML-RPC security checklist

• Determine whether any active integration genuinely requires XML-RPC.
• Check Jetpack, mobile publishing tools and remote-management services before disabling it.
• Review traffic to xmlrpc.php in server, CDN or WAF logs.
• Disable XML-RPC authentication methods if remote authentication is unnecessary.
• Remember that xmlrpc_enabled does not completely disable all XML-RPC functionality.
• Review pingback requirements separately.
• Remove unnecessary XML-RPC methods when granular control is preferable.
• Block xmlrpc.php at the edge or web-server layer if the endpoint is completely unnecessary.
• Rate-limit XML-RPC when legitimate services still need access.
• Use WAF rules to reduce abusive requests before they reach PHP.
• Monitor system.multicall and repeated authentication patterns where applicable.
• Use strong, unique passwords for WordPress accounts.
• Enable two-factor authentication for privileged accounts.
• Limit unnecessary Administrator accounts.
• Monitor successful as well as failed authentication.
• Do not treat XML-RPC disabling as a complete WordPress security strategy.
• Do not disable the REST API simply because XML-RPC is unnecessary.
• Test XML-RPC restrictions in staging when site dependencies are unclear.
• Document exceptions for integrations that require continued XML-RPC access.
• Keep WordPress core, plugins and themes updated.

Related guides

• WordPress Brute-Force Attacks, Explained
• A WordPress Login Hardening Checklist
• How to Limit Login Attempts in WordPress
• How to Monitor WordPress Login Attempts
• How Attackers Collect WordPress Usernames and Email Addresses
• WordPress REST API Security Basics
• WordPress Login: Username vs. Email, Which Is More Secure?
• How to Audit User Roles on a WordPress Site
• WordPress User Roles and Capabilities Explained
• Detecting Spam Registrations on WordPress

Final recommendation

XML-RPC is a legitimate WordPress remote communication interface, not an automatic vulnerability.

Its security problem is simpler: it provides functionality that many modern WordPress sites no longer need, and unnecessary remotely accessible functionality creates unnecessary attack surface.

If nothing on your site requires XML-RPC, restricting or disabling it is a sensible hardening step.

If Jetpack, a mobile client or another integration still depends on it, keep the required functionality available and protect it with appropriate rate limiting, WAF rules, monitoring and strong authentication.

Most importantly, understand what your chosen disabling method actually does.

The WordPress xmlrpc_enabled filter disables authenticated XML-RPC methods. It does not automatically eliminate pingbacks or every other method available through the endpoint.

If your security objective is to prevent all requests from reaching xmlrpc.php, blocking the endpoint at the web-server, proxy, CDN or WAF layer is a different and stronger control.

XML-RPC should also remain only one part of the site’s security model.

Strong unique passwords, two-factor authentication, least-privilege accounts, login throttling, traffic monitoring and regular updates remain necessary whether XML-RPC is enabled or disabled.

The practical rule is therefore straightforward:

Keep XML-RPC only when the site has a reason to use it. If it has no job, it does not need to remain an externally reachable authentication and remote-procedure surface.