Protect XML-RPC interface in WordPress via .htaccess

Rights of the XML-RPC file
Rights of the XML-RPC file

This is what the assignment of rights looks like after support has intervened to block the script.

I just got an email from my provider, according to which massive automated calls to the xmlrpc.php file in my blog had caused the entire server to reach its performance limit. Since the blog runs on shared hosting from All-Inkl, quick action was of course required. For this reason, the support guys initially made the script no longer accessible by changing the rights of the file from 744 to 300. So the calls from the joker who wants to hack into it run nowhere.

In the meantime I have had this type of attack on other WordPress sites and with other hosters. An excerpt from the log data shows the recurring attempts to crack WordPress via a POST call to xmlrpc.php. The whole thing looks like this:

[112] '0-3 "-" 0/0/2867 "." 171.83 "2228" 121334 "0.0" 0.00 "45.59" 5.199.XXX.XXX "POST" "/xmlrpc.php'
[461] '0-3 "-" 0/0/3058 "." 171.77 "2228" 128420 "0.0" 0.00 "97.27" 5.199.XXX.XXX "POST" "/xmlrpc.php'
[216] '0-3 "-" 0/0/2878 "." 171.40 "2228" 2765 "0.0" 0.00 "43.40" 5.199.XXX.XXX "POST" "/xmlrpc.php'
[361] '0-3 "-" 0/0/2844 "." 171.66 "2228" 23121 "0.0" 0.00 "38.72" 5.199.XXX.XXX "POST" "/xmlrpc.php'
[508] '0-3 "-" 0/0/3038 "." 171.80 "2228" 78254 "0.0" 0.00 "44.41" 5.199.XXX.XXX "POST" "/xmlrpc.php'
[68] '0-3 "-" 0/0/3018 "." 171.65 "2228" 118321 "0.0" 0.00 "41.81" 5.199.XXX.XXX "POST" "/xmlrpc.php'

Also with this other hoster I was informed that these attacks can bring the whole server into distress, even if my WordPress only runs on one [shared hosting-> shared hosting].

I then looked at what else can be done to protect this file and found the following options:

1. Complete prohibition of access to the XML-RPC interface

The xmlrpc.php file is completely protected by an entry in the .htaccess file. This means that no one can access this file from the outside any more. The protection is 100% and safe, but it has the disadvantage that you can no longer access it yourself with programs such as WordPress for iOS or Windows Live Writer. Even pingbacks or trackbacks can no longer "penetrate" from external blogs to your own blog. If you don't have a problem with that because you always work in the WordPress admin and don't want any trackbacks from other blogs, this solution is good for you.

Here is the corresponding code that you have to set up in the .htaccess file in the root folder of the WordPress installation:

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all

Inset - more interesting posts on the blog:

2. Only partially restrict access to xmlrpc.php

Anyone with the Windows Live Writer, Poster or even the iOS App WordPress for iOS works, you will certainly not want to do without it completely. For this reason, the following variant of the above-mentioned addition for the .htaccess file, which keeps the XMP-RPC interface free for common third-party software, is ideal for these bloggers. However, the trackbacks from other blogs are still blocked.

This is what the customized code looks like:

<IfModule mod_setenvif.c>
  <Files xmlrpc.php>
    BrowserMatch "Poster" allowed
    BrowserMatch "WordPress" allowed
    BrowserMatch "Windows Live Writer" allowed
    BrowserMatch "wp-iphone" allowed
    BrowserMatch "wp-android" allowed

    Order Deny,Allow
    Deny from All
    Allow from env=allowed

The lines with "BrowserMatch" can of course be adjusted as required if you use a certain program that was not considered in the above script. It is important that the Apache module "mod_setenvif" has to be installed for the protection to work. However, this module is already installed in many web servers. It is also important to know that the user agent is very easy to forge. So it is not a waterproof protection that you take here!

In the current case, I have opted for the rigorous variant and simply block everything that wants to access the file. I hardly get any trackbacks and I don't use any third-party software but only the WordPress admin to write blog posts. This is what my WordPress htaccess file looks like:

htaccess protection XML RPC

This is my complete htaccess file in the WordPress main directory including the lock code to protect the XML-RPC interface.

Update: Since the WordPress update to version 3.9.2 it is no longer possible to run DDoS attacks on the xmp-rpc.php. The WordPress team responded and changed the code accordingly. With this you can save the modification as described above from this version.


Did you like the article and did the instructions on the blog help you? Then I would be happy if you the blog via a Steady Membership or at Patreon would support.


  1. […] In the last few days I was able to recognize attacks on the WordPress admin area “wp-admin” on some customer blogs. I use the login lockdown plugin on most blogs, which not only records the unsuccessful login attempts, but also blocks the login for an IP if a certain number of incorrect logins has occurred. You can determine the number of logins and the duration of the block yourself by changing the settings of the plugins in the admin area. In this way you can also see whether a hacker wants to gain access to the WordPress admin with a brute force attack. Incidentally, this technique is also used to attack the WordPress XML-RPC interface - but more on that in another post. [...]

  2. epilot says:

    I had the same attack with 280.000 hits in one day.
    Thanks to the solution described (with partial approval), I was able to reactivate the page.
    Now the only problem I have is that Jetpack ( can no longer access it. The following message appears:

    Your website must be publicly available to use Jetpack: site_inaccessible

    Error details: The Jetpack server was unable to communicate with your site [HTTP 403]. Ask your web host if they allow connections from If you need further assistance, contact Jetpack Support:

    Question: Which BrowserMatch has to be entered for this.

    • sir appleot says:

      Hi! So I could not determine the browser match. I don't have a Jetpack installation where I could test. But in your case it might work if you block access to xmlrpc.php for all IP addresses except for I checked which IP it was, but I won't publish it here. One should be careful with it. :)

      But a tip: just open a terminal window on your Mac or PC and then type "ping". Then you get an IP address, which you put into the following entry, which is then placed in the htaccess file:

      <Files xmlrpc.php>
      Order Deny,Allow
      Deny from All
      Allow from HIER.DIE.IP.EINGEBEN

      With a little luck, WordPress Jetpack will use the same IP as the domain. If that doesn't work, then try to leave out the last octet (i.e. the last point and the number after it) in the IP. Then the file will be opened for the entire IP block - with a good chance that Jetpack will be there too.

    • Marianne says:

      I also had this error message with "jetpack" and then decided on the plugin "WPtouch Mobile Plugin". It is also not nearly as big as jetpack and "rubles" the homepage for mobile devices. (But I only installed "jetpack" for this reason).

    • Marcus says:

      What should a 403 bring? So that the server really gets a high load and constantly replies to thousands of requests from different IPs with 403 no permisson? So that the attackers start a DoS even more aggressively and paralyze the server? No. -
      What were firewalls designed for? So…

      Install fail2ban and use a tough rule to lock out (mostly) botnet attacks at network level. Not at the server level. It's too late by then. So create a filter with e.g.:

      -> failregex = -. * -. * "(GET | POST). * \ / Xmlrpc \ .php. *

      and in the jail maxretry = 1. Then Apache / nginx is happy and can concentrate on the essentials ...
      Other services can also be wonderfully unsealed with fail2ban. The wp-login-php is also a sought-after destination.

      PS. Your scroll script is way too fast on the Mac trackpad and the Subit button in Firefox has disappeared to 1 × 1 pixel ...

      • sir appleot says:

        Hello Marcus!

        Thank you for your hint. I don't know fail2ban, but if I've read it correctly, it can be used very flexibly. I now use the Wordfence plugin for most blogs. That also keeps the DoS attacks at bay.

        Because of the PS: I called up the page on the trackpad on the MacBook and it scrolls normally. And the submit button for comments also works quite correctly. Now I don't know how to look for the error ... :-(

Leave a Comment

Your e-mail address will not be published.