First it should be mentioned that the vulnerability (concerned with input filtering) was posted to Bugtraq in April 2002, however the message wasn't as clear as it could have been (most likely because the poster did not thoroughly research the issue), which caused confusion, due to fact another popular script exists with the same name, that does not have that particular security issue.

On the 21st of February 2003 Rootsecure.net sent an email to the vendor containing details of the problem.  An email was received roughly an hour later asking for more information which was promptly supplied in the form of a demonstration set up using two servers, along with step by step instructions.  The vendor then wrote back two days later unable to replicate the issue (tested by Rootsecure.net on 3 different implementations of their product, and using a number of different client programs).  Details of exploit compatible client software (for both Windows and *nix) were sent to the vendor who was again unable to replicate it.  Next screenshots were sent, which resulted in the vendors first attempt at implementing a fix, which was sent to Rootsecure.net for testing.  The 'patch' was found to be ineffective, as it only made a single pass at incoming data, meaning the filter could be triggered, and would then leave the rest of the input untouched, however it was noted that the filter was case sensitive.  The Perl code used was similar to the following: $datain =~ s/filterthis/withthis/i; the code that should have been used was $datain =~ s/filterthis/withthis/ig; (the 'g' operator replaces every occurrence of "filterthis" with "withthis" rather than only the first one it finds).  The vendor implemented this suggestion, as the next script received successfully filtered out all potentially malicious input.  Therefore additional testing was carried out, and it was found that input filtering had only been implemented on the one specific variable name that Roosecure.net made up for the purpose of demonstrating the exploit.  An email was sent back recommending filtering should be present on all untrusted input.  The date is now the 14th of March, and Rootsecure.net has now received what the vendor called revision 6 of the code, which successfully solves the problem.

Rootsecure.net's advice: Vendors should look at their procedures for producing patches, before increasing numbers of people don't bother contacting them first and post issues straight to some of the excellent security mailing lists out there, such as Bugtraq.  This does also have the benefits of letting systems administrators best mitigate the risks themselves, and prompting vendors to swiftly correct the problem.

Background reading on disclosure practises - http://www.vulnwatch.org/disclosure.html