--- title: Rethink Disabling XML-RPC for Security url: "https://pressable.com/knowledgebase/rethink-disabling-xml-rpc-for-security/" published: 2026-09-27 modified: 2026-09-27 author: Nox Dineen-Porter --- Disabling XML-RPC won’t meaningfully protect your WordPress site, and it can quietly break tools you rely on. If you’ve read a WordPress security checklist in the last decade, “disable XML-RPC” was probably near the top. That advice made sense years ago; today, the real risks are elsewhere. This article explains what XML-RPC is, why the advice caught on, and where your security efforts will actually make a difference. ## What XML-RPC Is [XML-RPC](https://codex.wordpress.org/XML-RPC_Support) is a feature built into WordPress that lets other apps and services talk to your site remotely. It lives at a single address, `example.com/xmlrpc.php`, and handles requests like “publish this post” without anyone logging into the dashboard. It predates the newer [WordPress REST API](https://developer.wordpress.org/rest-api/), and many modern tools have moved to that. Several services Pressable customers depend on still use XML-RPC, though (more on those below). ## Why People Say to Disable It Two abuse patterns made XML-RPC a popular target: - **Bulk password guessing.** XML-RPC can bundle many actions into one request using a method called `system.multicall`. Attackers used it to try hundreds of passwords per request, slipping past login limits that counted one attempt per request. - **Pingback abuse.** Pingbacks (the notice one blog sends another when linking to it) could be abused to make many sites send traffic at a single target. Disabling XML-RPC shut both down at once, so it became a checklist staple. ## Why That Advice Is Outdated WordPress [fixed the main threat in 2015](https://core.trac.wordpress.org/ticket/34336). Since WordPress 4.4, if one login attempt in a bundled request fails, every remaining attempt in that request fails too. Guessing passwords through XML-RPC no longer gives attackers an edge over the regular login page. On Pressable, every site also sits behind a [web application firewall (WAF)](https://pressable.com/features/manage/web-application-firewall/) and DDoS protection that filter abusive traffic before it reaches WordPress. You can read more about what’s handled for you in our [Quick Start Guide: Secure Your Site](https://pressable.com/knowledgebase/quick-start-guide-secure-your-site/#understand-pressable-security-layers). What’s left is a login path that behaves like any other. If an attacker has a valid password, disabling XML-RPC won’t stop them; they’ll simply use `wp-login.php` instead. ## What Disabling Can Break Turning off XML-RPC can disconnect services you depend on: - **Jetpack.** Jetpack’s connection to WordPress.com relies on XML-RPC. Without it, backups, malware scanning, and stats can stop working. Every Pressable site includes a free [Jetpack Security](https://pressable.com/knowledgebase/what-is-jetpack-security-how-to-enable/) license, so this affects nearly everyone. - **Automattic for Agencies.** If you manage client sites through the [Automattic for Agencies](https://automattic.com/for-agencies/) dashboard, its connection to your Pressable sites uses XML-RPC. - **Mobile apps.** The WordPress and Jetpack mobile apps may rely on XML-RPC to manage your site. - **Remote publishing tools.** Some desktop editors and third-party publishing services still post through XML-RPC. These failures rarely come with a clear error. A connection just stops working, sometimes weeks later, and the cause isn’t obvious. ## What Actually Gets Sites Compromised In the malware cleanups our team handles, two causes come up far more than anything else: 1. **Compromised admin credentials.** Weak, reused, or phished passwords on administrator accounts are the most common way in. An attacker with a real password doesn’t need XML-RPC; they walk in the front door. 2. **Outdated or nulled plugins and themes.** Software with known, unpatched vulnerabilities is the top technical cause. “Nulled” plugins (pirated copies of premium plugins) often ship with hidden malware or backdoors. Disabling XML-RPC addresses neither. Our [Common Vectors for Malware and How to Mitigate Them](https://pressable.com/knowledgebase/common-vectors-for-malware-and-how-to-mitigate-them/) article covers both in depth. ## Better Ways to Protect Your Site These steps close the gaps attackers actually use: - **Turn on two-factor authentication (2FA)** for every administrator account, at minimum. Even a stolen password isn’t enough to log in. - **Use strong, unique passwords** for every user, ideally stored in a password manager. - **Give users the lowest role they need.** Editors and Authors can’t install plugins, so a compromised account does far less damage. Remove admin accounts nobody uses. - **Keep plugins and themes updated**, and delete anything inactive. If you’re worried an update might break something, test it on a clone first. - **Only install software from WordPress.org or the original vendor.** Never use nulled plugins or themes. - **Turn on Jetpack Security** for malware scanning and backups. It’s included free with every Pressable site. - **Protect your hosting account, too.** Anyone with access to MyPressable can bypass WordPress entirely, so [enable 2FA in MyPressable](https://pressable.com/knowledgebase/enabling-two-factor-authentication-2fa/) and review our [best practices for securing your Pressable account ownership](https://pressable.com/knowledgebase/best-practices-for-securing-your-pressable-account-ownership/). For a step-by-step walkthrough, start with our [Quick Start Guide: Secure Your Site](https://pressable.com/knowledgebase/quick-start-guide-secure-your-site/). ## If You Still Want to Disable It Check these first. If any apply, leave XML-RPC on: - Jetpack is connected to the site. - The site is managed through Automattic for Agencies. - Anyone manages the site with the WordPress or Jetpack mobile apps. - Anyone publishes through a remote tool or service. **Seeing heavy XML-RPC traffic?** That’s usually a performance concern rather than a security one. [Contact our support team](https://pressable.com/knowledgebase/how-to-get-support-with-pressable/). We can review your server logs to confirm whether it’s a genuine attack and, if it is, help you put a targeted block in place that keeps Jetpack and Automattic for Agencies working. **A note on common snippets:** Many guides suggest adding `add_filter( 'xmlrpc_enabled', '__return_false' );` to disable XML-RPC. That filter only turns off features that require a login. The endpoint still answers other requests, including pingbacks, so it doesn’t do what most people expect.