WordPress includes an endpoint named xmlrpc.php that allows external applications to communicate with a site. It can support remote publishing and integrations, but it is also frequently targeted by automated login attempts and pingback abuse. The right decision is not “always disable it” or “always keep it.” First identify whether anything on your site still needs it.

What XML-RPC does

XML-RPC packages a remote request in XML and sends it over HTTP. WordPress has enabled the endpoint by default since version 3.5. Older mobile apps, publishing clients and some services may still rely on it. Modern integrations often use the REST API instead, but compatibility depends on the product.

Why attackers target xmlrpc.php

The endpoint can process authenticated methods, so bots may send repeated username and password attempts. Pingback functionality has also been abused to make sites send requests to other targets. Even when authentication fails, high request volume can consume PHP workers and server resources.

XML-RPC is not automatically proof that a site is compromised. The risk comes from exposed functionality, weak credentials, outdated software and inadequate rate limiting.

Do you need XML-RPC?

Use case Likely decision
You use no remote publishing or legacy integrations Disable or restrict it after testing
A mobile app or service explicitly requires XML-RPC Keep only the required access and harden authentication
You are unsure Check logs and integrations on staging before changing production
You use only the modern REST API XML-RPC may be unnecessary, but verify dependencies

How to check whether it is being used

  1. List every mobile app, automation and publishing tool connected to the site.
  2. Check the documentation for Jetpack or other services you actively use.
  3. Review web-server and security logs for legitimate requests to /xmlrpc.php.
  4. Test the intended change on a staging site.
  5. Confirm publishing, backups, management and monitoring still work.

Do not decide from bot traffic alone. A log full of attacks proves that the endpoint is being targeted, not that no legitimate integration needs it.

Safe ways to reduce the risk

Use strong authentication

Give every administrator a unique password and enable two-factor authentication where supported. Application passwords provide revocable credentials for compatible integrations. Never reuse the main admin password in multiple tools.

Follow SiteChai’s WordPress two-factor authentication guide for a safer rollout.

Restrict or disable unused methods

A security plugin or hosting firewall may restrict XML-RPC, pingbacks or the whole endpoint. Choose a maintained method that you can test and reverse. Editing .htaccess or web-server configuration incorrectly can take the site offline.

Rate-limit abusive requests

Rate limiting at a web application firewall or server layer can reduce repeated attempts before they consume application resources. Be careful not to block legitimate management tools without monitoring the effect.

Keep WordPress current

Update WordPress core, plugins and themes, remove abandoned software and use reliable backups. Disabling one endpoint does not compensate for vulnerable plugins or stolen administrator credentials.

A careful disable-and-test plan

  1. Create a current files-and-database backup.
  2. Clone the site to staging.
  3. Record all integrations and their expected actions.
  4. Disable or restrict XML-RPC using one controlled method.
  5. Test mobile publishing, Jetpack, remote management, backups and webhooks.
  6. Review logs for blocked legitimate traffic.
  7. Deploy during a low-risk period with a rollback plan.

If you host WordPress with SiteChai, ask SiteChai support which server-side protections already apply before stacking several plugins and firewall rules.

What not to do

  • Do not delete or edit the WordPress core xmlrpc.php file.
  • Do not copy web-server rules without confirming Apache, Nginx or LiteSpeed syntax.
  • Do not assume a successful HTTP response means authentication succeeded.
  • Do not expose logs containing usernames, cookies or tokens.
  • Do not disable the endpoint on production before testing required integrations.

Frequently asked questions

Is XML-RPC a virus?

No. It is a WordPress communication interface. Attackers may abuse it, just as they target login pages and other endpoints.

Does disabling XML-RPC break WordPress?

Normal front-end pages and the dashboard usually continue to work, but remote publishing or specific integrations may fail.

Is the REST API the same thing?

No. It is a newer interface with different endpoints and authentication options. A product designed only for XML-RPC will not automatically switch.

Can Cloudflare block xmlrpc.php?

A web application firewall can create rules for the path, but test carefully and preserve any legitimate access. Server-side protection may still be needed if the origin is reachable directly.

Sources: WordPress VIP XML-RPC security controls and WordPress REST API handbook.