XSS Vulnerability Affects More Than a Dozen Popular WordPress Plugins

For the past week, security firm Sucuri has worked with the WordPress core security team to address a cross site scripting vulnerability discovered in more than a dozen popular WordPress plugins. The vulnerability stems from the improper use of the add_query_arg() and remove_query_arg() functions. Inaccurate information within the WordPress Codex lead many developers to assume these functions would properly escape user input.

The Codex pages were created in 2009, but earlier this year, Samuel ‘Otto’ Wood updated both pages to include information on using esc_url(). Inaccurate information has existed on both pages for more than five years, leading hundreds, if not thousands, of developers to use insecure code in plugins.

The Updated Codex Pages
The Updated Codex Pages

The vulnerability was first reported by Joost de Valk who has an excellent post describing the issue. Sucuri worked with Yoast and discovered the problem affects a lot more plugins than just WordPress SEO. Sucuri has audited the top 300-400 plugins in the directory and found at least 15 plugins to contain vulnerable code.

With over 37,000 plugins in the directory, 400 is just scratching the surface. Gary Pendergast, who is helping to manage the coordinated effort says, he doesn’t have an official headcount of the number of plugins affected. “There is no official head count on how many plugins are affected, as it’s a case-by-case thing to check.” Some of the vulnerable plugins within the list have opted-out of automatic updates. “Jetpack, EDD, P3, Download Monitor and Related Posts for WP opted-in to auto updates. I didn’t keep track of who opted out,” he said.

So far, there is no evidence that suggests the vulnerability is being actively exploited. It’s extremely important that plugin authors revisit your code to make sure you’re not improperly using the add_query_arg() and remove_query_arg() functions. The Make WordPress Plugins site has a post that provides in-depth information on how to check and fix your plugins.

This Vulnerability is Not New

Mike Jolley, lead developer for WooThemes, published a post in 2013 on the use of WordPress’ URL manipulation functions. The post features add_query_arg() and remove_query_arg(), but near the end of the post, Jolley reminds developers to escape everything.

This caught me out a few weeks ago when I found out (the hard way) that WordPress doesn’t automatically sanitize the current URL if you don’t pass in your own. You need to use esc_url during output:

echo esc_url( add_query_arg( $key, $value ) );

If you forget to do this, a malicious URL, for example one containing some JavaScript, could potentially be output and executed on your page. Escape all the things to be safe!

Battle Testing the Automatic Updater

To date, this is the largest coordinated effort between an outside party, the WordPress core and security teams, and plugin developers. According to Sucuri, affected plugin developers banded together for the common good. Pendergast confirmed that the auto updates only contain code needed to fix the security vulnerability. This should limit the possibility of auto updates breaking sites.

The plugins listed above have already been patched and updates should be available to all users. Browse to Dashboard – Updates to check for and install any available updates.

30 Comments


  1. Just updated Yoast’s WordPress SEO – fortunately that is the only plugin I use that is on the list.
    Thanks for the early warning Jeff and I’ll stay tuned for updates.

    Report


    1. You’re welcome. Keep in mind that the number of affected plugins is likely much larger than what’s on this list. So keep an eye out for plugin updates in the next few days.

      Report


  2. I would be great for plugin authors (like Jolley) to keep in mind that the “Open Source” part of WordPress extends far beyond the code base. The Codex is a vital resource and completely Open Source as well. When problems or inaccuracies come up in the Codex, it’d help everyone to update it accordingly.

    Report


      1. So glad you did Mike! We are all learning how to best improve WordPress bit by bit. So, you’re article from 2013 was helpful and now that this issue has been addressed, we can continue to make progress.

        Report


  3. Oh, its way more, I’d go through a whole site and check every plugin and theme for it. Or do some of the hardening suggested in the Securi blog post.

    Report


  4. I have Jetpack on dozens of sites. Luckily it looks like an automatic update was pushed out on it and when I went to update, most of my sites had already been done. The only sites I had to do manually were on an overseas server and on WPEngine. I appreciated the time savings!

    Report


  5. Luckily, I use InfiniteWP to remote upgrade everything. What worries me the most is, how many of the non-free plugins, i.e., those from CodeCanyon, are vulnerable too. All of we have sometime purchased at least one plugin there. Any news on this regard?

    Report


    1. You should reach out to those plugin developers. Hopefully, they managed to hear about this issue sooner than their customers and have their plugin updated to fix this vulnerability.

      Report


  6. Thanks for the warning. I’ll be keeping an eye out for plugin updates across all my client sites.

    Report


  7. If using chrome to test this you might be lured into a false sense of security as chrome has XSS protection built in, you should add this PHP header to your site to be able to test in chrome: header(“X-XSS-Protection: 0”);

    Report


  8. I’m guessing an attacker would have to look for the vulnerability in a specific plugin – correct? For example, they’d have to be looking for it in Jetpack specifically. So the more popular the plugin, the bigger the risk?

    Report


    1. Not necessarily,

      Guess I will break this into multiple parts.

      Hackers work in a variety of ways and the tools available to them are actually considerably more sophisticated than WordPress or Joomla or Magento etc. Alot of hackers are literally “top notch” programmers which is in one way why I never understood their activities. Some look to benefit from what can be stolen and sold. Some just enjoy it. Some work for companies. Some are not even programmers at all but just able to use the myriads of tools that exist.

      With WordPress I am 99.9% sure a database exists of “known WP sites”. Whether by “bots” or search engines usage and other means.

      There are many many tools both created be hackers and industry itself where the applications sole purpose is to identify security flaws. Hewlett Packards “Fortify” application for Web/Net use tries to find security holes. Its state of the art. Its $45,000 or so.

      Optimally any theme or plugin before public distribution would be run against such a tool and perhaps even a few others. That should be part of the “mantra” at Joomla or WP or Magento etc. But logistically thats overhead. It doesnt mean things even get caught necessarily. But its “something”.

      As I said, I’d have to believe with a application as widely used as WP is that hackers have database(s) of known sites to target. So many current sites are already in the “targets” reticule.

      However, new sites popping up may not yet be.

      So the question comes to mind of “How do they find them?”

      Signatures, a footprint.

      Those can be anything that comes back to the browser as anything coming back to the browser can be viewed. I can write a program in less than 5 minutes that will show me all data from HTML, to CSS to Javascript, URL data and POST data in Visual Studio using Microsoft’s Browser Object or Firefoxes Mozilla Dynamic Link Libraries or Chromes.

      This is one of the reasons for a “SSL Everything Push”. That doesnt stop a smart programmer from getting at anything really. But, what it DOES do is begin the technology unto a path where a USER readable form of web data and a SERVER readable form of web data CAN now enjoy separation. So down the pike 10 years what you or I code .vs. the data the browser actually renders from are QUITE different ensuring security. The cloud also has its part in that role but to explain how and what is coming is WAY beyond the scope of this blog.

      A signature can be comments, javascript, css, anything coming out of the server on HTTP transport.

      For example, this little tidbit from our framework in process of coding:

      function tsk_DoHeadFilters(){
      add_filter(‘the_generator’, ‘tsk_RemoveWpVersion’);
      }

      function tsk_RemoveWpVersion() {
      return ”;
      }

      This will change the meta generator tag which normally says WordPress and the version.

      I removed a bunch of stuff but just these few lines get rid a a very common signature used to identify what is running the site. Just replace what in the content=”TSK’.TSK_EDITION. with whatever you like content=”SquirrelsGoneWild” for example.

      Point being this:

      If you were in a battle do you run into the middle of the battlefield trusting that your armor will protect you against everything? Or do you use the battlefield to the best of your ability to stay out of the line of fire?

      Thats what signatures/footprint is about.

      Report


      1. Lastly,

        I see the Tavern filtered off some of the tsk_RemoveWpVersion() maybe they can put that back in.

        tsk_RemoveWpVersion()

        OK, we’ll try that. just reverse the front and end.

        return ‘>meta name=”generator” content=”SquirrelsGoneWild”/<';

        ——-

        Security as a whole. As I said in a prior article, eCommerce and CMS dont mix.

        It doesnt matter if the ecommerce plugin or extension is secure as a rock. IF data is compromised both site owner and/or the developer/design firm can be held libel. That comes direct from a attorney who prosecutes such things.

        ANY customer data, shipping addresses, what they purchased, their names etc. are ALL datum that cannot LAWFULLY be disclosed without their consent. Period.

        Your attorney cannot call Amazon and request all order Jeff C. has placed, in fact, Amazon cannot disclose if Jeff C. is even a customer to any entity other than the transactors unless via court order.

        If a site is compromised by whatall, some other plugins security flaw .vs. the commerce package itself is COMPLETELY immaterial. Makes no sense?

        Lets look at it this way. Sarah V. orders jewelery online. She lives in Norfolk VA. The database is compromised due to some plugin. Even though her credit card information is not there nor her paypal login data whatall. Her orders are. The amounts are. Her address is. She's ordered $80,000 in fine jewelery over the past year. A hacker knows where she lives, what she's bought, perhaps her phone number. He calls a crew in Norfolk and they break into her house.

        Anything can and DOES happen.

        This is WHY it cannot be disclosed. A court of law does not care if "Mr Commerce plugin is secure" and the comment plugin wasnt. It is the ecommerce entities fiduciary responsibility to do their BEST to ensure the security of the PLATFORM (not JUST the plugin!).

        Since "Jeannies Jewelery" contracted Bob's Web Design to do the site Bob's can also stand in the path of libel/damages. IRREGARDLESS OF DISCLAIMERS as DISCLAIMERS do NOT circumvent liability in the eyes of breach of LAW.

        That'd be like saying, "Well… See the bar had me sign a disclaimer that I or anyone I hit while driving drunk after leaving the bar voids them of libel". Not at all. They let the drinker go out the door snot stinking drunk knowing he could not drive and 5 people were killed due to it".

        Law says, "This disclaimer means nothing."

        Or, Your toaster had a form that needed be signed saying "We are not libel if this toaster under normal use catches fire" or even if its implied in the paperwork accompanying the toaster. 10,000 peoples toasters catch fire and because you signed or had an implied disclaimer of liability means NOTHING in as far as a court action goes.

        The toasters were defective.

        In as far as the ecommerce PLATFORM security goes "It was defective".

        This is WHY standards exist and WHY applications complying WITH those standards SUBMIT their applications to BE approved of meeting or exceeding those standards. THUS there is a LEG to stand on.

        Now the plugin/extension developer may well be able to bring in a independent security expert who goes over their code and says, "Yep. This is solid as a rock". Ok, they stand in no target of libel. Doesnt mean the ecommerce owner or developer/designer of their site is scott free. Again, the ecommerce owner TRUSTED in the developer/designer and the developer/designer trusted in the plugin developers of the ratings widget and all the disclaimers in the world dont void liability when law has been breached. They are worthless in fact pretty much.

        Theft of data surrounding their address, names, orders, amounts etc. all cannot lawfully be obtained by ANY party except the transactors and court. Anything other than that is illegal whether its one consumer or 50,000.

        UNLESS terms of services agreements that the CONSUMER signs off on ALLOW sharing of the data. For example, Amazon may share with some book publisher demographical data under the terms of services user agreement (which people never read but nonetheless does not VOID it). But even with the BESTEST off terms of services agreements it doesnt cover "hackers" as again as "hacking" is illegal in as far as doing so to obtain data not readily available.

        If a hacker hacks the national weather service site to obtain maps that are a year old of weather is an illegal activity even though those maps were publicly accessible in the weeks they were active. The act of hacking NOAA is illegal.

        Liability is a crazy deal as anyone can sue anyone for anything irregardless of disclaimers.

        If 500,000 email addresses are compromised that can constitute a class action should a Councillor wish to take it on to/and try assign liability and disclaimers are up to the judge to discern or toss out.

        We went through this with a campaign site. Joomla. Overnight was defaced. Next day, phone rings, "Get it back online, secure it proper or expect a lawsuit within a handful of days in the amount of 2 million dollars". Literally. Crapped my knickers. I put the site back up. Spent hours and hours sifting through code. Got a call from someone at Xerox on another project. Told him, "Couldnt talk. Emergency going on". Calls me back little later. Told him same, he asked me what was happening. I told him. He said let me look into this for you. I said fine. short time later, he calls back. He found it. Xerox ran "Fortify" against the site. Not only did they find THE security hole but found others as well. Every single one a third party extension.

        So fixed em, quietly fixed some other sites.

        After I talk to our council. Could they have sued us even though we have this disclaimer HE wrote up! He said, "Anyone can sue anyone for anything. Does not mean they will be awarded damages. Thats up to a judge." Then he said he'd get me in touch with a friend of his. He did.

        I go to this other law office days later. He looks at the disclaimer and asks me some questions about the software, extensions etc. Told me yes they could have sued any yes they'd be awarded damages. He is an IT attorney. All he does. I wont go into the entire conversation. But at the end of it he told me, "Rick. I shouldnt even be talking with you". I asked why. His response was, "If you are so irresponsible to be making websites knowing full well that these third party components may or may not be secure then you deserve to be sued." I was floored. He then said, "I should not be speaking with you because I do not defend businesses, I prosecute them." and showed me to the door.

        Report


    2. Second Post:

      So what can I do to try not walk into the center of the battefield?

      Remove signatures, those footprints.

      Step 1 in that is get rid of comments in CSS, HTML and Javascripts.

      Step 2 is run an obfuscatory tool over the javascripts.

      Dont worry about jQuery or Bootstrap.js etc. But the plugins stuff. Yes.

      Well then what if I need change things?

      Ok… here we go.

      With your websites ALWAYS keep TWO local versions. OR, use a LOCAL repository application again, two copies of the current production site.

      Your development setup should consist of THREE computers (preferably 4).

      If you use Xampp or Mamp or Wamp you can use RAID ability to keep a mirror of drives OR you can use any number of tools to mirror directories over a LAN to another box. We do both.

      So any change I make on this site is mirrored over to a backup if you will automagically.

      I recommend people actually setup a real LAMP stack. If you are unfamiliar with Linux/Unix then you can begin with say Linux MINT and start learning. Then move up to uBuntu. When comfortable with it, then move to CentOS or Fedora Core or Rehat Enterprise.

      CentOS is the community edition of RedHat Enterprise.

      Why?

      Because knowing the underlying operating environment is important to growth.

      For example. If your using a hosting firm thats running uBuntu that says something right from the word go. uBuntu is a user friendly linux release. 98% of all hosting firms run CentOS, Fedora Core or Redhat Enterprise. They are not user friendly but they are performance friendly.

      If a host firm is running uBuntu it tells me, “They are not linux/unix experts”.

      Thats not to say uBuntu is bad. Its great. And to learn by even better!

      I recommend developers/designers setup a LAMP stack. You can use any decent PC, an older Quad core is perfect or dual core if one insists.

      There are tools that remove all comments from files out there (we coded our own Windows application for it. Probably no big deal to release it I suppose).

      There are many javascript obfuscation tools out there. Use them on the files on the production sites. You can do this as well with CSS.

      Point being your minimizing your visibility on the battlefield Net.

      If your site is not identified as a WP site than most bots will just skip right past it. Your site(s) are identified by these signatures, watermarks. “Powered By” statements.

      All that being said there is ONE problem.

      ALOT of the plugins etc. say, “Dont remove this” as part of the license. If your using this javascript menu then “Dont remove this from the comment header” or Keep our “powered by” statement in place.

      Keeping that in place, any of it, may make your site a target. So… up to you.

      As updates come along then you need go through it again. So it is work.

      Report


      1. Have you thought about creating your own blog or website where you can place these comments into posts and simply link back to the article in question? I appreciate you taking the time to comment, but they all seem to be long, drawn out, and sometimes way off topic.

        Report


      2. I assume people are concerned about security and liability thereof hence the posting of these threads informing them about security issues. As such, I also might assume that the readers might be interested in security practices.

        Perhaps some readers can chime in?

        I and some friends at a physical tavern discussed some of this several days backwards. A site where people can come talk freely and learn. Learn programming, learn this/that for developers and designers where they can really grow and learn.

        I just dont know how many people be interested.

        Report


      3. Hey Rick – It sounds like you have a lot to say! I too second Jeff’s recommendation that you get yourself a proper blog. That way we can follow what you’re saying more clearly and it’s not lost in the comments. It looks like you have a lot of great experience to share.

        Report


      4. Ricks comments on this post are some of the best and useful comments I’ve read on this blog. Really made me think about WordPress, e-commerce and the issues surrounding it.

        Report


  9. Hi Rick, thank you for your informative posts. But there is one thing I don’t agree. If you are using CMS, then you CANNOT completely remove signature because each CMS has its own file structure, and that is the real signature. For example, even you remove/replace meta tag, or “powered by WordPress”, but in the source of a web page, if you see “wp-content” in the url, then you know it is using WordPress.

    Sophisticated hackers don’t really rely on what CMS you use, their exploit scripts will just try to exploit if your site has vulnerabilities, that is how Fortify works. Fortify does not check if you are using WP, Drupal, Joomla, or whatever, it only checks to see if your site has security vulnerabilities.

    Report


    1. Fortify we use against any web work we do. Xerox was gracious enough to allow us to use it against our work as we have a project loosely going on with them. Fortify does not target any particular application. There are a variety of hacker exploit ware’s that do. In as far as the URL’s of items it is actually something I am working upon in a framework here.

      Certainly it can be very difficult to remove those footprints that web applications leave behind.

      I am not part of the hacker cracker community but I am aware of it to an extent. I intend when or if we get a web blog up (being discussed Friday night) to address at least some base practices that webmasters should apply to getting more stealthy as well as perhaps taking a few hours to see whats out there in the public domain that they can use in as far as penetration testing software goes.

      Last Friday there were 14 people at the pub, this week…. no idea. But I am hoping to get some or all of them onboard.

      Report


  10. Wow, I learnt a lot from Rick’s comments. I appreciate the honesty he has with sharing his experience with us. With due respect to some well-known bloggers, I reckon it might have come as piecemeal-dripfeed posts on an ‘established’ blog.
    Yet his comments are detailed and candid enough to make anyone sit up and say ‘There is more I need to learn in this big bad (real) world and how can I actually mitigate against these potential threats instead of just relying on good luck and low traffic numbers.
    Thanks Rick. And thanks also to Jeffro for highlighting this critical XSS issue on his blog, as well as the Sucuri + WP Security Team for fixing this problem.

    Report


  11. Thanks a lot for the Information.

    The list contains some of plugins I personally use for my site and I didn’t see any updates

    Should I disable them ?

    Report


    1. No, they were most likely automatically updated. I’d compare the version numbers to make sure you’re using the latest version.

      Report


  12. Hi Jeff – good post – I think that you will find there are a lot of Plugins and Themes that will need to be patched for this XSS vulnerability because it was in the codex.

    In our case the day WP 4.2.1 update was released we tested all 19 plugins we maintain on wordpress.org and found the vulnerability in 6 of them – that is just under 30% – they where updated that day.

    With our Premium plugins on a3rev.com that ratio dropped down to 12% – still significant .

    The XSS was unknown before this WP 4.2.1 – it could not be detected with any of the stock standard hacking tools – so up to now it has been a minimal risk (slightly above 0 ). Now that it is a know vulnerability the risk factor is a multiple of:

    The # of devs who don’t test and patch their plugins / themes
    X
    the # of users who don’t run updates.

    Report


  13. Wow, Rick you are just full of information.

    Bottom line is Security is a never ending endeavor and the fundamentals must always be considered. Too many people forget this and move forward anyways which can cause them much anguish later in the future.

    Report


    1. Its a enormous problem and not only in the terms people as individuals consider.

      Hackers, crackers and business snackers have all forms of reasons for doing their malicious activities. Some just kinda enjoy a challenge and feeling empowered somehow. NEVER understood that motivation. I mean, my goodness, some of these folks would make a fortune coding and I am sure some of them are in the industry doing just that.

      Information harvesting, thats where the public gets frightened. In some respects, I understand that. Identity theft some real scary stuff. People only consider ID theft as their finances but it can be so much more than that. People doing things in someone elses name. IP addresses should never ever be stored IMHO in a program such as WP. It ties location to person. A hacker can that. If one incists. Write to the Apache Log or a log file secured behind a write only directory.

      I believe its also a tool. For example, “ISIL attacks WordPress”. WTF? Like that would be a ISIL target? Please. I’d say its more like a useful propaganda breadcrumb that can be used in the future when its, “We must regulate” comes to term.

      Everything I see and hear points to one common focal point. The future of the Internet will afford folks much much more capability than they have now. The unification of smart technologies (for lack of a better term) will afford folks absolutely MARVELOUS things they can do.

      At the same time the unification of smart technology will remove the choices in what people can do and how they do it and the software that is still alive that they can do it with.

      At some point in time it all comes to a head.

      In as far as webmasters go, well, as I have said many times and been chastised a few for there are issues of liability irregardless of disclaimers. Disclaimers are potently useless in as far as breach of law goes. With some forms of websites liability is quite different than other forms. A blog site for example that were intentionally exposing peoples address data or personal information such as gender (Male/Female, Bi, Lesbian, Gay) etc. without permission could face libel. An eCommerce site different, even if its not credit card data exposed. A medical site, again, different, “We advise you mix Ajax and Beer along with Tylenol to cure your gout”. Someone does that, attorney have a field day.

      So really, there are a variety of responsibilities on all sides of the coin and the coin has many sides, not simply two.

      The technology now is maturing to a point where it can be regulated and I suspect thats exactly what will happen. Sort of has to.

      As I said in another post. One could have a web in the US or Britain that is espousing people to hate Islamic people. That causes a problem. A problem that governance folk are trying deal with and dont need more wood atop the fire. If the same webmaster were to go house to house and causing this on their streets they’d be arrested.

      If a person in Turkey is showing the world the inner’s of problems in that nation, what gives them the right? What issues does it cause their governance?

      Americans because we are rather free (sorta) tend think that as long as they are not overboard all is fine. That is until someone comes poking around them.

      Its all really crazy.

      One world one governance is how this planet moves ahead or doesnt. Globalization is what thats about. Not just economics but more. Culturally thats a big big problem.

      Or, on the very very other end of that as both radical and non-radical conspirator theorists might state, doesnt matter, We are facing a global change be that a rock from space or economic upheaval, Extraterrestrial takeover or Biblical Revelation.

      At this point in time however its not hard to figure out whats important in our small microscosm of WP websites.

      1. Webmasters should realize they have a certain responsibility as webmasters to their user public before self-interests. That means learn skills as a webmaster to ensure security. It means letting software builders know that “They dont want this data stored” for example. IP addresses should be optional as an example.

      2. Developers need use best practices. If a say plugin is found to be insecure, WP should send a “ping” out that disables the plugin or theme. Webmaster might be upset but know what, thats called looking out for webmasters best interests.

      3. With 200,000,000+ websites out there using WP it might be a good plan for WP.Core to have a voluntary security squad that are running “hackware” against new themes/plugins and maintain a website separated from WP.Core that allows webmasters to see such things.

      4. Webusers, well it’d be nice if they did tight passwords and had hundreds of them. But they dont, and it cant be enforced. So… cant blame them or expect them to be responsible in that end. So, the software must be. * I am working on this as time allows *.

      5. I and friends a few weeks back decided we’d slap a website out there and its still in building phase but it is up. We will announce it shortly.

      Report

Comments are closed.