This Blog has Moved!

This blog is moving to


Thank you for visiting! Content will remain here for archival purposes.

How (not) to handle software vulnerability submissions

If you're a software vendor developing programs more complex than "Hello World", eventually you will face an issue with a security vulnerability in your products.

For those who don't know I currently have an automated crawler searching Pastebin for new exploits and vulnerabilities.  This crawler reports its results live via the Twitter hashtag #exploitAlert. Every once in a while if something catches my attention, I'll submit it to the software vendor.

For most vendors the process is very straightforward...just send an email or fill out a form.  For an example of the right way to allow submissions of security vulnerabilities take a look at Microsoft's method.

Recently a supposed "0 day" vulnerability for Parallels Plesk was found by my crawler (a permanent copy of this paste is available here).  I've never worked with Parallels software before, so I went to their website to try and find out where to submit a vulnerability.  Finally I found it was an option on their support form.

My jaw dropped when I saw the warning at the bottom of the support form...


Well that certainly puts a stopper on things.  I'm not a paying customer...so obviously I won't be able to continue.  And what's even worse...if I was a paying customer...I would be CHARGED for submitting a security vulnerability!

Policies such as the one above will only cause frustrated users to post the vulnerability publicly instead of through responsible disclosure.

If anyone from Parallels reads this I would like to encourage you to push for reform of your vulnerability submission practices.

No comments:

Post a Comment