Title: WordPress vulnerability?
Last modified: August 20, 2016

---

# WordPress vulnerability?

 *  [Sven D.](https://wordpress.org/support/users/sven-d/)
 * (@sven-d)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/)
 * _There’s a vulnerability in WordPress’s XMLRPC implementation, that permits trackback
   spam – even when you disable trackbacks. The only way to prevent this spam is
   to disable XMLRPC entirely._
 * Does this apply to WordPress 3.5 also (the latest version)?
 * [http://wordpress.org/extend/plugins/prevent-xmlrpc/](http://wordpress.org/extend/plugins/prevent-xmlrpc/)

Viewing 12 replies - 1 through 12 (of 12 total)

 *  [gcaleval](https://wordpress.org/support/users/gcaleval/)
 * (@gcaleval)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304484)
 * Here’s a link from esmi explaining how to disable xml-rpc:
 * [http://wpengineer.com/2484/xml-rpc-enabled-by-default-in-wordpress-3-5/](http://wpengineer.com/2484/xml-rpc-enabled-by-default-in-wordpress-3-5/)
 * I don’t know if it’s really accurate to call the situation a “vulnerability” 
   since the code is doing exactly what it is designed to do. Trackback spam has
   always been a concern and there have been countermeasures available.
 * What I notice is that about a day after the new WordPress core release came out
   turning xml-rpc on by default the web started getting dotted with all these claims
   about a “new” vulnerability.
 * My philosophy is that if you do not need a functionality, then, to the extent
   possible, you should not have code for that functionality on your site. As more
   and more gets bolted on to the core, it becomes increasingly difficult or impossible
   to “only keep what you use.”
 * Heck, I think lots of what’s in core should be outsourced to addons — like the
   whole Media Library should be a plugin. But woe betide the community if that 
   were the approach; much tearing of hair and gnashing of teeth would ensue! <chuckle
   >.
 *  Thread Starter [Sven D.](https://wordpress.org/support/users/sven-d/)
 * (@sven-d)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304503)
 * Thanks for your reply and link, gcaleval.
 * It might not be a bad idea to break WordPress in to “moduls” and be able to enable,
   disable or choose another supplier.
 * About the XMLRPC; the author of this plugin links to this information (dated 
   December 17, 2012), and the problem is much wider than pingback spam:
 * > This can be abused in at least fours ways:
    1. WordPress is trying to resolve the Source URL and will return different error
       messages if the Source URL exists (host exists) or not. This can be abused by
       attackers to try to guess hosts inside the internal network. The attackers can
       use URLs like [http://subversion/](http://subversion/) or [http://bugzilla/or](http://bugzilla/or)
       [http://dev/to](http://dev/to) see if these hosts exist in the internal network.
    2. If the Source URL is resolved, WordPress will try to connect to the port specified
       in the URL. Therefore, if an attacker will use a URL like [http://subversion:22/](http://subversion:22/),
       WordPress will try to connect to the host subversion on port 22. The responses
       are different if the port is open or closed. Therefore, this functionality can
       be used to port scan hosts inside the internal network.
    3. This can also be used for distributed DOS (Denial of Service) attacks. An attacker
       can contact a large number of blogs and ask them to pingback a target URL. All
       of these blogs will attack the target URL.
    4. From the tests I’ve carried out, I’ve seen that WordPress is also supporting
       URLs with credentials. So, an attacker can use a URL like [http://admin:admin@192.168.0.1/changeDNS.asp?newDNS=aaaa](http://admin:admin@192.168.0.1/changeDNS.asp?newDNS=aaaa)
       to reconfigure the internal router like in the email hack attack.
 * And _How do you protect against this vulnerability? Currently there is no fix.
   Disabling pingbacks and trackbacks from the Discussion Settings page doesn’t 
   fix the problem either._
 * If this is true then our servers can be abused and get blacklisted, and that 
   is reason for concern.
 *  [gcaleval](https://wordpress.org/support/users/gcaleval/)
 * (@gcaleval)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304555)
 * > How do you protect against this vulnerability?
 * The link I shared from esmi explains how to disable xlmrpc, which is complete
   protection against the kinds of probes being descrived.
 * What ticks me is that this is all being presented as a “new” threat. The DoS 
   attack was completely viable against any site allowing pingbacks _before _3.5.
   So was trackback spam. XML-RPC also always supported user credentials — that’s
   how remote blogging tools like LiveWriter and ScribeFire work — they use XML-
   RPC to authenticate you into the site.
 * The only one I’m not sure about is the internal network mapping.
 * What’s really new is just the fact that it is turned on by default now and you
   have to take an extra manual step to disable it.
 * But as someone who watches security threads and has vulnerability alert notices
   coming from many sources, I get a little angry that some “security” sites take
   any opportunity to trump up something into a “threat” when it really is at most
   an annoyance.
 * I’m convinced that there are many self-proclaimed security experts out there 
   who are more interested in “scaring” up traffic to their sites or selling their
   services than they are in monitoring, reporting and defending against actual 
   threats.
 *  [matthew2582](https://wordpress.org/support/users/matthew2582/)
 * (@matthew2582)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304594)
 * After installing this plugin the mobile app on my iPad can no longer access my
   admin panels. The error indicates it is looking for the file this plugin is disabling.
   If I deactivate the plugin, the mobile app works. Any idea how to address this?
 *  [Yael K. Miller](https://wordpress.org/support/users/yaelkmiller/)
 * (@yaelkmiller)
 * [13 years, 5 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304602)
 * [@matthew2582](https://wordpress.org/support/users/matthew2582/) The answer is
   no. The WordPress mobile app connects using XMLRPC. And this plugin disables 
   WordPress’s XMLRPC functions. Therefore, if Prevent XMLRPC is activated, then
   the WordPress mobile app doesn’t work.
 * Under the plugin’s FAQ, it says:
 * > Windows Live Writer, and other similar services, use the XMLRPC interface to“
   > talk” to your WordPress site, so it won’t work while this plugin is active.
 *  [forsett](https://wordpress.org/support/users/forsett/)
 * (@forsett)
 * [12 years, 12 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304669)
 * xmlrpc.php appears to be only used by the admin(s) for publishing and managing
   the wordpress via mobile or via a client as opposed to using the web interface.
   it does not appear to be necessary for end users. Is this true or false? It is
   very difficult to find a straight answer to this question on the Internet. There
   are all kinds of discussions about xmlrpc.php, but nowhere does anyone come right
   out and say: “It is only used by admin.”
 * If it is only used by admin, then it will be a simple matter to restrict access
   to it based upon user-agent or IP address.
 *  [pubwvj](https://wordpress.org/support/users/pubwvj/)
 * (@pubwvj)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304672)
 * Forsett, how would one do the restriction? I have a static IP that I access from.
   I am the only admin user. Would I put something in the .htacess and if so what?
 * I just had an attack of xmlrpc which used up all of my bandwidth for the month
   in just a few days. Money down the drain to some CRU sucking bot. I have removed
   the xmlrpc file for now as doing so does not seem to interfere with my site at
   all. Other than the mobile app are there other consequences?
 *  [gcaleval](https://wordpress.org/support/users/gcaleval/)
 * (@gcaleval)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304673)
 * [@forsett](https://wordpress.org/support/users/forsett/) it is not correct that
   xmlrpc is only used by Admins. It is also the vector in for a range of web services
   such as IFTT and others where interaction with your site is required to provide
   the service. If you use a service that involves server-server communications 
   which require authentication, it is possible they are using xmlrpc.
 * [@pubwvj](https://wordpress.org/support/users/pubwvj/) if you don not use it 
   for these purposes or for WP mobile then you are likely safe to just disable 
   it as explained in the second post of this thread.
 * The simplest test is to disable it and watch what happens for a few days. If 
   everything is working fine, you’re god to go. If not at least you should be able
   to see exactly what it is breaking so you can look for an alternative to that
   function / service.
 *  [pubwvj](https://wordpress.org/support/users/pubwvj/)
 * (@pubwvj)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304674)
 * I would like to leave the xmlrpc alone and have WP properly protect things however
   the problem I ran into was that a bot was requesting the xmlrpc file over and
   over, using up 5GB of bandwidth. My guess, correct me if you think differently,
   is it was trying to login/command through that entry point. Eliminating the xmlrpc
   file stopped the bandwidth sucking.
 * So far no users have reported any problems with not having the xmlrpc file available.
   I get about 1,000 to 3,000 readers a day between the two blogs and I warned readers
   of the issue, that I was disabling xmlrpc and to let me know if they had any 
   trouble. So far, so good.
 * Any insights are appreciated.
 *  [gcaleval](https://wordpress.org/support/users/gcaleval/)
 * (@gcaleval)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304675)
 * [@pubwvj](https://wordpress.org/support/users/pubwvj/) The following htaccess
   rule will prevent any access to the xmlrpc file from any IP other than your own(
   obviously you need to swap in your own proper IP address). But if you are using
   a mobile app to admin your site, you’d have the problem of knowing all the possible
   IP addresses that may be signed to your phone or device over time. In theory 
   that’s possible, but I don’t know enough about how cell providers assign IPs.
 * So if you are actually using a mobile app to administer your web site, htaccess
   rules are not a viable solution. If you are using Windows Live Writer from your
   home system, then this will work fine until your IP changes at which time you
   have to FTP in and change the rule for the new IP.
 *     ```
       RewriteCond %{REMOTE_ADDR} !^999.999.999.999
       RewriteCond %{REQUEST_URI} /xmlrpc\.php
       RewriteRule .* - [F]
       ```
   
 * A better solution to the problem you faced may well be [ZBBLock](http://www.spambotsecurity.com/zbblock_download.php).
   It does a very good job of catching bad IPs and blocking them from ever getting
   into WordPress, but manual installation is necessary as no one has created a 
   plugin for it yet.
 *  [gcaleval](https://wordpress.org/support/users/gcaleval/)
 * (@gcaleval)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304676)
 * [@pubwvj](https://wordpress.org/support/users/pubwvj/) If you don’t need it at
   all, then yes, you are good to go without it. I have it disabled on a number 
   of sites.
 *  [forsett](https://wordpress.org/support/users/forsett/)
 * (@forsett)
 * [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304677)
 * What I do is redirect unacceptable requests to my bot-trap. You do have a bot-
   trap installed along with a honeypot, don’t you?
 * I ban about eight hundred thousand IP addresses as known spam and scraper bots.

Viewing 12 replies - 1 through 12 (of 12 total)

The topic ‘WordPress vulnerability?’ is closed to new replies.

 * ![](https://s.w.org/plugins/geopattern-icon/prevent-xmlrpc.svg)
 * [Prevent XMLRPC](https://wordpress.org/plugins/prevent-xmlrpc/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/prevent-xmlrpc/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/prevent-xmlrpc/)
 * [Active Topics](https://wordpress.org/support/plugin/prevent-xmlrpc/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/prevent-xmlrpc/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/prevent-xmlrpc/reviews/)

## Tags

 * [xmlrpc](https://wordpress.org/support/topic-tag/xmlrpc/)

 * 12 replies
 * 6 participants
 * Last reply from: [forsett](https://wordpress.org/support/users/forsett/)
 * Last activity: [12 years, 9 months ago](https://wordpress.org/support/topic/wordpress-vulnerability-2/#post-3304677)
 * Status: not resolved