Founder Of ManageWP Publishes Open Letter on Security to The WordPress Community

Open Letter Featured Image
photo credit: dreams & pancakescc

The founder of ManageWP, Vladimir Prelovac, has published an open letter addressed to the WordPress community on the topic of security. In the letter, he cites the third-party ecosystem surrounding WordPress is not only its biggest strength, but also its biggest weakness.

He suggests a three-point plan to help mitigate security issues in themes and plugins.

  1. Weed out plugins with potential security issues.
  2. Enhance the plugin verification process in the WordPress repository so all new plugins/commits are scanned.
  3. Educate the WordPress developer community, which goes beyond what is done at the moment.

Although Prelovac urges the community to start addressing these problems today, most of what he suggests is already occurring and has been for years.

Weeding Out Plugins

Weeding The Plugin Directory
photo credit: shutterbugamarcc

This is a process that takes place 24 hours a day, 7 days a week. It’s largely a byproduct of so many people using WordPress and the code for plugins being open source. This gives anyone the opportunity to review the source code to check for vulnerabilities. My guess is that most vulnerabilities in plugins are discovered due to a security keen user or researcher reviewing the plugin because they want to use it on their site.

Samuel “Otto” Wood explains what happens when a plugin in the directory is discovered to have a security issue.

  1. The plugin is de-listed from the repository, to prevent further downloads of an insecure plugin.
  2. If the exploit is accidental or not obviously malicious, the developer is notified via email. The email comes from a valid address (plugins @ wp.org) and can be replied to.
  3. The plugin developer presumably fixes the exploit or tells us that it is an invalid exploit, updates the plugin in SVN, and emails back saying so.
  4. We check it out, and either provide advice or re-enable the plugin.

Enhancing The Plugin Verification Process

This is one area of the WordPress plugin directory I consider a weakness. After a plugin is reviewed and approved, a malicious plugin author can upload a different code than what was initially reviewed. This is considered a bait and switch technique. The only way to prevent this from occurring is more humans as there are several times more plugin committs than there are plugin reviews.

In an interview published on the Tavern earlier this year, Mika Epstein, who is a member of the plugin validation team, described how they try to combat the issue.

Someone submits plugin A, we approve it, but they upload plugin B to the repository. That’s something a lot of spammers like to do. Sometimes people upload the wrong version of the code by accident, other times they intentionally go back and add in code we told them to remove. We try to mitigate this by filtering emails (I actually get an email for every single plugin check in) and scan for known issues, but it’s never-ending.

The review team is constantly improving its checks, which help them scan for the most basic and unintentional violations. Unfortunately, there is no way to scan for bait-and-switch techniques, which require someone to go back and manually check for violations after the plugin is already sent to the repository.

Expanding Educational Resources For The WordPress Developer Community

Chalkboard Learning
photo credit: Clint Gardnercc

Prelovac suggests that security information and best practices should be merged into a single resource. He also suggests that 2015 become the year of WordPress security. This includes WordCamps across the world where security would be the main theme.

The WordPress Plugin Development handbook project is still ongoing but is essentially what Prelovac is suggesting. There’s already a chapter dedicated to Plugin Security covering data validation, nonces, and checking user capabilities. If you’d like to contribute to the handbook project, check out this page for additional information

As for WordCamps, most of them already have a session or two on security. I don’t think a WordCamp or conference devoted to security in WordPress would work. It can be a dry subject and quickly go over the heads of users. I’ve attended a few different security sessions at various WordCamps and some people left the room in a panicked state.

There is no shortage of resources and tools to help developers write clean code. There are books such as WordPress Plugin Development and Professional WordPress Design and Development, 2nd Edition. Then, there is WordPress.TV with sessions like Kurt Payne and Josh Hansen: do_action(‘hack_me’) Advanced Security for Plugins or Mark Jaquith: Theme & Plugin Security. The knowledge is out there, plugin developers have to find it.

Most Of What Prelovac Suggested Already Exists

Just about everything Prelovac has suggested in his open letter either already exists or is an ongoing project. I agree that the biggest threat to WordPress and its reputation are the plugins and themes built for it.

The gatekeepers for the plugin directory and the theme review team have done a great job of protecting users from security issues when they’re discovered. On the other side of the coin, plugin and theme developers have for the most part, done a good job pushing out a patch once a security vulnerability is reported.

News Of Security Vulnerabilities In Plugins Will Be More Common

No software is perfect as it’s written by humans but the tools in place on WordPress.org make patching holes a quick process. Updates are sent to every user of the affected plugin and in most cases, updating is as simple as clicking a button.

With thousands of plugins available for WordPress both in and outside the official directory, I think reports, disclosures, and immediate updates for security issues will be more common. I think they already are but because no one has consistently reported on them, especially the minor ones, it doesn’t seem like they’re common. How a developer or business reacts to and notifies users/customers of a security issue is just as important as fixing it.

End User Responsibility and Auto Security Updates For Plugins

Education is a key component the helps users keep their sites safe and for developers to write clean code. At the end of the day, the user has a responsibility to make sure their website, themes, and plugins are up to date. If users fail to keep their sites up to date, everything else becomes a moot point.

While WordPress auto updates to point releases, could we eventually see auto updates for major security issues in plugins? This happened with Jetpack 2.9.3 which fixed a critical security bug and updates were pushed out through WordPress cores auto-update system.

Personally, I don’t want to see that happen as I like control and do a good job of keeping myself updated. I rarely leave an update notification stick around for more than an hour. Is the idea of updating plugins automatically from critical security bugs for the sake of keeping the web and users safe a justifiable one?

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

19 Comments


  1. Site environments are far too varied for forced automatic updates to be particularly viable, but I think as an opt-in feature it could be very useful. For instance: due to the git workflow I use to develop and deploy most sites, it would be a nuisance for plugins to start updating themselves on the production sites – even if they are non-breaking updates. As well, there’s a lot of room for abusing such a feature (think a bait and switch being silently pushed to sites with the previous plugin).

    Report


    1. Well, automatic plugin updates are already opt-in since you would need to edit their behavior in a plugin or through wp-config. I’m talking about whether or not we may find ourselves in a situation where plugin updates that fix critical security bugs are pushed out and sites that are running WP 3.7 or above will auto update regardless if it’s turned on or not, for the sake of updating the site.

      Report


      1. I more meant opt-in as a feature exposed to end-users, and something a bit more flexible than the existing filters. Being able to – from the WP Admin – select plugins that you deem acceptable to auto-update.

        Report


  2. Good coverage of a serious issue– I think that mistakes which result in security holes are a much bigger issue than malicious plugins. Malicious plugins will get found out and delisted, but everyone makes mistakes, and that is much harder to combat.

    What I would like to see, in the case of severe vulnerabilities, is a process for the plugin developer to work with the plugin review team to release an update and then have that update PUSHED to sites running the vulnerable code, similar to the way the Jetpack issue was handled earlier this year.

    Report


    1. Education as Prelovac notes is the biggest and perhaps most important way to limit those mistakes from happening. All security vulnerabilities are preventable because they don’t exist without humans creating them. I too wonder how bad a security vulnerability would need to be in order for the update to override whatever settings WordPress installations have and auto update or if it’s even possible for other plugins to do that. Jetpack is not your average plugin you know :)

      Report


      1. It IS possible for updates to be forced on other plugins.

        I think that there would need to be certain criteria that would need to be met:

        – Installed on X number of sites
        – Vulnerability can be exploited directly
        – Exploits can allow an outside attacker to modify posts/comments/users or some combination therein

        Something like that…

        Report


  3. Users need a color coded indicator of security to help provide them at least a little in the way of an informed decision.

    “Currently, WordPress repository is in total shambles security-wise.”

    WordPress needs to step in and “begin” to wrangle their cats not next year, but yesterday.

    +++

    This situation is totally out of control. And if you are a hosting company you know exactly what I’m talking about– WordPress is nearly a total disaster for the business model. And if you had no idea this was the case, then message or call me sometime, and I’ll be more than happy to enlighten…

    Suffice it to say, a large portion of my hosting company’s support staff efforts goes toward un-blowing up WordPress related mini-disasters. Guess who’s paying for that (certainly not the client who’s just trying to promote their “cute cats of the week” blog)?

    Report


    1. Hi Jim,

      You just have to start charging for CMS related support. You’ll go out of business otherwise. If the clients can’t handle it, they should be hosting on a service (there’s WordPress.com and I’ve heard good things about SquareSpace).

      Good point that WordPress.org could work much harder on not blowing up working installs with updates though.

      Report


  4. How about adding one more step in the whole process on wp.org – notifying users who downloaded plugin which turns out that is malicious at some point? Removing the plugin from the repo and notifying the developer is not enough in this case.

    Report


  5. I honestly see most exploits coming through all these horribly written commercial themes that are available. Its amazing how many people with buy or download a theme or plugin from about anywhere versus one that has been reviewed, rated, etc.

    Report


  6. Whups, hit post too soon.

    I also wanted to say that I find the idea of auto-updates that ignore user preferences to be pretty untenable. Like I said, site environments are just too varied; the margin for error is too high. And even in cases where it can be guaranteed to be a harmless update, it can still interfere with things like a project’s workflow.

    Control over updates is in general part of the expectations of how software should work. Even things like operating systems where security can be highly critical still provide degrees of control. Going contrary to this expectation would be really bad UX.

    Edit: and for some reason this didn’t attach to the correct post.

    Report


  7. Thank you for pointing out the good work that is continually being done to help keep the WordPress ecosystem secure. As you mention, it is an ongoing activity that is being addressed, but of course, any ideas that will make the task easier and things more secure are worthy of consideration.

    The original author made a suggestion of security bounties. While I don’t see that as practical for contributed themes and plugins, it might make sense for WordPress core. It appeared to me that Vladimir Prelovac offered $10,000 towards something along those lines.

    Google can remove an app from your phone if they realize it has a security issue. An option to signup for something similar from WordPress.org, when a hosted plugin or theme was found to have a major security issue, would be of interest to me. Having the offender deactivated and receiving an email about this issue sounds wonderful.

    An opt-in for automatic plugin updates may make sense, perhaps on a plugin by plugin basis. While some people attend carefully to updates, it appears that there are a large number of people who install and forget.

    It is an important topic. Thanks again for writing about it.

    Report


    1. Google can remove an app from your phone if they realize it has a security issue. An option to signup for something similar from WordPress.org, when a hosted plugin or theme was found to have a major security issue, would be of interest to me.

      Both remote-killing and automatic updates have taken place for extreme security issues with plugins in the past. It’s a capability that the WP.org team has, but it’s one that’s taken very seriously, as it is basically a nuclear option.

      Report


      1. How can WP.org team kill a malicious plugin running on sites? I haven’t seen something like this even being talked about.

        Report


      2. I’m being a bit loose with terms here. “Kill” in this sense is actually just the combination of releasing a new dummy version with no content (or a warning or such), then forcing an upgrade via the same process used for core autoupgrades (and the Jetpack security releases).

        Report


      3. Gotcha! Do you have any pointers on how the whole system is setup by which this auto-update system works?

        Report


      4. Take a look at the WP_Automatic_Updater class in WordPress for the mechanics of how that works.

        Report


  8. Hi Jeff

    Thanks for picking this up and spreading the word.

    When I read your thoughts the feeling I had felt familiar and then I remembered. If I replace ‘WordPress security’ with ‘Global Warming’, ‘WordPress community’ with ‘humanity’ and my proposed solution with ‘global effort for solar panels and renewable energy’ we get this situation in a familiar context.

    Yes most of what is proposed by ‘global warming movement’ already exists – certainly technology and even some solar plants have been built. And yes news of Global Warming will be more common.

    But that does not mean that we as a humanity are determined and united to solve this issue once and for all and that we are doing it fast enough before it kills us (or our children). ( I happen to have researched this topic in detail as well and there is an astonishing conclusion http://www.prelovac.com/vladimir/how-much-does-it-cost-to-solve-all-human-energy-problems-about-256-apollo-programmes/ )

    To me, this lurking monster is too big to be left handled by a few courageous individuals and non-focused non-global effort.

    And as I said at the end of my letter, I welcome all opinion as contributions to this matter, as my goal was not be right or smart but to raise awareness, and in hindsight, to help start a movement ( http://www.ted.com/talks/derek_sivers_how_to_start_a_movement?language=en

    Report


  9. Education is key. Plugin authors need to take responsibility for their code and go about things the right way to limit the potential damage security vulnerabilities can cause.

    Report

Comments are closed.