# Disable XML-RPC In WordPress
1. [Home](https://mysites.guru/)
2. [Tools](https://mysites.guru/tools/)
3. [WordPress configuration](https://mysites.guru/tools/wordpress-configuration/)
4. Disable XML-RPC In WordPress
# Disable XML-RPC In WordPress
Block xmlrpc.php in WordPress with one .htaccess or nginx rule. Why XML-RPC is a brute-force and pingback target, and when Jetpack or the apps still need it.
## Quick answer
If you don't use Jetpack or remote publishing from the WordPress mobile apps, block xmlrpc.php at the web server so requests never reach WordPress. On Apache add this to .htaccess. If you do need it, disable just pingback.ping and system.multicall instead.
```apache
Require all denied
```
Article Contents
- [How the xmlrpc.php check tests your site](#how-the-xmlrpcphp-check-tests-your-site)
- [The two ways xmlrpc.php gets abused](#the-two-ways-xmlrpcphp-gets-abused)
- [Blocked entirely, or trimmed to what you use](#blocked-entirely-or-trimmed-to-what-you-use)
- [Blocking xmlrpc.php or trimming its methods](#blocking-xmlrpcphp-or-trimming-its-methods)
- [Disabling XML-RPC on all connected sites](#disabling-xml-rpc-on-all-connected-sites)
- [Further Reading](#further-reading)
- [Frequently Asked Questions](#faq)
How common is this?
- 48.9% of the WordPress sites we have this data for fail this check. Platform: WordPress.
Measured across the sites we audit, on each site's most recent snapshot.
## How the xmlrpc.php check tests your site
This check requests `xmlrpc.php` on your site and checks whether it’s still reachable and responding to XML-RPC calls. A site that has blocked or disabled the endpoint, whether at server level or through a plugin filter, passes. A site where the file responds normally fails, whether or not you’re aware the feature exists on your install.
## The two ways xmlrpc.php gets abused
XML-RPC is a protocol for remote procedure calls, and `xmlrpc.php` is the single file WordPress uses to implement it. Every request to that one endpoint can trigger any of dozens of WordPress methods: creating a post, uploading media, editing a comment, or authenticating a user, all specified inside the request body rather than through separate URLs. That design is exactly what made it useful for early desktop blogging software, and it’s still what the Jetpack plugin and WordPress’s official mobile apps lean on today.
The same design is also what makes it a persistent target. Two problems come up repeatedly:
**Brute-force amplification.** XML-RPC supports a method called `system.multicall`, which bundles many separate method calls into a single HTTP request. An attacker can pack hundreds of username and password combinations into one request instead of sending hundreds of individual login attempts. Most simple rate-limiting counts requests, not the login attempts hidden inside them, so this sails straight past defences that would otherwise catch a conventional brute-force attack against `wp-login.php`.
**Pingback abuse.** The `pingback.ping` method lets one site notify another that it’s been linked to. Attackers have used it to make WordPress sites unknowingly participate in denial-of-service attacks against a third party: they ask thousands of vulnerable sites to “pingback” a single target URL simultaneously, and each site’s server dutifully makes an outbound request on the attacker’s behalf. Your site becomes part of someone else’s attack, using your server’s resources and, potentially, your IP reputation.
Neither of these is a theoretical risk. Both are attack patterns that show up in server logs on a scanned-and-forgotten XML-RPC endpoint within days of it being left exposed. If you’ve never looked, checking your access logs for repeated `POST /xmlrpc.php` requests, particularly clustered bursts from the same handful of IP addresses, is usually enough to confirm the endpoint is already being probed on your site, whether or not anything has succeeded yet.
Automated scanners look for `xmlrpc.php` on essentially every WordPress install they find, not just ones that have shown any other sign of weakness, because the file’s presence alone is the trigger. It doesn’t matter how obscure your site is or how little traffic it gets. If it’s running WordPress with the endpoint reachable, it’s on the list.
## Blocked entirely, or trimmed to what you use
If you don’t use Jetpack and don’t rely on remote publishing through the mobile apps, the endpoint should be blocked entirely. If you do use either, the more targeted fix is disabling the specific methods responsible for the abuse, `pingback.ping` and `system.multicall`, while leaving the rest of XML-RPC working for the features that need it.
## Blocking xmlrpc.php or trimming its methods
**Option A: block it completely**, if nothing on the site uses XML-RPC. Add this to your `.htaccess` file in the site root:
```apache
Require all denied
```
On nginx, inside your server block:
```nginx
location = /xmlrpc.php {
deny all;
}
```
**Option B: disable it through WordPress itself**, which is easier to reverse and doesn’t require server access. Add this to your theme’s `functions.php` or a small site-specific plugin:
```php
add_filter( 'xmlrpc_enabled', '__return_false' );
```
**Option C: keep XML-RPC, but remove only the risky methods**, if you rely on Jetpack or the mobile apps and want to keep them working:
```php
add_filter( 'xmlrpc_methods', function ( $methods ) {
unset( $methods['pingback.ping'] );
unset( $methods['system.multicall'] );
return $methods;
} );
```
1. Check whether you actually use Jetpack or remote publishing through a mobile app before choosing an option. If you don’t, Option A or B is the simpler, more complete fix.
2. Apply the relevant snippet.
3. Confirm the change: request `https://yoursite.com/xmlrpc.php` directly. A blocked endpoint returns a 403; a disabled-but-reachable one returns an XML-RPC fault message rather than the normal server description.
4. If you use Jetpack, check it still connects correctly after the change, particularly if you chose Option A or B rather than C.
5. If you went with Option C and kept XML-RPC partially available, check your access logs again a week or two later to confirm the volume of `POST /xmlrpc.php` traffic has actually dropped. Scanners that were finding login and pingback methods available will usually move on once those specific calls start failing.
## Disabling XML-RPC on all connected sites
mySites.guru checks every connected WordPress site for a reachable XML-RPC endpoint on each snapshot, twice a day, and can disable it with one click across every connected site at once, rather than editing each one by hand.
## [Disable XML-RPC In WordPress](https://mysites.guru/free-audit/?check=wordpress/wordpressconfiguration/disablexmlrpc)
mySites.guru checks every connected site for this automatically and flags it the moment it appears. These run twice a day on every connected site.
It can also fix this across every connected site with one click.
[Check your site for free](https://mysites.guru/free-audit/?check=wordpress/wordpressconfiguration/disablexmlrpc)
## Further Reading
- [WordPress.org: XML-RPC support page](https://developer.wordpress.org/apis/xml-rpc/)
WordPress.org's own XML-RPC documentation covers exactly which features depend on it.
## Frequently Asked Questions
Show all
What is xmlrpc.php actually for?
It's a single file that implements the XML-RPC protocol, an older standard for making remote procedure calls over HTTP. WordPress uses it to let external applications, historically desktop blogging clients, and today mostly the Jetpack plugin and the official mobile apps, authenticate and publish content without going through the normal wp-admin login form.
Will disabling XML-RPC break Jetpack or the WordPress mobile app?
It can. Jetpack has historically relied on XML-RPC to connect a site to WordPress.com, and the mobile apps have used it for remote publishing. Check whether you actually use either before disabling it wholesale, and consider the pingback-only fix below if you need to keep the rest working.
Why is XML-RPC specifically a brute-force risk?
Its system.multicall method lets a single HTTP request bundle up hundreds of separate method calls, including login attempts. An attacker can test hundreds of username and password combinations in one request instead of hundreds of separate ones, which sails straight past simple rate-limiting or fail2ban rules built around counting individual login requests.
[Written and edited by a human, with AI assistance. Our approach to AI](https://mysites.guru/ai-statement/)
### Article Contents
- [How the xmlrpc.php check tests your site](#how-the-xmlrpcphp-check-tests-your-site)
- [The two ways xmlrpc.php gets abused](#the-two-ways-xmlrpcphp-gets-abused)
- [Blocked entirely, or trimmed to what you use](#blocked-entirely-or-trimmed-to-what-you-use)
- [Blocking xmlrpc.php or trimming its methods](#blocking-xmlrpcphp-or-trimming-its-methods)
- [Disabling XML-RPC on all connected sites](#disabling-xml-rpc-on-all-connected-sites)
- [Further Reading](#further-reading)
- [Frequently Asked Questions](#faq)
- **Published** - 28 August 2026
- **Applies to** - WordPress
- **One-click fix** - Yes, in mySites.guru
Share
[](https://x.com/intent/post?url=https%3A%2F%2Fmysites.guru%2Ftools%2Fwordpress-configuration%2Fdisable-xmlrpc%2F&text=Disable%20XML-RPC%20In%20WordPress)[](https://bsky.app/intent/compose?text=Disable%20XML-RPC%20In%20WordPress%20https%3A%2F%2Fmysites.guru%2Ftools%2Fwordpress-configuration%2Fdisable-xmlrpc%2F)[](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fmysites.guru%2Ftools%2Fwordpress-configuration%2Fdisable-xmlrpc%2F)
Topics
[WordPress configuration](https://mysites.guru/tools/wordpress-configuration/)WordPress
★★★★★
> "[Updating all my sites at once](https://mysites.guru/blog/how-to-update-joomla-joomla-extensions-wordpress-and-wordpress-plugins-from-mysites-guru/) and [monitoring everything](https://mysites.guru/blog/uptime-monitoring-explained/) and being on top of [vulnerabilities](https://mysites.guru/blog/security-audit-tools/). This saves me so much time. I love mySites.guru"
Edwin WitloxScorpion Computers & Software
[](https://mysites.guru/reviews/)
## More checks in [WordPress configuration](https://mysites.guru/tools/wordpress-configuration/)
- [
### Disable File Editing With DISALLOW\_FILE\_EDIT
Add define( 'DISALLOW\_FILE\_EDIT', true ); to wp-config.php to remove the plugin and theme file editor from wp-admin. What it blocks and what it doesn't.
](https://mysites.guru/tools/wordpress-configuration/disallow-file-edit/)
- [
### Block Plugin Installs With DISALLOW\_FILE\_MODS
define( 'DISALLOW\_FILE\_MODS', true ); blocks plugin and theme installs, updates and deletes in wp-admin, including WordPress's automatic security updates.
](https://mysites.guru/tools/wordpress-configuration/disallow-file-mods/)
- [
### Let Search Engines Index The Site
"Discourage search engines from indexing this site" in Settings > Reading keeps crawlers away. How to switch it off, and why to check robots.txt too.
](https://mysites.guru/tools/wordpress-configuration/search-engine-visibility/)
## More from the blog
[
### Deep Security Audit for WordPress & Joomla
Surface-level scanners miss hidden malware. File-level audits check every line of code against 1,500+ patterns to find backdoors other tools miss.
](https://mysites.guru/blog/security-audit-tools/)
## See where your own sites stand
One free audit of one site · no card · about 2 minutes to connect
[Get Your Free Site Audit](https://manage.mysites.guru/en/register)
[How the xmlrpc.php check tests your site](#how-the-xmlrpcphp-check-tests-your-site) [The two ways xmlrpc.php gets abused](#the-two-ways-xmlrpcphp-gets-abused) [Blocked entirely, or trimmed to what you use](#blocked-entirely-or-trimmed-to-what-you-use) [Blocking xmlrpc.php or trimming its methods](#blocking-xmlrpcphp-or-trimming-its-methods) [Disabling XML-RPC on all connected sites](#disabling-xml-rpc-on-all-connected-sites) [Further Reading](#further-reading) [Frequently Asked Questions](#faq)