Why you should stop your plugin from updating

Why you should stop your plugin from updating

Per Soderlind recently alerted me to a rather important security issue regarding plugins hosted outside of WordPress.org. All WordPress.org hosted plugins receive plugin updates from WordPress.org. Commercial plugins often add scripts to provide plugin updates from other sources*, but the vast majority of plugins simply go without automatic updates at all.

Now, imagine a scenario in which you create a custom plugin, but someone with malicious intent registers a plugin with the exact same name and slug as yours with the WordPress.org repository. It is conceivable that you or someone else working on the site could accidentally hit the “update” button and be immediately infected by a malicious plugin launched to attack your site from WordPress.org itself. Joost de Valk made use of this very mechanism for good back in 2010, when he forced an auto-upgrade on the BlogPress SEO plugin, but an evil person could potentially do the same thing in a more malicious way.

Thankfully there is a very easy to use work around for this problem as you can simply deactivate the auto-updates via some code kindly provided by Mark Jaquith, variants of which are posted below.

* Methods to add plugin update support from other sources include:


  1. says

    This is like treating the patient by killing him!

    This is not a solution to the supposed problem, but a way to screw up your site by not updating plugins any more. Not to mention producing a shit load of work for yourself by manually updating plugins.

    A somewhat better solution would be to have a plugin that let’s you configure where you should get updates for each installed plugin in particular. Even better, if you have the non-repository plugin active, you could possibly do this check directly from that plugin.

    This way WordPress won’t be able to serve updates for plugins that get automatic updates from other places.

    • says

      This is a method of dealing with updates for plugins which are not hosted anywhere. They wouldn’t auto-update anyway.

      Methods for updating plugins from alternate sources are listed at the bottom of the article.

  2. says

    Now, imagine a scenario in which you create a custom plugin, but someone with malicious intent registers a plugin with the exact same name and slug as yours with the WordPress.org repository.

    The method you gave works, but a simpler solution is to just name your custom plugin something unique.

    I like to stick the domain name of the site in my custom plugins. Because I’m pretty sure the people reviewing the plugins at WordPress.org would question a malicious person trying to register a plugin with the name of “ottopress.com – Custom Plugin Name”.

    • says

      That won’t help unfortunately if the person knows what the plugin name is (which they will if it loads JS or CSS onto the page since they’ll be able to see the plugin slug in the URL).

      You are correct though that something with ottopress.com in the name is unlikely to get through the approval process. I’d rather stick the code in to be on the safe side though.

      • says

        By “the people approving plugins”, I meant myself and the other members of the review team. :)

        Nothing wrong with the code. I just think my way is simpler.

    • says

      There’s no problem with using plugins, it’s just important to make sure you are aware of the security implications involved with each one you use. I have somewhere in the vicinity of 40 plugins in use on my own site right now.

  3. says

    A good question is: If someone uses wp-updates.com, wp-updates.com already protect users from that type of vulnerability? Using wp-updates.com It will stop wordpress official updates, or a bad guy could still submit a plugin with same name to WordPress.org, and it will overwrite the original plugin hosted on wp-updates.com?

Leave a Reply