Shut the door on WordPress's oldest remote interface
Disable XML-RPC closes xmlrpc.php completely, blocking it before WordPress's own XML-RPC server produces any output, with a custom 404 page replacing the request entirely.
- Blocked at init, before WordPress's XML-RPC server even starts.
- Two additional native filters back up the block as a fallback.
- A fully customizable 404 page replaces the default response.
- Closes off the multicall brute-force amplification method specifically.
404 page template
Customize the HTML shown when xmlrpc.php is accessed. Use {home_url} as a placeholder.
What does Disable XML-RPC do?
When the disable_xmlrpc module is active, TOWP_Disable_Xmlrpc checks the XMLRPC_REQUEST constant, which WordPress defines at the very start of xmlrpc.php before plugins even load, on the init hook at priority 1. If the request is genuinely an XML-RPC request, it terminates immediately with a 404 status and a customizable HTML page, before WordPress's own XML-RPC server does anything at all. As a second and third line of defense, the module also forces the native xmlrpc_enabled filter to false and empties the list of registered methods via xmlrpc_methods, so both GET and POST requests to xmlrpc.php get blocked.
XML-RPC is still enabled by default, on almost every WordPress site
Since XML-RPC ships enabled by default, most sites carry the exposure without anyone having made a deliberate decision about it.
It accepts login attempts without a login form's rate limiting
XML-RPC authenticates requests the same way the login form does, but without the same throttling most sites apply to repeated failed attempts through wp-login.php.
Its multicall support lets many passwords be tried in one request
A single XML-RPC request can bundle dozens or hundreds of login attempts together through the system.multicall method, which can bypass protections that only count separate requests.
Blocked before WordPress's own server ever starts
The module intercepts the request at the earliest reliable point, backed by two further layers in case anything reaches further.
Terminated before any XML-RPC code runs
The request gets stopped on init, before WordPress's own XML-RPC server initializes or produces a single byte of output.
Two additional native filters, as backup
xmlrpc_enabled forced to false and every registered method emptied out, in case a request somehow reaches that far.
A real 404 page, not XML-RPC's own fault response
Instead of WordPress's default XML-RPC error output, a proper, customizable 404 HTML page answers the request.
Three layers, not one
Every capability below is present in the supplied PHP class, its response template and the settings registration.
Blocked on init, priority 1
Checks the XMLRPC_REQUEST constant, set at the very top of xmlrpc.php before any plugin even loads, making the check reliable and impossible to spoof through request data.
Not just the multicall vector
A GET request, which WordPress would otherwise answer with a generic "POST requests only" message, gets the same 404 treatment as a POST attempt.
The native WordPress kill switch, always set
The standard filter most other approaches rely on as their only defense gets set here too, as a second layer rather than the sole one.
xmlrpc_methods returns nothing
Even if a request somehow reached WordPress's method dispatch, there would be no registered method left to call.
Editable Visual or Code, with a homepage placeholder
The 404 page's body content can be rewritten entirely, with a {home_url} placeholder that resolves to the site's actual homepage address.
noindex, nofollow on the response page
The custom 404 page includes its own robots meta tag, so it never ends up in search results even if something links to xmlrpc.php directly.
Where disabling XML-RPC helps most
The module supports any site that doesn't genuinely depend on the legacy interface.
Sites that don't use pingbacks or legacy remote tools
Close off XML-RPC entirely on the large majority of sites where nothing actually depends on it.
Sites already dealing with brute-force login attempts
Remove multicall as an amplification method for exactly the kind of attack that targets login endpoints.
Client sites where the exact remote-access needs are unclear
Close a legacy interface by default, with a customizable message ready if anyone asks what happened to it.
An entire surface removed, layered protection behind it
The module combines a real attack-surface reduction with a response that looks intentional rather than broken.
Stopped early, nothing else runs
The verified implementation avoids any XML-RPC-specific processing for a blocked request.
One constant check, as early as possible
The block runs at the very first opportunity WordPress offers, avoiding any further processing for a request that's going nowhere.
No effect on any other request
Since the XMLRPC_REQUEST check only matches genuine XML-RPC requests, ordinary page loads are entirely unaffected.
No XML-RPC server initialization at all
Since the request terminates before the server starts, none of its usual setup work happens for a blocked request.
Defense in depth, not a single point of failure
The code closes the multicall brute-force path with a check that can't be forged, backed by further layers.
Closes the multicall brute-force amplification path
Bundling many login attempts into a single request stops being possible once xmlrpc.php itself is unreachable.
Reliable detection that can't be spoofed
The XMLRPC_REQUEST constant is set by WordPress core itself before plugins load, not derived from anything in the request that could be forged.
Defense in depth, not a single point of failure
Even if the early block were somehow bypassed, the native filter and the emptied method list still stand in the way.
Configuration requires the same access as any other setting
Enabling the module and editing the response page happen through the standard TheOneWP settings screen, available only to an administrator.
Built directly around WordPress's own XML-RPC internals
The supplied code integrates through APIs present in WordPress core; this page makes no compatibility claim beyond the verified implementation.
XMLRPC_REQUEST constant
The WordPress core constant defined at the very start of xmlrpc.php, before plugins load, used to reliably detect a genuine XML-RPC request.
xmlrpc_enabled filter
The standard WordPress filter for disabling XML-RPC support, used here as a backup rather than the primary mechanism.
xmlrpc_methods filter
The native filter used to control which XML-RPC methods are registered and callable at all.
TheOneWP versus common alternatives
Compare the verified Disable XML-RPC implementation with a typical single-filter approach.
| Capability | TheOneWP Disable XML-RPC | Other common solutions |
|---|---|---|
| Blocking mechanism | Blocked at init, before the server starts, plus two filter-based backups | Frequently rely on the xmlrpc_enabled filter alone |
| GET request handling | Same 404 treatment as POST | Some approaches only address POST-based attacks |
| Response page | A real, customizable 404 HTML page | Often WordPress's own generic XML-RPC fault message |
| Reliability of detection | Based on a core-defined constant, not request data | A filter-only approach can miss requests that reach XML-RPC's dispatch differently |
| Administration | One toggle plus an editable response template | Usually a single on/off switch with no response customization |
Close xmlrpc.php in four steps
Confirm the block with a direct visit before considering it done.
Enable Disable XML-RPC
Activate the module from the TheOneWP Components settings tab.
Customize the response page, if wanted
Edit the 404 page's HTML using the Visual or Code editor, with {home_url} available as a placeholder.
Save the template
Save the customized response, or leave the default 404 message in place.
Visit xmlrpc.php to confirm
Load the site's xmlrpc.php address directly and confirm it now returns the custom 404 page.
Confirm the tradeoff before closing the door
Disabling XML-RPC is safe for most sites, but a quick check first avoids surprises.
Confirm nothing on the site actually relies on XML-RPC
Check for pingback usage or older remote-publishing tools before disabling, even though most sites have no dependency on it.
Keep the default 404 message if there's no specific reason to change it
The built-in response is already a clean, generic 404 page; customizing it is optional, not required.
Use the {home_url} placeholder rather than hardcoding a link
A placeholder stays correct automatically if the site's domain or URL structure ever changes.
Recheck xmlrpc.php after any major site migration
Confirm the block still returns the expected 404 after moving the site or changing its configuration.
Avoid the details that catch people off guard
A couple of assumptions are worth double-checking before and after enabling the module.
Disabling it without checking for a real dependency
A site using pingbacks or an older mobile publishing app may notice a real functionality loss; confirm nothing depends on it first.
Assuming raw HTML in the template needs to bypass sanitization
The saved template goes through wp_kses_post, so scripts and unsupported markup won't be preserved even if entered.
Forgetting the {home_url} placeholder exists
Hardcoding the site's URL directly in the template works but won't update automatically if the address ever changes.
Disable XML-RPC FAQ
These answers come directly from the verified class, its response template and the settings registration.
What does Disable XML-RPC do?
It closes xmlrpc.php completely, terminating the request with a customizable 404 page before WordPress's own XML-RPC server produces any output.
Does this block both GET and POST requests to xmlrpc.php?
Yes. Both get the same 404 response, rather than WordPress's default GET message or normal POST handling.
Why is XML-RPC considered a security risk?
Its multicall support lets many login attempts be bundled into a single request, which can bypass protections that only count separate requests.
Will this break pingbacks or older remote-publishing tools?
Yes, if anything on the site actually depends on XML-RPC; on most sites nothing does, but it's worth confirming before disabling.
Can I customize the page visitors see when XML-RPC is blocked?
Yes. The response page's HTML can be edited with a Visual or Code editor, with a {home_url} placeholder available.
What happens if I don't customize the response page?
A default 404 message is shown instead, with no further configuration needed.
Is the block reliable, or could a request bypass it?
The primary block relies on a constant WordPress core defines before plugins even load, backed up by two additional native filters as further layers.
Does this affect the REST API or other WordPress features?
No. The module only affects xmlrpc.php specifically, not the REST API or any other part of the site.
Does the custom 404 page get indexed by search engines?
No. The page includes its own noindex, nofollow meta tag.
Who can enable this module or edit the response page?
Only an administrator with access to the TheOneWP settings screen.
Stop leaving WordPress's oldest remote door unlocked.Close xmlrpc.php before it's ever reached.
Use Disable XML-RPC to block xmlrpc.php entirely, backed by three layers of defense, with a fully customizable response page.