Disturbing Report On WordPress Plugin Security

checkmarx logo Checkmarx, a company founded in 2006 that specializes in automated security code reviews has published a security vulnerability report on the top 50 plugins on the WordPress plugin repository. In the report published on June 18th, 2013 Checkmarx concluded that more than 20% of the 50 most popular WordPress plugins were vulnerable to common web attacks such as SQL injection. Furthermore, the report revealed that 7 out of the 10 most popular e-commerce plugins for WordPress contained vulnerabilities. First, some background information regarding how the report was put together.

The research in this survey has nothing to do with the core security of WordPress but rather, the plugins available for it. It’s important to consider this distinction when reviewing the report. An automated static code analysis developed by Checkmarx was used to scan the source code against the most popular plugins. These included the 50 most downloaded plugins as well as the 10 most popular e-commerce plugins. The scans occurred on two separate occasions. The first was during January 2013 while the second took place in early June of 2013.

During the first scan, Checkmarx discovered 18 vulnerabilities and notified the developers of four of the vulnerable plugins, then worked with them to apply fixes. After 6 months, the WordPress plugin repository indicated that all 18 plugins had updated versions. The scan was used on these updated versions to see if the vulnerabilities had been fixed. Their automated tool was set to notify when one of the following vulnerabilities was discovered:

  • SQL Injection (SQLi). Allows the execution of commands on the back-end server, such as the extraction of sensitive information. In a hosted environment, a SQL Injection attack can further be used as a stepping stone for attacks against non-vulnerable sites. The attacker in this environment can manipulate the database shared by both vulnerable and non-vulnerable sites.
  • Cross Site Scripting (XSS). Allows the running of a script on the client in order to bypass access controls. This kind of vulnerability targets all visitors to the site. In a hosted environment, this problem is exacerbated where an attack can also be used to steal the session cookies of the site admin. Effectively, it allows the attacker to imposter the admin.
  • Cross Site Request Forgery (CSRF). Allows the attacker to perform an application-level transaction on behalf of the victim. In a hosted environment, an attacker can log onto the site on the admin’s behalf and perform nefarious activities such as re-directing users or performing admin transactions.
  • Remote/ Local File Inclusion (RFI/ LFI). Allows the uploading of a potentially malicious file to the server. In a CMS environment this is a particularly critical vulnerability as the point of the CMS is to manage and deliver site-related files.
  • Path Traversal. Allows the attacker to crawl the Web pages. In a CMS environment an attacker can exploit this type of vulnerability to access and map all hosted files.

Checkmarx tested the plugins for Path Traversal vulnerabilities only during the second scan.

  • The findings from the second security scan were definitely an eye opener for me.
  • 20% of the 50 most popular plugins contained one or more of the vulnerabilities listed above.
  • 7 out of the top 10 most popular e-commerce plugins were vulnerable to common web attacks

There is no correlation between the number of Lines of Code (LOC) and the vulnerability level of the plugins. Every line of code has the potential impact of introducing a vulnerability. However, Checkmarx has found that the opposite does not hold true. Meaning, the smaller the codebase does not necessarily mean the safer the code. On the contrary – some plugins that included only a few thousand lines of code contained more types of vulnerabilities than plugins containing tens of thousands lines of code.

Only six plugins out of the 50 scanned in January were completely fixed during the six-month time period between scans. The following screenshot is taken from page 5 of the report that highlights which plugins were fixed. An important note to take away from these 6 plugins is that all of them were notified of their vulnerabilities by Checkmarx. Nowhere in the report is it mentioned that the authors of all the other plugins were afforded the same courtesy.

Security Report

The report has sound advice some of which has been preached repeatedly over the years. For starters, only download plugins from reputable sources. The most notable is the WordPress plugin repository. By the way, I’ve noticed more plugin authors hosting their code on GitHub only. Take heed plugin authors that if you do this, by default, you’ve lost a degree or two of trustworthiness because GitHub is not the WordPress plugin repository. Instead, I highly recommend having a GitHub version that is kept in-synch with a WordPress plugin repository version. This article on WP Tuts+ does a good job explaining how to do that.

Their second piece of advice is to verify the security posture of a plugin by scanning it for security issues. I take issue with this piece of advice because it’s not like we as end users have a scanner in our back pocket. There is one plugin that is maintained by members of the core WordPress development team called Exploit Scanner. However, this plugin is not meant to be a security scanner for plugins, it’s more for monitoring suspicious activity on a website.

Three. Make sure plugins are kept up to date. Thanks to the ease of updating plugins, even in bulk, this is for the most part a painless process.

Fourth. Remove any unused plugins. If a plugin is no longer necessary, remove it instead of leaving it on the site deactivated. Use the option to delete the plugin along with its files from the WordPress plugin manager.

The report ends with recommendations to plugin developers and the WordPress plugin repository as well as any other application platform provider. Plugin authors are encouraged to integrate security within their development process.

The later a vulnerability is discovered, the higher the cost of fixing. But there’s more: a simple fix does not guarantee that the plugin users updated their sites. And until they do, these admins are left with the vulnerable plugins. The solution? Bake security within the plugin development as part of your secure Software Development Life Cycle (SDLC) process.

WordPress is not the only platform that has to deal with third-party issues like plugin security. According to Checkmarx, app marketplaces like the WordPress.org repository should:

  1. Enforce a security policy on apps that enter the marketplace. Although the security of a plugin may seem to be the developer’s problem, platform providers are held responsible in the light of users. Make security your competitive edge and build a marketplace where users can feel secure to return to.
  2. Authorize only apps that passed the security bar. Provide certification to those apps that stand up to the security policy.

There is more to the report than what I’ve covered in this post which you can download and read for free via their website.

Where Does This Report Leave Us?

WordPress plugin security has always been an issue that occasionally pops to the forefront of people’s minds. A good example is the W3 Total Cache and WP Super Cache plugin vulnerabilities in May of this year. It’s also a discussion we’ve been having for years. In 2009, I asked whether a plugin validation team was a pipe dream. The idea was taken from the phpBB project where the mod database would only allow mods to be hosted if they passed a strict code review process, ensuring the highest quality mods in an official, central location. Unfortunately, this method really hampered the growth of third-party extensions in their mod repository.

Today, there are at least a few members of the plugin review team for WordPress.org. These volunteers act as the front-line for plugins submitted to the plugin repository. (Thank you by the way for your work) Check out these detailed guidelines on what it takes to be hosted on the repository.

One of the arguments against having a dedicated team reviewing every line of code for submitted plugins is that there are already a large amount of eyeballs looking over code. Since everything is open-source, anyone can review the code. If the results of the report published by Checkmarx is any indication, there are not enough security minded folks dissecting plugins. It’s even more worrisome when you consider the results were based on the 50 most popular plugins. Those plugins should have had the most scrutiny considering their popularity yet, they contained vulnerabilities.

A Big Problem With No Easy Answer:

On the surface, plugin security is a big problem that can not be solved with one action. Instead, it’s going to take a multi-layered approach. Education is key. The plugin developer handbook being worked on as part of the handbook series of projects should be the starting point for all WordPress plugin developers. Especially part three which focuses on plugin security.

If Checkmarx is able to create an automated scanning analysis tool to discover vulnerabilities within the source code of plugins, why hasn’t the plugin repository come up with something similar that plugin authors could use as a tool or resource? At the very least, create a plugin that has the scanner built-in. Or, use the scanner as part of the process to review plugins and send them back to the author if a vulnerability is discovered.

The biggest impact and the one that would make all WordPress users safer would be implementing stricter policies with plugins on the repository. Unfortunately, restrictions and policies go against the open-source nature of WordPress. There is a fine line between the amount and difficulty of rules to be hosted on the repository versus going at it alone. I’d hate to see plugin authors give up hosting on the repository simply because it’s too difficult because of the policies. Some would even argue that the guidelines currently in place make it too difficult to be hosted on the repository.

By the way, if you think someone would be able to make a buck by reviewing code for themes and plugins, you’re wrong. Sites such as DevPress Code Review were launched only to disappear and ideas like WPCodeReview.com were discussed but never materialized. While a good idea that was backed by people on the WordPress Hackers mailing list, reality proved otherwise.

Throwing My Hands Up In The Air:

I don’t know what it’s going to take to solve the problem of plugin security. The more I think about it, the more it seems like it’s a necessary evil of open-source software. For as long as I’ve been active in the WordPress community, it’s been accepted by many that the plugin repository is filled with insecure code. The report by Checkmarx not only verifies that thinking, but shows that the problem could be bigger than anyone thought. One of the most unfortunate things about third-party plugins and themes is that if a site is compromised because of them, WordPress usually ends up taking the blame.

It’s depressing to think that so many people who love using WordPress are going to end up needing to hire someone to monitor their sites full-time or plunk down cash on something like VaultPress because of the epidemic of plugin vulnerabilities. The ease and joy of using WordPress quickly goes out the window with the introduction of the webmaster security hat. I think it’s reasonable to believe that the last thought on most WordPress users minds who add functionality to their site through plugins are not wondering if whether or not that plugin contains a security vulnerability. They just want that plugin to work without breaking anything else. To a point, I don’t think they should have to worry about it. WordPress users are repeatedly told to install/use plugins from a trusted source, the most trusted source being the WordPress plugin repository. What good is a plugin repository with thousands of plugins if all they end up being are ingredients to a toxic soup of disaster?

As the plugin repository continues to increase in size, so does the epidemic. WordPress community, what is the cure?


34 responses to “Disturbing Report On WordPress Plugin Security”

  1. Interesting report. My takeaway is if they have this automated tool for WordPress plugins, why not offer it as a service for plugin devs? They already have put in the time to develop it, why not profit from it too? If the cost were within reason for smaller projects, I’d buy. Even better they could offer a litte seal that could be added to plugins.

  2. The only solution is a strict review process.
    There is a a review for plugins published the first time on wp.org, but it is very limited, and since a complete commit history is forbidden(!) on .org, it is very hard to follow all the changes on older plugins. One of the many reasons why I trust GitHub only plugins more. I can read the code better there, there is a real issue tracker, not just a hidden ugly Trac instance, and I can send pull requests to fix those plugins.

  3. We have known all along that plugins are mostly unsophisticated, and could therefore be liabilities.

    But what is the pragmatic, actual record, with respect to various theoretic vulnerabilities of plugins that seemingly could be exploited? Is this in fact occurring?

    Are we indeed taking damage, because of the status of plugins?

    I can’t offer a strong answer to that question. The best I can do is shrug and say; “I sure haven’t heard much about plugin-exploits being a big or widespread problem for WordPress”.

    That question should be front & center in this discussion. We have 10s of thousands of plugins deployed 10s of millions of times. If these codes were actually being used by hostile elements to make merry with WordPress-installations … if they really were handy for the bad guys – would we only now & in this manner be hearing about it?

    Let’s be a little bit real here. Checkmarx has been getting global publicity now for 2 weeks on this story. They did really only minimal research. It has been popular in numerous circles, for years, to flog a trumped-up meme that WordPress is a security-twit … and large numbers of such articles were spun off the Checkmarx report in exactly that manner.

    What is the forensic story on plugins? Are plugins hurting WordPress … or not? It is kinda germane that we have that facet of the situation in view, as we watch these other actors read their lines.

  4. I have documented approximately 428 plugins on .org that have exploitable code since 2011 on my hobby site.

    The vast majority of these are updated/fixed, if they contain SQL/PHP exploits they are generally removed immediately upon notification. I can attest to that.

    These are only plugins that have been reported due a security list with poc’s, the real number of unreported or zero-day is a huge % higher. The reason is simple.. very few people do professional grade security audits on their websites.

    Some fact :

    1. Exploits poc’s are added automatically to exploit tools (wpscan, metasploit. etc, etc). This creates serious “ease of use”.
    2. The reported exploits are scanned en masse by bots, by en masse I mean in the tens of millions of requests and probably more.
    3. WordPress sites are exploited because of some of these plugins, especially File Inclusion and SQL injection.
    4. XSS is by far the most common exploit and is becoming a much more prevalent tactic, it now accounts for most black hat web site activities .

    I also agree with toscho, github is a safer place because the code is easier to read, easy to fork/fix and the social aspect of it creates exposure.

  5. @Steven Zahm – That’s a good question. If they had something like that available, I’m sure it would have been linked to from within the report. But as illustrated in the post, over the years, there have been sites and services based on reviewing code for plugins and or themes and they ended up closing. I wonder if their is better demand for such a service now adays.

    @Thomas Scholz – I’ve been pushing for stricter guidelines since 2009 but then again, I hate seeing more restrictions if it fosters freedom. I don’t want the walls of the repository to grow so large, it keeps everyone out. However, the Apple App store is a good model for what happens when things are strict.

    As far as GitHub is concerned, as I mentioned on twitter and in this post, users have been told and trained to only get plugins from a trusted source and WordPress.org is that trusted source. Now, at an individual level, if I see a plugin hosted on GitHub by a known plugin author, someone I trust, then I’ll download and use it. However, the average joe has been told to stay away from plugins that are not hosted on WordPress.org with the exception of commercial plugins like GravityForms. That is why I said plugins hosted on GitHub only are knocked down a notch on the trustworthy scale. Secondly, I linked to the WPTuts article because it was one of the first that instructed people how to keep a GitHub repository plugin synched with one hosted on the WordPress subversion repository. It’s the best of both worlds for both user and developer.

    On the topic of GitHub only hosted plugins, why introduce that pain of the ass of downloading/upgrading plugins the old fashioned way by uploading zip files. Unless you use a trick that enables automatic upgrades from your GitHub repository.

  6. @Thomas Scholz – If your comment were a nail, you just hit it on the head! The only way to solve all (or very close to all) vulnerabilities with plugins (themes too) is to have a strict review process. Who’s going to foot the bill for that? That’s why Github, or any setup like it, is a better way to maintain repositories of code and have move users and developers, interact and contribute to finding and fixing bugs including vulnerabilities. Trac makes your eyes bleed. WP.org repo needs a format similar to Github or BitBucket.

  7. Here’s a modest proposal: make the DEBUG constant true by default and force plugin authors to fix their notices/warnings instead of sweeping them under the carpet. Errors should be fixed, not hidden. PHP itself is going that route, getting rid of what was likely the single biggest mistake in the language, ever. WP would be well-served by doing the same.

  8. As plugin’s author in a contributive world, just a humble opinion:
    Since 5 years, plugins repository seems to become more a shop or a factory (with customers) and not a exchange platform or a knowledge library (with people working together). I am happy to contribute to WP core debug or improvement via tracs. I will be happy if for free available plugins, users continue to comment and why not suggest patch… But, perhaps the world is changing…
    Best regards,


  9. @Jeffro Here are some aspects of this story that Checkmarx might address:

    1.) The method used to select a sample of plugins for the study is unscientific. By selecting “popular” plugins, the sample is unrepresentative in meaningful ways. Although it is mentioned that the findings are applicable (only) to “the most popular plugins”, what was found out about this special sample is then used to argue for policies that would be applied to all plugin developers, and to plugins as a whole and their role in the WordPress ‘ecosystem’.

    The sample-selection method should have been randomized, etc.

    It is true & valid that the popular plugin codes will affect more websites, but it’s not scientifically legitimate to extend what is found out about popular titles, to unpopular examples as well (which in fact comprise the vast majority of all plugins). Basic observations & inferences about the different liabilities & assets of big-name versus no-name plugins have been recognized & discussed for years … we already know these 2 groups aren’t the same animal.

    2.) The study as originally designed & attempted actually failed. It had to be redesigned, in order to be ‘doable’. The technical inappropriateness of the original approach and the fact that it had to be abandoned (‘Oops – That won’t work!’), gives reason to question Checkmarx’ grasp of this field.

    What is the problem? How did the study fail? As reported at TechNewsWorld:

    Six months ago, [Checkmarx] started scanning just the top 50 WordPress plug-ins.

    “We were overwhelmed by the sheer amount of results,” [founder and CTO] Siman said.

    So the researchers limited themselves to the five most critical vulnerabilities — SQL injection, cross-site scripting, cross-site request forgery, file inclusion and pass reversal.

    “Once we limited ourselves to those vulnerabilities, the results were more meaningful — yet shocking,” Siman said. “We found that 30 percent of the top 50 plug-ins were found to be vulnerable to at least one of the vulnerabilities.”

    Automated security-auditing algorithms & programs have been around for a long time. Folks do continue to invent & patent new specific formulations, but the general idea & field is well-known and of long-standing.

    Allowed to work ‘freely’ (as hackers do), such programs tend to churn out ‘overwhelming’ results. Sure-enough. It’s a foible related to the ‘garbage-in, garbage-out’ phenomenon.

    3.) Checkmarx cannot deliver on their promise. They can neither identify the full range of exploits to which plugin-codes might be subject, nor are they physically capable of performing an in-depth analysis of even the mere 50 top WordPress plugins, much less the inventory of 25,000 titles. They are unable to serve as inspector of the ongoing stream of new plugin-submissions from developers great & small (beyond a misleadingly-superficial degree).

    They can only succeed, eg, by artificially restricting their audit-targets to 6 specified vulnerabilities. They can offer assurances only that code is free of ‘this’ or ‘that’ particular vulnerability … not that the code is free of vulnerabilities & immune to exploitation.

    Checkmarx cannot logistically meet the role they suggest for themselves. Nobody can … and we’ve known this for a long time. It’s a fundamental “combinatorial” problem. There is ‘no end’ of ways that code can be exploited.

    ‘If it was really that simple’, automated security-auditing would long-since have been a cut & dried done-deal. Vulnerabilities would now be a footnote in the history of computer programming.

    The problem is fundamentally similar to that of plugging or denying opportunities to terrorists. That we have our ‘junk’ inspected at the airport does not prevent the bad guys from selecting ‘no end’ of other avenues of attack.

  10. I spoke with Dave earlier today who manages the cloud operations for Checkmarx to talk about the WordPress plugin report. They are interested in sharing more data and answering the many questions people have raised since it was published. I’ll be in contact with them next week to view a demo and possibly get those questions answered. They also hinted at making a scanner available as per the requests of many but they are working together to determine the best way to go about it.

  11. Having a review process is too complex given the sheer amount of code committed. Code automation (Checkmarx) may catch some low hanging fruit but in reality it’s not a solution and actual code auditing is expensive, time consuming and well..no one likes doing it.

    Also a lot of exploits come from bundled scripts (timthumb, jplayer, flash players, etc.) So you are not just liable for a plugins code but a complete 3rd party library ..ya that’s not going to happen.

    Malware prefers quantity over quality, that’s why the top 50 plugins are attacked more often, it’s simply a matter of download numbers. In my stats on wpsecure the popularity of plugins are a non-issue exploit wise. Some plugins have under 1k downloads while other have over 1 million.

    The reality is that websites are audited and not plugins because no one has truck loads of cash lying around to manually audit and find poc’s in hundreds if not thousands of plugins, let alone try and patch them (you can’t even patch a plugin using trac..). Where is the return on that investment?

    Educate the end- users, no one, including WordPress, is going to hold your hand.

    Also I am not particularly interested in any company or person who automates code review, you must provide an actual poc (proof of concept) to be taken seriously.

  12. It’s obvious from looking at my server logs that there are plenty of plugins with vulnerabilities, as evidenced by the constant 404 errors from plugin probing. I have put measures in place to quickly ban IP addresses probing for plugins I don’t have installed, which helps but is not a total solution.

    I wonder if there is something we could do as a community where we voluntarily offer stats of what plugins get probed so that users and plugin creators can get notified when probing for a plugin goes over some threshold? Yes, the horse is already out of the barn at that point, but when the bad guys discover and begin to exploit vulnerabilities this could provide a warning system.

  13. Agree with wycks, without proof of concept the report is about bad coding styles and not about exploits.
    For example there might be an unescaped sql statement which the automatic tool might flag, but if the path to get to that code is available only to the admin of the site then it is not an exploit.

    Not even sure that a different review process will help because in the end of the day it takes an expert to find exploits. githuib might be nicer for use then trac but having 1M developers forking and pulling a specific code doesn’t improve the security of the code if none of them are security experts. If you just needed better version control tools to improve security then by now microsoft etc would not have had any security problems.

  14. I don’t think these results will surprise anyone experienced in security who has glanced through the plugin repository.

    The solution IMHO is education. There should be more promotion of blog posts teaching security basics. Most developers creating insecure code just don’t realise they’re doing it.

  15. This report isn’t one bit surprising to me . It seems that almost every WP plugin I’ve read is vulnerable. This needs to be fixed, so my company started a service where we will scan a plugin or theme for free and try to get the fixed code into the wordpres repo.

    I read your daily plugin posts and sometimes I decide to read the code of the plugin and they usually are vulnerable to being hacked.

  16. Thanks for your notes and comments. We (Checkmarx) are diligently working with industry experts such as Jeff (WP Tavern – Jeffro) to best reveal more extensive results, examples and insight to Checkmarx automated scanning of WP Plugins. As noted by earlier comments, the results are broad and deep, a course of responsible disclosure and tactics is required. Checkmarx engineers researched this topic thoroughly prior to release of the report; our intention is to help secure the internet experience. We hope to release further data in the coming week.

  17. Today I had the chance to participate in a WebEx session with Checkmarx to get a better look at the results of their report. I saw how their scanner works and how it reports different vulnerabilities. In one example, a particular plugin had over 150 SQL Injection vulnerabilities in its code base. A Google search later showed about 182 thousand sites using that plugin. Put 2 and 2 together and you’ve got trouble.

    I’m trying to work with Checkmarx and get the appropriate people involved to see if a partnership can be formed between WordPress.org and Checkmarx. I believe once the right people get to see for themselves just how large of a problem this is, that some sort of action will be taken. There is also the issue of just how to go about releasing their work to the public. If they make the scanner available to the public, then it’s possible that plugins will be scanned and once all of the vulnerabilities are found, will Google search websites using those plugins and begin their hack fest. This wouldn’t make Checkmarx look good too the public. However, going that way may wake up a lot of people and finally demand that something be done about it. Having a secure core is great but why not hold plugins and themes to the same scrutiny.

  18. @Jeffro – Sounds interesting. An automated system to let developers know when their code is detected as malicious could be a really useful learning resource. You couldn’t use it to auto-remove plugins from the repository as there is bound to be many false positives, but just alerting developers to the potential presence of bad code could be enough to solve many of the issues.

  19. @Ryan Hellyer – They did talk about False Positives but they were hoping that by releasing their scanner or tool that developers could contribute to detecting false positives and over time, they would decrease.

    I think a scanner or something like it that a plugin must go through before being accepted into the repository would be the best means of implementation. It would kill two birds with one stone. First, education. And 2, less plugins getting into the repo that are filled with vulnerabilities.

  20. @Jeffro -It is not possible to make a scanner which can reliably scan a plugin, so that wouldn’t work. Something which plugin reviewers use to point me in the direction of security flaws would be a handy tool for them though I imagine.

    The main use I see would be in alerting plugin developers that they may have problematic code. You couldn’t automatically block it based on that though as there will always be perfectly good reasons for doing some things which the scanner may fire off warnings on.

  21. @Ryan Hellyer – What are you talking about? Checkmarx creating an automated tool that scanned the plugins in their report. Doesn’t that prove it’s possible? The scanning would not be done by the plugin author but by the plugin review team. Any code that comes up as an SQL injection point or other type of vulnerability would all be publishing in a report. The plugin author gets the report with the details on which code is causing the flags to be drawn and the plugin is not accepted into the repo until it’s scanned and comes up with a result of 0. No guarantee that everything will be found but damn, it has to be a better situation than what we have now.

  22. @Jeffro -I’ve seen this discussed many times before (on WP Hackers I think) and the consensus has been that it is a bad idea. The problem is that you would presumably end up blocking a bunch of legitimate plugins. There is no way to reliably detect bad code that I’m aware of, you can just take a guess, which is presumably what the Checkmarx scanner is doing.

    I guess you could block everything, and then when someone needs to bypass the scanner for some reason then you could apply for an exemption from the plugin repository team I suppose.

  23. It really is true that scanners of this nature have been around for decades. There are many Patents pertaining to this Art. Indeed, the art has been known & patented for so long, so many times, that patents have for years been expiring, allowing others to then roll formerly-protected art into modified products, and then patenting the ‘new’ art.

    The limitations & foibles of these scanners became well-known, decades ago. Most ongoing art involves attempts to dodge/hide these essential shortcomings.

    If scanners could actually do what is claimed for them, there would be no vulnerabilities. Anywhere. The phenomena of errors & oversights & weaknesses would be simply extinct.

    Notice that Checkmarx studied the most-popular plugins, and found lots of issues … they did not study dorky plugins, but we tacitly assume – without even looking – that dorkware would be even worse. On this partial finding, we then tend to ask: “Shouldn’t we make standards that all plugin authors have to meet, and establish vetting to ensure these codes are up to snuff”?

    Accomplished programmers would have no problem, getting over a steeper learning-curve and a higher barrier-to-entry. But casual authors and their to-diss plugins would be excluded, rejected and culled, in large numbers.

    For some, getting rid of the low-skill authors & their plugins would be acceptable. “Hey – we gotta clean this mess up”! For others, it would even be desirable; a way to ‘deal with’ unwanted competition.

    But the bottom line on crudnik coders & plugins is … WordPress themselves are obviously protecting the plugin-rabble; has been for years, and show no signs of changing that policy. Any plugin-enhancement solution that incidentally grinds the plugin riff-raff under the wheels of Progress will be unacceptable to WordPress.

    Any suggestions for addressing issues with plugins must make-nice with plugin-hillbillies.

    It is a matter of top strategic importance, that Honey Boo-Boo herself can take a glance at the plugin-scene and snort; “Fiddle. Even I can do that“.

    Plugin-management ideas cannot reject — or even noticeably inconvenience — the inexpert. WordPress HQ won’t have it.

  24. @Ryan Hellyer – I’ve seen those discussions. I guess that’s why it hasn’t been done yet already, it’s a bad idea. At the same time, if even half of what I saw during the scanner demo today was accurate, it’s a depressing state of affairs for plugin security on the WordPress.org repository. I mean, we assumed that the repo contained all sorts of plugins rife with insecure code but to have one plugin with over 150 SQL injection points is shocking to me, even without knowing much about security.

  25. @Jeffro -It’s been like this as long as I’ve been around the community.

    An important thing to remember though, is that just because something has an “SQL injection vulnerability” that doesn’t necessarily mean that it will be present on all or even most sites. The most common examples of dangerous code I see only affect situations in which users have elevated permissions. The best example of this is in multisite where developers often assume that administrators are trusted users. However in a multisite environment where unrestricted site registrations are allowed, those users are most definitely not trustworthy. However, the number of sites which allow unrestricted site registrations is small and (I would hope) their developers should know to security audit everything they’re running on their network. So just because something is an “insecure WordPress plugin”, that doesn’t necessarily mean it will ever cause any problems for the majority of users.

    (I have no idea if the stats Checkmarx is reporting includes users with elevated permissions or not)

  26. @Jeffro What are you talking about? Checkmarx creating an automated tool that scanned the plugins in their report. Doesn’t that prove it’s possible?

    Nope.I already said this but I will be blunt this time, unless you provide an actual poc, no one cares about automated scanning, period.

    Providing a poc has been a standard for decades because it’s the only thing that actually provides proof.

    For example here is the poc for the DDOS 3.5.2 update: https://vndh.net/note:wordpress-351-denial-service

  27. @wycks – You and Ryan both bring up good points. A plugin could be detected to have a bunch of flaws but if you can’t do anything malicious with them, no big deal, right? Or if you can’t prove that what the scanner is detecting is actually a flaw with a POC then it’s borderline meaningless.

  28. On a more positive note I think a scanner could be an educational tool for developers, for example if they are not using input sanitization (built into wordpress or otherwise) it could warn them, or user role based encapsulation.

    It’s possible a plugin reviewer could use this but the amount of time and the vastness of the repository is rather daunting without funding.

  29. In addition for false positives there is also the issue of false sense of security. Just because the scanner said that a code is valid doesn’t mean it is secure.
    For example any code that doesn’t strip tags from input in multisite environment is insecure, but I don’t think there is any way to automatically detect that.
    Different example, I doubt that an automatic tool could have discovered that W3CT and supercache expose private/security info to the public net.

    I think that you have to assume that all plugins are insecure untill you audit them. There might be even a situation in which some plugins are declared secure but a combination of them is insecure

  30. “Checkmarx…published a security vulnerability report on the top 50 plugins on the WordPress plugin repository…[and] concluded that more than 20% of the 50 most popular WordPress plugins were vulnerable to common web attacks…”

    Best place to download plugins? “For starters, only download plugins from reputable sources. The most notable is the WordPress plugin repository.”


  31. Thanks for the eye-opening article. I’m part of a security startup called Prevoty, and we’re new to the WordPress community. We’re really digging the discussion here. With so many third-party themes/plugin vulnerabilities and a constantly shifting ecosystem, we’re prompted to look at creative ways to fill in the gaps.

    Not long ago we released our SmartFilter WordPress plugin, which acts as a preview layer to sanitize all input and protect your site from code injections and cross-site scripting (XSS). Because it doesn’t rely on past signatures, it’s able to understand content in a more modern way and prevent zero-day exploits. We’re then able to give precise analytics on how many rule breaks, violations and injections we handled for you. (You can even live test some of SmartFilter’s functionality with blocks of dirty or malicious code on Prevoty’s website.)

    We’re love to have some WordPress aficionados give SmartFilter a whirl and share valuable feedback. Check it out at wordpress.org/plugins/smartfilter. Please let us know what you think!


Subscribe Via Email

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