Recently somebody posted on Reddit about a WordPress scanner that is taking advantage of a new WordPress vulnerability. The vulnerability is abusing the Pingback system, which is a well-known feature that’s used by a lot of bloggers.

What is a Pingback?

Quoting Wikipedia: A pingback is one of three types of linkbacks, methods for Web authors to request notification when somebody links to one of their documents. This enables authors to keep track of who is linking to, or referring to their articles. Some weblog software, such as Movable Type, Serendipity, WordPress, and Telligent Community, support automatic pingbacks where all the links in a published article can be pinged when the article is published.

WordPress has an XMLRPC API that can be accessed through the xmlrpc.php file. One of the methods exposed through this API is the method. With this method, other blogs can announce pingbacks. When WordPress is processing pingbacks, it’s trying to resolve the source URL, and if successful, will make a request to that URL and inspect the response for a link to a certain WordPress blog post. If it finds such a link, it will post a comment on this blog post announcing that somebody mentioned this blog post in their blog.

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/ or  http://bugzilla/or 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/, 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@ to reconfigure the internal router like in the email hack attack.

I’ve made some screenshots to demonstrate how WordPress is returning different error messages for valid and invalid hosts/ports.

Invalid Host

Invalid Host WordPress Pingback Vulnerability

 Valid Host

Valid Host WordPress Pingback Vulnerability

I’ve implemented an Acunetix WVS script to test this vulnerability. This script will try to resolve various common internal hosts and try to connect to common ports. In the end, it will report the successful attempts. The script is available in the latest build (20121213) of Acunetix WVS. A sample alert looks like this:

Wordpress Pingback Vulnerability Alert

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. The issue was reported to the WordPress Team and will probably be fixed soon. Until then, you can rename/delete the xmlrpc.php file. Please let me know if you have a better workaround.

** Note: The issue described in this article has been addressed in WordPress 3.5.1.

Bogdan Calin

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.

  • Ahan!! Great work. Thumbs up. 🙂

  • actually in my overnight tests i found that a blog post where trackbacks are disabled isn’t vulnerable. disabling it worked as a fix for my test installation, of course YMMV.

    • That’s not my experience. In my case it worked even if trackbacks were disabled. I’ve tested on WordPress 3.5.

  • Interesting. This is a classic case of XSPA/SSRF (Cross Site Port Attack/Server Side Request Forgery). A lot of research has now been conducted into specific instances of this vulnerability with PoC from several popular web applications.

    • Thanks Riyaz. I was aware of some of those papers but not all of them.

      In this case only the http:// scheme is supported, it’s not possible to use dict/gopher/…

  • what if you disable xmlrpc?

    add_filter( ‘xmlrpc_enabled’, ‘__return_false’ );

    • Yes, that would work but has the same effect as renaming the file xmlrpc.php to something else.

    • Very cool. I wasn’t aware about your blog post.

  • You can simplify this with a simple deny clause in your .htaccess file (Apache compatible only)


    Deny from all

    Save the file and the site should still function, but all requests to xmlrpc.php will get a 403 forbidden.

    • Deny from all will restrict access to all files.

      • Hi,

        Yes I crafted a very specific config stanza, but apparently the comment filter filtered out my XML and only left the Deny from all.


        It also didn’t allow me to edit my comment

        /double facepalm

        Basically look at the docs for an idea:

        You need to specify “files xmlrpc.php” with just the Deny from all

        • you have to be careful with .htaccess 🙂

        • The same (something similar) can be accomplished with web.config on IIS 7.5 web servers or .htaccess if something like ISAPI_Rewrite is installed on IIS. Just rewrite and/or the requests to xmlrpc.php:

          IIS web.config (Request Filtering):

          ISAPI_Rewrite .htaccess (you can’t use “deny sequences” with ISAPI_Rewrite):
          RewriteCond %{REQUEST_URI} (xmlrpc.php) [NC]
          RewriteRule .? / [F,L]

          As Bogdan said, be careful with .htaccess and read the article “htaccess files should not be used for security restrictions” on this blog.

          • Hmm, couldn’t use < %gt; for Request Filtering. Perhaps HTML encoded will work, if not I’m sorry 🙂

            <add sequence=”xmlrpc.php” />

  • Is wordpress 3.5 vulnerable?

  • Is this Vulnerability fixed in 3.5.1 version of WordPress?

      • I have a WP 3.5.1 site that still gets pingbacks with chinese characters…have disabled pingbacks, but it does not help. So is this really fixed or do I have some other issues?


  • hey, what’s the tool name you used to do the HTTP post ?
    and thanks.

    • I’m using Acunetix’s HTTP Editor tool.

  • you can also use a Htaccess rule like

    # Redirect all xmlrpc requests to noexist ip
    RewriteRule ^(.*)xmlrpc(.*)$ "http\:\/\/0\.0\.0\.0\/" [R=301,L]

    to block incoming requests containing “xmlrpc” and send the traffic to a nonexistent IP to remove stress from your server

  • The image links are wrong. They are not leading to the image.

  • Comments are closed.