Disable XML-RPC blocks public access to xmlrpc.php, the legacy WordPress remote-procedure-call endpoint. AdminEase rejects every request to it at the server level, with an optional Pro IP allowlist for the rare integrations that still need it.
What this feature does
XML-RPC is a remote-procedure-call protocol that WordPress has supported since the earliest versions. It powered desktop blogging clients, the Jetpack-WordPress.com handshake, and various third-party integrations. In modern WordPress, almost everything that used XML-RPC has migrated to the REST API, but xmlrpc.php is still enabled by default and remains a frequent target for two attacks: brute-force credential guessing (one HTTP call can attempt thousands of passwords via system.multicall) and amplification-based DDoS via pingback.ping.
This setting writes an .htaccess block that denies all requests to xmlrpc.php, returning a 403 Forbidden before WordPress even loads. AdminEase Pro extends this with an IP allowlist for cases where you have a legitimate integration that still uses XML-RPC.
If you don’t use Jetpack’s site-stats sync, the legacy WordPress mobile apps, or a niche third-party integration that explicitly requires XML-RPC, turning it off is a clean security win.
How to enable it
- Open AdminEase › Security. Click AdminEase in the WordPress admin menu, then switch to the Security tab.
- Toggle Disable XML-RPC on. On Pro, an optional Allow specific IP addresses textarea appears. Add IPs (one per line) for any service that legitimately needs XML-RPC.
-
Save settings.
AdminEase writes the deny block to
.htaccessimmediately. Test by sendingcurl -I https://yoursite.com/xmlrpc.php. The response should beHTTP/1.1 403 Forbidden.
Settings reference
| Setting | What it does | Default |
|---|---|---|
| Disable XML-RPC | Master switch. Writes an .htaccess block denying access to xmlrpc.php for all visitors. |
Off |
| Allow specific IP addresses Pro | One IP per line. Requests from these addresses bypass the deny rule and reach xmlrpc.php normally. |
Empty |
What gets written to .htaccess
On free, the block looks like this:
# BEGIN AdminEase
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>
# END AdminEase
On Pro with allowed IPs, AdminEase injects allow from lines for each IP via the adminease_disable_xmlrpc_code filter:
<Files xmlrpc.php>
order deny,allow
deny from all
allow from 203.0.113.10
allow from 198.51.100.20
</Files>
What happens behind the scenes
AdminEase writes the block to .htaccess using its file handler, which manages a marker block (everything between BEGIN AdminEase and END AdminEase). Anything outside that block is preserved untouched.
Developers can fully customise the generated rules via the adminease_disable_xmlrpc_code filter. Pro uses this filter internally to inject the IP allowlist; you can hook it to add additional logic if needed.
Troubleshooting
Jetpack stopped working
Jetpack uses XML-RPC for several site-stats and connection features. If you need Jetpack, either leave XML-RPC enabled, or upgrade to Pro and add WordPress.com’s IP ranges to the allowlist (these change occasionally; check Jetpack’s docs for the current list).
The legacy WordPress mobile app can’t connect
Expected. The legacy mobile apps used XML-RPC. The current WordPress mobile apps use the REST API and aren’t affected. Switch to the current apps or, on Pro, add the device’s IP to the allowlist.
I’m on Nginx and the rule isn’t working
Nginx doesn’t read .htaccess. AdminEase still writes the file but at runtime it has no effect on Nginx hosts. Ask your host to add an equivalent location = /xmlrpc.php { return 403; } block to your Nginx config, or use a security plugin or WAF that operates at the application layer.
I want to disable XML-RPC but keep pingbacks
That’s a contradiction; pingbacks travel over XML-RPC. If you only want to stop pingbacks, leave XML-RPC enabled and use Disable Pingbacks and Trackbacks, which removes only the pingback methods while leaving the rest of XML-RPC intact.
