Cancel

Jeff Chandler

It’s Time for XML-RPC in WordPress to Hit the Road

Jesse Nickles Founder of Little BizzyThis post was contributed by Jesse Nickles. He is the founder of LittleBizzy, a managed WordPress hosting company, and a part-time blogger at CollegeTimes, where he gets into trouble exploring controversial issues.

Two weeks ago, I announced that all current and future domains hosted at LittleBizzy would have XML-RPC permanently blocked due to the non-stop problems it was causing. In the announcement, we recommended that other WordPress users across the globe urgently consider blocking the technology on their own web servers as well.

XML-RPC in WordPress Has a Troubled Past

Days after the announcement, Daniel Cid, founder and CTO of Sucuri, and Mark Maunder, CEO of WordFence, confirmed the reports that a new type of Brute Force login attack was being carried out on a massive scale against WordPress sites around the world using XML-RPC. Apparently, hackers have wised up to the fact that wp-login.php is often well protected.

Perhaps more shocking than this latest wave of attacks is that they are nothing new, as Sucuri previously reported a similar wave of attacks in July 2014. Let’s also not forget the wide-scale use of XML-RPC to perform DDoS attacks on WordPress websites reported by Incapsula in 2013. Combine these reports with hundreds of posts on the wordpress.org support forums and Stack Overflow and a picture is painted of years of unhindered attacks against millions of WordPress sites due to this single PHP file, yikes!

It is common sense to take a method and try it. If it fails, admit it frankly and try another. But above all, try something. ― Franklin D. Roosevelt

I didn’t expect to be the one to advocate that XML-RPC be removed from WordPress but that’s exactly what I’m doing: It’s time for WordPress XML-RPC to hit the road, for good.

XML-RPC Was a Conscious Mistake

I understand that thousands of volunteer hours have been invested into XML-RPC support for the WordPress platform, as is the nature of open-source communities. I sincerely respect and thank said programmers and volunteers for creating a very cool way to remotely connect to a website built on WordPress. But sometimes, we need to be honest with ourselves and admit when something isn’t working; This one of those times.

If you’re wondering why I’m framing the XML-RPC mess as a conscious mistake, that’s because it was. Three years ago, Andrew Nacin, a WordPress core developer, announced in a trac ticket that, “Security is no greater a concern than the rest of core. There is no longer a compelling reason to disable [XML-RPC] by default. It’s time we should remove the option entirely.”

Three years later, millions of WordPress sites have been hacked, crashed, or attacked, due to XML-RPC. It’s undeniable that removing the option to disable it (and/or enabling it by default) was wrong.

Out of Touch With the Average User

When broken down, it’s a classic case of extremely talented and intelligent software developers being out of touch with the millions of average Joes that use WordPress and have no idea what XML-RPC is. When developers inevitably argue that there are several free security plugins available that can help combat XML-RPC attacks, they completely miss the point: the majority of webmasters being attacked are the same ones who don’t even know what a security plugin is or how to use it.

Ironically, the one good standalone plugin that fought Brute Force login attempts was foolishly combined into the controversial Jetpack plugin, which most serious webmasters would never consider installing.

The premise, of course, for XML-RPC support in WordPress is a noble idea that sounds versatile: it allows, as previously mentioned, remote connections (logins, usually) to any given domain that is running a WordPress installation. In reality, however, this XML-RPC functionality is primarily used for three common reasons:

  1. Pingbacks/trackbacks (great for Viagra spam, DDoS attacks, and not much else)
  2. Jetpack (an all-in-one solution to slowing down and/or bloating your WordPress site with third-party scripts)
  3. WP mobile apps (I’m not sure who blogs from their smart phone, but the YO app is literally rated higher than WordPress on the iTunes store, and the user reviews of the Android version repeatedly point to XML-RPC login issues)

Do recall that the WordPress backend is now responsive, which means you can login to your blog from practically any mobile device; this wasn’t the case when the native WordPress mobile apps were first launched. And arguably, the vast majority of WordPress sites have absolutely no use for pingbacks, trackbacks, or XML-RPC in general.

XML-RPC Needs to Be Disabled or Removed From WordPress

The logical conclusion should be immediately clear: XML-RPC needs to die a quick death in the WordPress community, or at least be shifted into an optional (non-default) plugin or otherwise, in order to bring an immediate and measurable improvement to the security and stability of not only WordPress sites, but the internet overall.

Perhaps Jeff Chandler said it best:

WP Tavern is no stranger to denial of service attacks due to pingbacks and trackbacks. In 2010, I explained how WP Tavern was trackbacked to death. Shortly after the website came back online, I disabled both as I feared they might end up taking the site down again. A few years have gone by and I’ve re-enabled pingbacks and trackbacks with no ill effects. However, I wonder if it’s time to kill them once and for all, not just on WP Tavern but in WordPress in general.

Sometimes, we as developers and others with a technical mindset get caught up in solving the challenge of the day, when what is really needed is to step back and take a more philosophical look at the bigger picture. Is this thing worth our time, or is it causing more problems than solutions? When it comes to XML-RPC in WordPress, the conclusion is obvious.

Category:
Tags: , , ,
63

63 responses to “It’s Time for XML-RPC in WordPress to Hit the Road”

  1. The nacin quote is taken out of context – he is actually referring to enabling XML-RPC by default, not “removing it” from core.

    Also, the author seems to have missed all third party apps and integrations that use XML-RPC, which the JSON API does not currently replace. This post just comes off sort of misinformed and naive.

    Create forum topic from comment

  2. It stinks to hear the one good standalone plugin was rolled into Jetpack. My host suggested I remove XML-RPC a few months ago and I ended up installing Remove XMLRPC Pingback Ping. I now see on their GitHub page that it’s simply a reproduction of a snippet of code from WPTavern!

    I wonder if adding that code to our functions file still good enough to get the job done until XML-RPC is removed from WordPress? Or should people look for plugins that disable it completely?

    Create forum topic from comment

  4. Regarding mobile apps, I’ve found that “who uses that?” is often a form of tunnel vision. Just because I don’t have a use case for something, it doesn’t mean that other people don’t.

    While a smartphone isn’t that great for long-form text blogging, it’s perfect for comment moderation and replies, short text posts, photo posts, etc. You know, all those things that people do on Facebook, Twitter and Tumblr with their phones, but could be doing on sites that they own.

    Of course, Android and iOS aren’t just for phones, they’re for tablets as well. I know it’s popular to deride tablets as useless, but I’ve found that if I’m going to be on a train or an airplane for a while, or just going somewhere for lunch, I’d much rather carry a tablet than a laptop. And I’d much rather write on a tablet than a phone. When I’m offline, I don’t have access to the site’s admin interface, no matter how responsive it is.

    So yes, there are use cases for the mobile app.

    I can see deprecating XMLRPC or making it optional again (with suitable UI to indicate it needs to be turned on for mobile access). But an alternative needs to be ready to take its place before it’s actually removed. My understanding is that the JSON API isn’t quite there yet. When it is, then it’ll be time to kill off XMLRPC.

    Create forum topic from comment

    • Here’s a use case: you’re out-and-about, no wifi, no mobile data, and you have an idea for an article. You can either put it in a collection system (e.g. Evernote) or create a draft article straight on on the WP mobile app that’ll sync up when you have data.

      Hopefully the mobile apps will use the JSON API in the not-so-distant future!

      Create forum topic from comment

  5. XML-RPC has some redeeming features and can be useful, but is seriously lacking in the ability to limit it’s access to real users only. It also suffers somewhat from being an “all things to everyone” process that means if you want to use one tool, you effectively have to expose at least part of every other tool for prodding.

    For me, XML-RPC needs a simple and direct way to limit access (without using complex htaccess rules). As an example, if you are a blogger based in Argentina and only ever mobile blog from Argentina, it would be good to be able to limit access to the code to your own country. For those more commercial users who may use a WP editing tool from their office, limiting access to a given IP or IP block would probably be a good way to go.

    I would say that what XML-RPC needs is it’s own little control panel, with an ON/OFF switch (so people can entirely disable it) and the simple ability to limit access by country code, IP, or IP block. It may also be useful to have toggles to disable parts that are commonly not used and only abused, such as trackbacks. Not accepting trackback spam would likely be a very good start!

    Create forum topic from comment

  6. Specifically on trackbacks and pingbacks, like many things in this world, they have become a haven for viagra and other problems because we haven’t tried to improve them in years.

    The idea of linkbacks is sound. I want to comment on your article on my site(as opposed to yours) and I want your site to accept it as a comment.

    The code that accepts pingbacks needs a serious rewrite. Trackbacks don’t even verify a site is linking to yours as it was never in the original spec.

    I suppose we could abandon them both and move to their successor, webmentions, which is http, not xmlrpc based…but the linkback idea, regardless of a solution, if the handling is improved, is something worth having on your site.

    If you don’t perform maintenance on your house, and someone breaks the windows, the roof leaks, etc…

    Create forum topic from comment

  8. This is stupid, removing functionality is the stupidest kind of security, but if you are going that way you should at least prove that there is an actual security risk. This article has many words but no numbers to prove the point.

    The reality is that if you have a good password you will not get hacked from brute force attack, and if you have a login rate limiter then even not so good passwords might be enough. If your password is 123456 then you will get hacked with or without XML-RPC.

    Create forum topic from comment

    • Stupidest? This is not about security only. XMLRPC DDos attacks can put a server down quite easily. Those post requests are coming from thousands of different, infected computers, each IP is unique and dynamic in most cases so good passwords and rate limiter won’t help you much.

      Create forum topic from comment

        • Samuel, “they” chose XMLRPC for a reason. Except wp-login.php, it is the only door that is so easy to attack and to overload a server. And hard to protect. I can restrict IP addresses to login on WordPress, can check if a request is coming from a browser ( “they” do mistakes ) or can even move wp-login.php to a new location. But the only way to stop XMLRPC DDos attacks is to close the door. I would be grateful for an advice if you know a better solution.

          Create forum topic from comment

          • What, “they” can’t hammer your posts, comment handlers, search handlers, archive pages, etc. with cache-busting URL parameters, stuffed HTTP headers and long POST parameters, to ensure that PHP and the database are called, and tie up resources that way?

            DoS attacks don’t require a login “door,” they just require keeping you busy.

            Create forum topic from comment

            • Attackers target XMLRPC to get in. That’s why there are so many attacks on WordPress xmlrpc.php . Keeping you busy is a “side effect” ( that can overload a server ).

              “They just require keeping you busy” is a different problem.

              Create forum topic from comment

            • Getting in has nothing to do with DDoS, which is what you’ve been talking about all the way up the thread. DDoS is a distributed denial of service attack. Keeping your server busy (or otherwise blocking access to it) *is* the problem.

              If you’re talking about breaking in, that’s not DDoS.

              Create forum topic from comment

      • I never look at my logs to see how many brute force attempts are being made against my sites. brute force attacks like spam and crawlers are the fact of life on the net and you need your site to be able to handle it if you are doing anything which is more then a simple blog.

        The cheapest linode VPS I use for 10$/month serves me very well, and the only “DDOS” I ever experienced were due to actual higher traffic.

        Of course I have basic performance enhancers like APC and object caching going on, but people that care about performance and security should not host on a shared hosting in the first place.

        Actually comment spam is a much bigger DDOS threat as it requires a DB write which is much more expensive then a DB read required to authenticate a user, but I don’t remember anyone suggesting to remove comments from core because business sites don’t use them….. well, not yet ;)

        Create forum topic from comment

  10. WordPress is not just a nice standalone CMS anymore. It’s a Network, kind of Facebook :-) XMLRPC and Jetpack are one of most important parts of it. “Unsubscribe” from WordPress if you don’t like them :-)

    Create forum topic from comment

  11. To me it’s clearly that this host doesn’t know how to protect their customers in a good way. I will not go as far that you should avoid them but you should ask yourself why they think this is the right solution. Will they also block the REST API when it’s out? Because most if not all of the XML-RPC features will be there too. In the end you should protect your customers on your network and server layer. And for most, if not all issues of the XML-RPC you can do that.

    But yes, the XML-RPC has it’s issues but asking for disabling/removing is just not the way to go. At least for now. Even when the REST API is fully in core, it still will take a couple of more years when disabling XML-RPC by default is mostly risk free from breakage.

    To close off, when I read this post, I reading a story from someone that is defending the decision the company made. Finding reasons that makes their decision stronger. Personally I rather write on my laptop but even I sometimes using the iOS app to create a draft with bullet points for an upcoming new post.

    Create forum topic from comment

      • I have my XML-RPC fully functional except multi call. I do have an IP block for all admin account.

        There are two problems here: the security(login) one and the DDOS one. For DDOS protection you can use mod_security or even nginx to limit the amount of requests an IP can make. You can even specify the path so for wp-login.php/xmprpc.php it can be stricter. With mod_security you could even look at the post values to target more specific.

        The security part would be limit login attempts. But also remove the multi call method. What I like is the combination of WordPress with fail2ban. When someone logged in to many times wrong, you could block him on the server level. This would help a large attack too.

        But there are so many other ways. This are simply the things I know about.

        Create forum topic from comment

        • Thanks for sharing. But fail2ban and limiting IP requests won’t “work” if you’re attacked from different IP addresses. Or I’m missing something ? By the way – I use Openresty ( Nginx with Lua ) instead of fail2ban. Much more effective.

          Create forum topic from comment

          • That is certainly a valid point. It still works though since most traffic still will be blocked. If not by fail2ban (or something simular) then by the limiting the login attempts. Obviously they have more possibilities to try things out. Never dealt with this situation but applying a certain threshold that blocks all traffic when x amount of IPs are blocked for a certain amount of time.

            Btw, you can’t really compare Openresty/Nginx with fail2ban. It’s not only about webserver but also about FTP, SSH etc. Also for fail2ban you have lot’s of default rule sets. You could even use Lua if you want.

            Create forum topic from comment

            • Yes, fail2ban is very useful for SSH.
              For webserver I do prefer Openresty – with it’s Lua I can block/ban a “bad” request IP immediately, before it will be sent to php. Fail2ban requires a log entry to take an action, so it’s not that effective.
              Thank you for taking your time, anyways :-)

              Create forum topic from comment

    • It’s perfectly legitimate to turn off a feature if it’s causing problems with a site or server (I’ve lost count of the number of times xmlrpc.php has simply overloaded a machine so a site becomes unusable – and it is annoying to have to remember to do this, or when you forget about it and waste time looking elsewhere for the cause of the problem).

      I prefer to block it at Nginx or Apache level and if necessary I can open it up again to specific IP addresses/ranges if there’s a genuine need for automated posts or file uploads etc.

      WordPress is a consumer product – it’s unfair to expect ordinary users to have to understand this kind of problem.

      I’d prefer an ‘off-by-default’ approach combined with a warning and some advice when you turn it on.

      I’d welcome any info about whether the new REST-API has any mitigation against brute-force or DDoS built in – I didn’t find anything from a cursory reading of the docs, but it’s been discussed, surely?

      Create forum topic from comment

      • WordPress is a consumer product – it’s unfair to expect ordinary users to have to understand this kind of problem.

        But you do expect them to understand how to turn it on? What is the chance that anyone which installs the wordpress iphone app will know how to handle the “can not login” message it will get? What helpful instructions can the app give when the site might be in a different language?

        people want to be able to publish from the smartphone and tablets and as long as wordpress admin is not mobile friendly enough they need to use the apps which use xml-rpc.

        Create forum topic from comment

  12. Will they also block the REST API when it’s out? Because most if not all of the XML-RPC features will be there too.

    YES. THAT. ?

    The problem with killing off the XML-RPC interface is that it put’s the blame on a DoS problem where it doesn’t belong.

    Any interface will get hammered like that. Does anyone seriously think getting rid of the (as an example) wp-login.php file is a good idea? It’s just another interface/target for abuse.

    *Drinks coffee*

    That was a rhetorical question, in case anyone is not sure.

    Look for solutions that let host providers rate limit requests to your site. Once that’s done then you only have worry about secure passwords. They’re not getting in if you’re passwords are good.

    Create forum topic from comment

  17. Android app is basically useless at this point. Since the early September update, it’s unable to refresh and post if you have any number of garden variety security or login limiting or XMLRPC limiter plugins installed.

    Given the large number of businesses that are using WP to build websites they can use and aren’t looking for comments, ping backs, trackbacks on their sites, we really should address this situation.

    Create forum topic from comment

    • Hey Matt, I’m not sure what warranted such a condescending, ad hominem attack from you, but here is my response:

      https://www.littlebizzy.com/blog/matt-mullenweg-attack

      Also, your Jetpack-enabled site takes 14 seconds to load:

      http://tools.pingdom.com/fpt/#!/eJ6gPc/https://matt.wordpress.com/

      …while our (lighter) homepage loads in just 0.4 seconds:

      http://tools.pingdom.com/fpt/#!/bDUtpj/https://www.littlebizzy.com

      Cheers and best wishes to you —

      Create forum topic from comment

      • If you would have done your research then you would also have contacted the people who had improved the XML-RPC years ago when it got enabled by default which you haven’t.

        I was one of them and I’m more then happy to discuss it with you why some of your points are not well formulated. You can read my comment for more information. Would be fun if some podcast would host this.

        Create forum topic from comment

        • It would be really helpful to hear the ideas behind your improvements to xmlrpc.

          Simple facts for me: I just recently setup 2 wordpress sites, withing couple weeks both got slow and unresponsive (even though both were on VPS). Some digging revealed periodic POST pings to /xmlrpc.php with some CPU heavy operations consuming workers.. So in the end solution was the same – block /xmlrpc.php and problem went away immediately.

          As for REST API – the biggest benefit there is protection, you will need keys to access API!

          Another observation – about a week ago I was under 1.5GB/s DDoS attack which was mitigated using Incapsula protection. Most of the traffic came from WordPress clients. There is no way to protect against more or less seriouse DDoS attack with just Nginx as you mentioned.

          Anyways, looking forward to your explanation of awesomeness of xmlrpc in wordpress and why is it enabled by default. It’s a big mistake in my mind and already bit me in the ass couple times..

          Create forum topic from comment

          • Thank you for your reply. Let’s see if I can address the issues you mentioned.

            We improved in WordPress 3.4 and 3.5 the capabilities of the XML-RPC and checked the code quality. This included a lot of new unit tests written to be sure that code was correct and things were secure capability wise. Having the need of username/password is still a security problem but it’s also a hard/impossible problem to fix. Based on that, enabling the XML-RPC was something that made sense. It was way more easier to use mobile apps and offline editors. Downside is another entry for hackers to get in. Numbers I got from this year from a host still shows that wp-login.php gets attacked way more then the XML-RPC. The only said part since then was the ability to login multiple times with one request. That is something I should have looked at before XML-RPC got enabled by default.

            That sites running on a VPS doesn’t mean a lot. There are sites running faster on a shared hosts then on a VPS. In the end it’s all about the hardware/software and getting everything out of it. I guess with POST pings you mean trackbacks. Though it is in the XML-RPC code, I wouldn’t say that the XML-RPC should be disabled only based on that. But if you don’t need the XML-RPC then blocking it is a good thing to do. It’s your site and you know if you don’t need it. For a host with many clients it’s a different story.

            I disagree with the statement that REST API has protection because of needed keys. You can still call it and it will run your PHP code. That same goes for the XML-RPC. The way authentication works is different but there are still database queries happening and both cases caching is a hard thing to do. So it’s still ending up being a DDoS attack with a lot of traffic. I don’t know if the REST API is more secure since it can be accessed with the cookie data and a nonce so that is also a risk.

            I’m wondering what the traffic was from WordPress clients. Was it through the XML-RPC or just WordPress sites that got hacked?

            Create forum topic from comment

      • The 14 sec load time is only because of the gif animation, nothing else. Not because of Jetpack which you reference so be fair.

        I have never, ever had a problem with XML-RPC and i host on WPEngine.

        I’m no server engineer but maybe it has something to do with your server configuration that needs fixing.

        Create forum topic from comment

      • Condescending Mullenweg? Wrong guy.

        Hyperbolic, slightly, but the attempted tie to dDOS was indeed misleading … no special relationship there.

        Indeed, we see here in the comments someone attempting to follow up on the flawed dDOS-logic. Bad call … over-enthused for your thesis, it looks.

        XML-RPC is just a tool. Some people aren’t up to screwdrivers. Some misuse them. Not a commentary on the tool itself.

        Create forum topic from comment

        • “attempted tie to dDOS ”
          I think most here are equating the statement in the post to be about the brute force password guessing for admin credentials,

          However I thought a while back there were some methods posted about how “DDosers” could use multiple wordpress xmplrc’s to amplify an attack on a third party.

          I’m not positive this is what the author was talking about, as I think he linked to a definition of ddos and not info about this amplification method.

          However I think it is a valid concern, even if your site is not being targetted, I would bet that there are thousands of wordpress sites out there in which the admins / authors never have and never will use xmplrpc – however having it turned on is indeed a security issue for a site itself, and I think it could be also used to harm other sites.

          Reminds me of a friend’s father who did not care that his anti-virus software was expired – he said “I only have pics of my grandkids on there, nothing for anyone to want to steal, and if they did, I would not care.

          Given that this gentleman had relatives in a controversial country, I asked him. “what if a virus maker was to infect your computer and use it to attack via password guessing or traffic overloading against the people in your home country X”

          If that scenario was a real possibility, would you then consider updating your anti-virus software?

          That was many years ago, and that kind of attack was rare… these days, things like that are much more likely.

          I think he updated his AV software, learned a bit more about this connected world, and surely if he had xmlrpc runnin on ihs web site he would turn it off if a checkbox was there with a note about what it does and it can be used for.
          1 – unhcheked – cant post with your phone app, can’t be used to attack other sites and can’t be used to flood your server with 1000 password guesses per minute, bypassing your limit logins secuity.
          2 – checked – now you can post with your phone. now your site can be used to attack other sites and the bots will come and cram a thousand passwords an hour through your system for a couple of days at a time every few weeks. Enjoy.

          Create forum topic from comment

      • You’ve embarrassed yourself twice now by publishing an article and a follow-up comment on at least two topics that you clearly don’t have a great deal of experience with. Matt’s comment was not condescending, it was observational, as are several other comments in this thread.

        If you’re going to publish an article about a topic you’re not experienced with (you admit yourself that you’re not a software engineer), then you should request peer feedback on the article prior to publishing it, from someone who’s actually familiar with XML-RPC. They would have pointed out that practically this entire article is FUD.

        I suspect the main reason this article was published was, indeed, to “cause controversy” in order to draw attention to the author.

        Create forum topic from comment

    • @Matt, under the umbrella of “socially responsible public relations”….
      IF you feel like the author was “misinformed and misleading”, then instead of making an assumption that you “guess the author was trying to create “controversial issues” why not simply respond to the content that the author has written?
      It’s your name, it’s your voice, it’s your platform, and it’s yours to run into the ground or lift up in clarity. You’re the one who built this, and now millions of us use it.
      So, when you make public comments like this, you’re not hurting us at all, you’re just hurting yourself, your name, and your voice.
      Hopefully next time you can focus on the message instead of the messenger?

      Create forum topic from comment

    • @Matt – I can understand you thinking that. However I am quite surprised you would post it without some facts to rebut the things in the article.

      My experience with WP has been that the author is well informed about the issues we have been facing in the trenches.

      I do not think that xmlrpc needs to be removed from core – but there should certainly be an option to turn it off – and preferably on the next update that rolls out a message that explains to users that they have xmlrpc, if it’s turned on, and a blurb about what it does – and give the option to turn it off.

      I installed a couple different xmlrpc disabling plugins on a dozen sites, then moved to one of the firewall plugins to disable it.. I am still unsure about which plugin is the safer / better to use. A checkbox to disable in core would be safer and easier.

      Speaking of safety – disabling it by default would be safer – and make it easy to turn on if people need it.

      A simple note with a link to more info / discussion:
      1 – unhcheked – cant post with your phone app, can’t be used to ddos attack other sites, and can’t be used to flood your server with 1000 password guesses per minute, bypassing your limit logins security. Will break jetpack plugin.

      2 – checked – now you can post with your phone. now your site can be used to attack other sites and the bots will come and cram a thousand passwords an hour through your system for a couple of days at a time, every few weeks. Now you can use jetpack too. Enjoy.

      Create forum topic from comment

  19. What Jeff has drawn attention to is something that needs attention.
    While I’m not sure what the best course of action is, I do agree that there is a significant problem that needs to be addressed.

    I am working thru my sites and disabling xmlrpc.
    For my clients I explain to them the risks vs benefits – some elect to keep it enabled.

    I am by no means a security expert, I rely on others for that via plugins and consulting.

    I do believe that as a community, all of us involved with WordPress need to work together to figure out a solution.

    I am getting occasional client enquires that dismiss the possibility of working with me because I only do WordPress sites.

    The fact is out there that some people are discounting WordPress as a viable solution – however rightly or wrongly their assumptions are. The only reason I have heard is because of security… nothing else has ever been mentioned to me.

    If it is not already, then I think the WordPress core team needs to make this a top priority. The longer it continues the harder it will be to repair the damage to WordPress’ reputation.

    Create forum topic from comment

    • I am getting occasional client enquires that dismiss the possibility of working with me because I only do WordPress sites.

      The fact is out there that some people are discounting WordPress as a viable solution – however rightly or wrongly their assumptions are. The only reason I have heard is because of security… nothing else has ever been mentioned to me.

      #1. The traditional media is being devastated by the Internet. Hundreds of billions, possibly a trillion or more in value has been lost. Thousands of jobs; Hundreds of solid, leading careers.

      Out of millions of stable Wikipedia articles, a single fleeting edit-war always sends hordes of journalists dancing on the Internet’s grave. Admins with idiot-bait passwords on WordPress sites getting cracked? It’s the End of Days, people.

      #2. WordPress does have competition. Drupal is good. There are many kinds of needs & goals, many secondary website programs, and WP is not necessarily always the best, much less the only solution.

      WP was small, simple and easy to learn, more than a decade ago. The upside is, if you’ve learned WordPress, other well-known blog & CMS programs are an easy study. Even Drupal bends over backwards to help students.

      Learn a pack of ’em. It’s really not that big a deal, once you’ve broken the ice with one big-name product. In the old days, most of us were learning & trying a steady stream of CMS titles. It’s not hard.

      In all candor, anyone hosting or managing a stable of WP sites will be able to serve some clients better or more satisfactorily, by being able to offer a range of product-solutions.

      And it makes the provider look sharp.

      Create forum topic from comment

  20. “CIA Director’s lingerie – now online“!

    For some perspective, the head of Intelligence of the world’s sole superpower just had his private data hacked & broadcast.

    There is a certain beauty in having the bad guys beating a path to your door, eh?

    It’s possible that WordPress is performing a national service, by leaving loopholes dangling. It’s certainly not an issue peculiar to our favorite CMS, though.

    My non-public site logged 600,000 visits in the last few weeks … and robots-exclusion is scrupulously honored. A recent scan shows every byte exactly as it should be.

    This presumably won’t go on forever, but as long as they want to litter our digital sidewalks & carpets with their DNA … hey.

    Create forum topic from comment

    • Nice article. But it’s not clear what server was used for the tests. Dedicated, VPS, shared? RAM, CPU?
      Also, as far as I understand the discussion is about issues caused by XMLRPC, not JetPack?

      Create forum topic from comment

  23. I would like to suggest another potential security hole in wordpress, but I must apologize in advance for there is no solution against that one: child themes.

    The way a child theme works:
    – we take one of the php files of that theme
    – we kinda “branch it off” into a separate directory, and we apply the changes we desire to this php file
    – wordpress process the normal theme normally, except for the theme’s php files that have become part of its child theme

    Why this is an issue
    – themes receive security and functionality updates
    – but the vast majority of the users, while they let wordpress update their theme, do not care at all about the php files left behind in the child theme’s directory
    – and those php files in the child theme directory may contain an exploitable security hole

    Let’s be real, I never saw someone having a child theme care about checking what changes happen to his/her official theme, and then propagate the changes to his child theme’s directory’s files.

    I don’t see at all how that could be prevented.
    It’s not like we can tell people to go and use file comparison utilities between version x and version x+1 of a theme, and then edit their child theme’s php files to manually do the changes. The only persons who understand how it works are already the extremely small minority of persons who keep their child themes up to date.

    But, still, that’s an actual and big security issue within wordpress.

    Create forum topic from comment

    • Give would-be child-hackers some grief, by naming it anything other than twenty-fifteen-child. They’re ‘trying’ and guessing names, right?

      You raise a potentially notable point, though.

      Still, I made a lot of child-themes with nothing but a CSS, before I started including PHP files and doing functions.

      Create forum topic from comment

  25. This is clearly a tricky area for new app developers to navigate. Whilst researching I found this post.

    I’ve now found three ways to build support for my users to post to their WordPress sites:
    1. Our own WordPress app with wp_insert_post – https://codex.wordpress.org/Function_Reference/wp_insert_post
    2. JSON API which only works with wordpress.com and WordPress instances with jetpack installed – https://developer.wordpress.com/docs/oauth2/
    3. XML RPC wp.newPost which some sysadmins (see comments above) turn off – https://codex.wordpress.org/XML-RPC_WordPress_API

    Hope this helps others who find their way here. Please correct if not a correct understanding!

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.