WordPress XML-RPC enables remote publishing, mobile apps, pingbacks, and some integrations through xmlrpc.php. It is also targeted for password guessing and pingback abuse. The correct control depends on whether the site actually needs it.
Inventory Real Use
Check access logs for legitimate XML-RPC clients, plugin documentation, mobile publishing, Jetpack-like services, and external automation. A successful request in the logs should map to an owner and purpose. Do not block the endpoint first and discover later that backups or publishing relied on it.
Disable It When Unused
If no workflow needs XML-RPC, block xmlrpc.php at the web server, WAF, or supported security plugin. Return a consistent denied response and monitor for attempted access. Test the site, scheduled integrations, and remote management after the change.
Restrict It When Required
Prefer allowlisting known service addresses where they are stable. Otherwise apply rate limits, bot controls, strong account passwords, MFA where the integration supports application passwords, and alerts for repeated failures. Use dedicated least-privilege publishing accounts rather than a primary administrator.
Control Pingbacks Separately
Pingbacks can be abused to make a site send requests to third parties. Disable pingback functionality if it has no editorial value, even when other XML-RPC methods remain required. A method-level control is safer than leaving every capability open for one integration.
Use Application Passwords Carefully
Create a unique application password for each named integration when supported. Store it in a secret manager, transmit it only over HTTPS, and revoke it when the integration is retired. Do not reuse the normal WordPress password in scripts or configuration repositories.
Monitor Logs and False Blocks
Record timestamp, source, method where visible, response, user agent, and rate. Distinguish credential attacks from a broken legitimate client retrying. Keep WAF exceptions narrow by endpoint, source, and method. Our ModSecurity log guide explains evidence-based exclusions.
Set an alert for an unusual rise in requests, authentication failures, or successful use by a source that has never used the integration. Retain enough history to compare normal publishing schedules with attack bursts, but avoid storing request bodies that may contain credentials or private content.
Protect the Supporting Account
The endpoint is only one part of the risk. Give the publishing account the lowest role that can complete its task, prevent interactive administrator use where possible, and review its posts and sessions. If an automation host is compromised, revoke its application password and issue a new secret only after cleaning the host.
Use HTTPS exclusively and verify certificate validation in the client. A rate limit cannot protect a credential sent through an untrusted connection. Document who can rotate the credential and how service is restored without temporarily granting administrator access.
Test the Policy
- Back up configuration and keep an admin session.
- Run the legitimate integration and record success.
- Apply the narrow control.
- Repeat the legitimate action.
- Verify that an unauthorized source or method is denied.
- Check logs and alerts, then document rollback.
Frequently Asked Questions
Does XML-RPC need to be enabled for normal visitors?
No. Normal browsing and wp-admin publishing do not require it, but specific apps and services may.
Will renaming xmlrpc.php secure it?
No. It can break updates and integrations, and scanners may discover alternate paths. Use supported server or application controls.
Is blocking all POST requests safe?
No. WordPress forms, APIs, admin actions, and webhooks use POST. Scope any rule to the endpoint and required behavior.
Final Policy
Unused XML-RPC should be disabled. Required XML-RPC should have named owners, least-privilege credentials, narrow method or source access, rate limits, protected logs, and a tested revocation path.
