Why WordPress Needs To Overhaul Their Plugin Repository and Introduce Safety Checks

I have written quite a few plugins including WordPress Automatic Upgrade and understand how things work within WordPress.

Earlier today, I wrote about a very dangerous plugin doing the rounds of the Internet called BlogPress SEO. The plugin is nothing but a Trojan horse which siphoned sensitive data to a third party and allowed them to login to the plugin user’s admin interface without having access to the admin password.

WordPress Security

That plugin is not in the WordPress repository and will never be, but there are thousands of plugins which are already in the repository and thousands which will eventually be part of it. Here is the catch, adding a WordPress plugin to the repository is as easy as sending an email, you just create a legitimate plugin, upload it to SVN and it’s there in the repository for everyone to use.

Now, here is the problem. As far as I believe there are no checks on what code is added to a plugin and to top that there are no checks at all to future updates. In plain words, I can create a legitimate plugin and introduce it to the repository. After that, whatever updates I make to it will never be checked (other than by clever WordPress users who sift through code), since the WordPress plugin updates are based on SVN trunks.

Any new trunks you create will be made available as a update to the end user, regardless of what code you put into it. Now, this may not be alarming since there are hardly any scams related to WordPress plugins within the repository, but today’s event goes on to show that it can be exploited. It does not take much effort to get in a plugin into the repository itself, so a scammer/hacker will be able to create multiple plugins and then add exploit code to it and offer it as updates. By the time the exploit is discovered, it might be too late for users who have already updated and sent out sensitive information to the hacker.

Now, while I am making a valid point here, there is really no foolproof way to stop this problem. Of course, it would help if there are safety checks and maybe a community based checking of code before it actually is made available as an update to users. Community based code checks are hard, if not impossible, because it will involve people to actually check the updated code before it is made available to users. This will also add a hassle to developers who are contributing for free, however, in the end it will be beneficial to everyone.

Once again the approach of checking code is not exactly foolproof. A recent example involves and , who now have a very strict process of approving extensions and it causes problems to developers. However, both of them did let through/had or which snooped on sensitive information and passed them on to third parties, some without even you having to install those extensions. The most recent example being Firesheep, an extension which allowed you to extract cookies for and and then used it to login to these networks (P.S. Install BlackSheep to stay safe from Firesheep).

Now here is the big problem, none of these harmful extensions are available through the repositories, if they are, they are quickly taken off, but people can still go ahead and install these. Just like Firefox has the ability to block extensions (they blocked .NET and WPF add-ons from Microsoft), and Google Chrome has developed features in the browser to block unsafe extensions, WordPress has to take steps to block harmful plugins at the core. They have to have the ability to inform users or explicitly block plugins which are harmful.

Considering how huge a community WordPress has, it would be easy to have a system in place to report unsafe extensions, no matter if they are present in the repository or not, along with providing a friendly warning to users that the plugin they are about to install might be unsafe. In addition to that, they have to move towards encouraging more and more developers to use the WordPress repository for plugins. I had written about the benefits of users adding their plugins to the WP repo on WLTC and saw many developers unhappy with the system, so this might take a while.

If they add this feature, and it works on the fly, it would be one of the best features I could use. Though I am a experienced plugin developer and have coded plugins such as WordPress Automatic Upgrade, I fear for the millions of people who might start adding plugins which are really bad.

Hope WordPress does something about this as this could easily get out of hand. The coder of BlogPress was foolish, he wrote code that could easily be identified, imagine intelligent people being able to write code which cannot be identified and the threats just multiply.

(Image Credit: Clickonf5.org)

One thought on “Why WordPress Needs To Overhaul Their Plugin Repository and Introduce Safety Checks”

  1. You’ve really got a point here. There could already be compromised plugins, who knows…

    I think there has to be some sort of repository management in WordPress. Like, moving all plugins to a Not-Checked-repo and having one repo for official WordPress stuff and widely used plugins like Akismet.

    I myself would love to host a repo for myself. I’m building WordPress Sites for a lot of people and having them only add plugins I approve would really safe me a lot of trouble. And then I could also have a place to update my own non-publically-available plugins.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>