Any WordPress site administrator will know WordPress has an auto update system for plugins. Not many people seem to think through how this works and what it means, which is why a lot of people started to say stuff when I “fixed” the BlogPress SEO situation earlier today. Let’s walk through this essentially pretty easy system.
You have a set of plugins installed, WordPress gathers the name, slug (directory name), version number and some other things, and sends that to WordPress.org. On WordPress.org, the server tries to find that plugin within its system, and when it’s found it, it checks the version number against the current version number for that plugin. If it finds a newer version, it returns it. Simple, superb, just works, every day, for all of us.
How I “used” the WordPress plugin update system
The thing is, the update check relies on the fact that the plugin is on WordPress.org. If it’s not, it should return nothing. What I did was create a BlogPress SEO plugin on WordPress.org which was empty. Note that that’s easier for me than for most: I have a lot of registered plugins already, and most people who have the rights to approve a new plugin for me will do so without too much of a check. The empty plugin has the same name etc. and a higher version number than the current version BlogPress SEO sends out, and therefor it updates.
Call it genius, call it evil, some people thought it was pretty bad that it’s possible. In this case I used it for “good”, where it could also be used for “bad”. Mind you, I only did it when I found the backdoor, I wasn’t willing to do it before when it was “just” SEO spam, even though I had thought up this method about 11 months ago already.
This will not work for plugins that are already on WordPress.org, it might work for others. But remember: plugin requests do normally get a high level of scrutiny on WordPress.org. After that, if something bad got through, it would be pulled immediately. I doubt they’re going to pull this hijack of mine for obvious reasons: it does a good thing. Still, if you’re concerned about this happening, the fix is to apply this method by Mark Jaquith, or even better, replace it with your own update server.
Is this legitimate (ab)use?
Some people will argue I shouldn’t have done this. In this case, I think the end justifies the means, you’re welcome to disagree and give me your opinion, I sincerely want to hear that, ethical behavior is very important to me.
This whole story also opened the discussion about whether WordPress needs a kill switch for stuff like this (this isn’t one, people have to upgrade, I can’t just kill the plugin). I think we do need one, but we should also set very strict rules on how to use that when we add it. But then again when someone purposefully adds a backdoor to WordPress blogs around the globe, I think the platform would benefit if we (or rather, the lead developers) would be able to “kill” that plugin on all WordPress.org blogs instantly. The issue is of course that a sophisticated developer would just disable that check, so in the end, there’s probably no chance of that. Of course this is also a one off fix, as all other bad people out there will now also apply Mark’s fix…