Support » Fixing WordPress » WordPress 4.4 XML-RPC Exploits Still NOT Fixed

  • Hi Guys,

    My server has been under attack quite a bit recently. After spending a lot of time investigating why the php5-fpm process was using so much CPU, I determined that several attackers have been targeting an installation of WordPress on my server.

    More specifically, the logs show attacks against xmlrpc.php. Using this information, I searched the net for answers. It appears this problem is known and has been known for years now.

    Thinking that this problem may have been fixed in the latest version of WordPress, I updated my blog from version 3.6 to 4.4. I then unbanned the IP address that was attacking the WordPress installation, and sure enough, nothing has changed. The attack immediately takes my server load to over 10, and the CPU is hammered by php5-fpm stemming from the POST requests against xmlrpc.php

    Sample log: – – [16/Dec/2015:10:44:34 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:35 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:35 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:36 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:36 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:36 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:37 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:37 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;” – – [16/Dec/2015:10:44:38 -0700] “POST /xmlrpc.php HTTP/1.0” 499 0 “-” “Mozilla/5.0 (compatible; Googlebot/2.1;”

    Is this issue going to be fixed anytime soon? An exploit that can bring down an entire web server needs to be fixed. I cannot believe that it hasn’t already been fixed. I’m not sure how the attack works, but the request shouldn’t even be processed if it’s too large or contains too many login attempts.

    I believe software I’ve helped write before also uses XML-RPC, but the way we implemented that is that we don’t process a request unless a unique key has been sent to us that we expect.

    If you need more information from me or my webserver, please let me know.

    This problem needs to be fixed. I cannot have WordPress installations running on my server that overload my resources. I don’t believe the solution of blocking access to xmlrpc.php makes sense. It should be fixed so that this exploit is rendered useless.

Viewing 10 replies - 16 through 25 (of 25 total)
  • @own3mall

    By the way, we had this discussion with another wp forum official member of Automattic, and they replied that basically xml-rpc is still used by thousands of people on a daily basis.

    So it’s not something that can be “put off” for security sake, as it’s used by many people worldwide, for example on smartphone. It’s rather up to us to secure our server(s) and our code, be it a template, plugin or else.

    Moderator Samuel Wood (Otto)

    (@otto42) Admin

    XML-RPC is currently the backbone of communicating to WordPress from things like all the Mobile Apps, third-party blogging tools, services like IFTTT and Quora and YouTube, and anybody using Jetpack which uses it to communicate with servers. That’s *millions* of users, not thousands.

    While a lot of that will eventually be replaced by the REST API, for now, it’s very much necessary.


    Thanks for all this in-depth information, I sometimes forget WP fuels so many websites and end-user services world-wide.

    If the WordPress functionality offered by XML-RPC is being used by millions and possibly being exploited by thousands, it’s up to WordPress to secure and optimize their code. I try my best to secure my servers. Some random IPs just spammed a pingback POST request to my server. That in no circumstance should overload any web server, ever. Especially if the pingback is for a post that doesn’t accept pingbacks and the feature has already been turned off in the WordPress options. Database queries need to be optimized if that is the cause for the server load jumping to over 10.

    Saying my server is at fault is simply NOT what happened in this case.


    Hello, and sorry for the late reply I’m quite busy this week.

    I would answer this:

    – WordPress is a free good CMS, among others (many other free software for you to try)
    – You are free to code your own CMS (Content Management System) yourself, for a good software engineer, it’s not “such” a big deal (actually it is, to reach same level in terms of quality and security with such “open” options with api and plugins)
    – If you have no time to plug WordPress with custom code, I suggest you use, will give you plenty of secure options with big data / apis / so on. Again, one my client site is on nginx for 3 years, never hacked because nothing is left possible by Linux rights. And yes it updates core updates automatically. It’s a matter of user cascading rights. Did I change my Linux rights for 3 years? No. Small site for sure, but I just try to say cascading rights are very important to a secure WP website (like disabling or rerouting default ports with nginx so that it avoids default mode and bot port scanners on :80).

    Have a nice day,

    I wish this issue would be fixed properly by the WordPress team. Other users using my shared web server have begun using WordPress, and each time, this same attack against their WordPress installation is used to bring my server to a crawl.

    I have to let everyone running WordPress on the server know that they need to install the disable xml-rpc pingback mod:

    That’s a lame fix based on the abundance of evidence showing it is the fault of WORD PRESS for its inefficient handling of this POST request. Sorry, but I can monitor all day, but it is your software inefficiently loading the database making my server work too hard FOR NO GOOD REASON.

    This issue continues, today, I saw 3 gigs of traffic all hitting my xmlrpc.php page, If I delete the page, usually the attacks cease, after seeing this issue for so many years I just have to ask Why can’t the wordpress team fix this problem?

    They don’t care, ?

    Not really sure but one thing I know for sure, I am moving away from wordpress because of this issue, other developers are also making this same move, why?

    They don’t care to fix the problem, its not on their top list of issues…

    Which tells you one critical thing about wordpress, if they are so busy fixing other more serious security problems, then when will they have time to improve the system significantly?

    Answer they won’t.

    Abandon all hope all ye who enter here.


    I agree completely. It is clear they don’t care. They continue to mark this thread as resolved too, but it most certainly is not until THEY (WordPress) fix this issue in their actual code.



    That’s really a lot of traffic for xmlrpc.php page. What is your daily visits number please (in GA for example). Compare it with xmlrpc unique hits.

    After, guys, please consider WordPress is a FREE software, thus the support is mostly community based. Most people do it on 100% free time.

    I hope you don’t quit rage because no one answered you, open source software doesn’t mean no skill involved (just the best are in general paid to do it). And, I doubt there are no WP expert to help you locally.

    Nothing great is free, that includes doing a great WP site. If you don’t know how, just ask other people around your community, there are many wp meetups or camps around the world.

    I hope this helps a bit,


    Moderator Jan Dembowski


    Forum Moderator and Brute Squad

    I wish this issue would be fixed properly by the WordPress team.

    I agree completely. It is clear they don’t care.

    OK, that’s enough and I’m closing this topic down. Venting only has value to a point and this really is a topic that’s just going round and round. If you want to vent, feel free to write a blog post.

    This already has been addressed and I’m sorry but the answer isn’t going to change.

    As has always been the case, XML-RPC can be disabled. It’s one line of code in a plugin.

    add_filter( 'xmlrpc_enabled', '__return_false' );

    This is not affecting all WordPress users; it is affecting you and you can fix it on your site yourself. That’s the use case for why something goes into a plugin.

    A lot of WordPress users use XML-RPC and there have been improvements to the interface. You can leave it off if you choose.

Viewing 10 replies - 16 through 25 (of 25 total)
  • The topic ‘WordPress 4.4 XML-RPC Exploits Still NOT Fixed’ is closed to new replies.