When it comes to problems we see with the handling of security in WordPress Plugins by the people behind WordPress, one the overarching issues is their overemphasis in keeping quiet about vulnerabilities. While there certainly can be additional security risks due to the information being more widely available, there can be upsides as well. For example, we frequently find that supposedly fixed vulnerabilities have not actually been fixed. Without the disclosure of those vulnerabilities we wouldn’t be able to check to see if they haven’t been fixed and make sure they actually get fixed. Another thing they can do is to show when developers of plugins are not taking security seriously as something we spotted last week shows.

A week ago a report of a potential SQL injection vulnerability in the WP eCommerce plugin was posted on the support forum. Shortly afterwards one of the plugin’s authors marked the thread as being resolved and wrote:

Please disclose vulnerabilities responsibly in the future by contacting the plugin authors and not publicly.

Moderators can close this topic. pinging @esmi

It is worth noting that they didn’t link to any information on how someone could contact them about something like that (the need to make it easier for people to privately report vulnerabilities will be the subject of an upcoming post).

While the thread was marked resolved, the vulnerability was not fixed at that time and still has not been fixed after a week.

The good news is that the vulnerability does not look like something that someone using the plugin would need to worry about being exploited at this time for two reasons. First, the code is part of 2.0 theme engine, which is scheduled to be the default one in version 4.0, but at this point you have to manually enable it. We had a hard time finding out how to do that, so it doesn’t seem likely that it would be widely used at this point. Second, the code only is run if someone is using Payment Express as their payment processor.

So while it isn’t something that you should be concerned about being exploited at this point, it is concerning that vulnerability was and still is in the code.

The vulnerability exists because a database query was not properly done using a prepared statement. It would seems to us that with a plugin being used for ecommerce there would be a thorough review before new code was added, which should catch something like that.

What makes this more concerning is that after the vulnerability was identified it was not quickly fixed seeing as that would be easy to do. Due to the limited ability to exploit this you might make an argument that new version doesn’t need to be released immediately to fix it, but it should have been fixed in the publicly repository for the plugin, located on GitHub, by now and that has yet to happen either. As of today the file in question, checkout-results.php, had been last updated five months ago: