Check whether xmlrpc.php is publicly reachable, restricted, or blocked.
WordPress XML-RPC Security Risk
WordPress XML-RPC security risk is a common vulnerability that can expose your site to brute-force attacks and DDoS abuse. If XML-RPC is enabled and not properly restricted, attackers can exploit it to gain access or overload your site.
This page explains what XML-RPC exposure means, why it matters, and how PreFlight evaluates the result before launch or handoff.
Why it matters
XML-RPC was originally useful for remote publishing and external integrations, but today it is also a common point of review in WordPress security. If xmlrpc.php remains accessible without a clear need, it can increase the attack surface of the site and create unnecessary risk before launch.
This matters because exposed XML-RPC endpoints have long been associated with brute force abuse, pingback abuse, and other automated attacks. In many modern WordPress setups, the feature is no longer essential, so keeping XML-RPC restricted or blocked is usually the safer default, while leaving it accessible should be a deliberate technical decision.
What to review
Before marking this check as correct, review the following points:
Confirm whether the site genuinely needs XML-RPC for remote publishing or external tools.
Review whether access is properly restricted, blocked, or intentionally left available for a real use case.
Make sure XML-RPC is not left exposed by default when restriction would be the safer normal state.
If the endpoint remains enabled, confirm that the decision matches the site's real technical needs.
How PreFlight checks this check
PreFlight requests the public XML-RPC endpoint and verifies whether it is reachable, restricted, or blocked from the outside. The goal is to identify whether xmlrpc.php remains accessible as part of the live site setup or has already been limited as expected.
This check does not decide for you whether XML-RPC should be enabled in every case. Instead, it helps confirm whether the endpoint is appropriately restricted by default or left available for a legitimate technical reason as part of the site's security and launch readiness.
PASS / WARN / FAIL
XML-RPC is restricted or blocked publicly, or its availability is clearly intentional and aligned with a legitimate technical requirement.
The endpoint is still accessible and may be valid for the project, but it should be reviewed before delivery because XML-RPC is often left enabled by default when restriction would be more appropriate.
XML-RPC is publicly accessible in a way that creates avoidable risk, with no clear indication that the site actually needs it in production.
Common mistakes
Leaving xmlrpc.php exposed by default without checking whether it is needed.
Assuming XML-RPC is harmless just because the site already uses HTTPS.
Forgetting that older features like pingbacks can increase abuse risk.
Disabling login brute force on /wp-login.php but ignoring XML-RPC as another access point.
Treating XML-RPC as a harmless legacy file instead of an active public endpoint.
FAQ
Should XML-RPC always be disabled?
Not always. Some sites still rely on it for specific integrations or remote publishing workflows, but in many modern WordPress installations restricting or blocking XML-RPC is the safer default when there is no clear need to keep it available.
Why is XML-RPC considered a security concern?
Because exposed XML-RPC endpoints have been associated with brute force attempts, pingback abuse, and other automated attacks against WordPress sites.
Is this the same as the REST API?
No. XML-RPC is an older remote communication mechanism. In many current WordPress setups, the REST API has replaced the need for XML-RPC in day-to-day use.
Check your WordPress site before delivery
Reduce rework, catch last-minute issues and review critical points before launch.