A spammer is using my cgiemail, what do I do?

More details on the specifics of cgiemail's vulnerability can be found here on SecurityFocus.com.

Step one is easy: disable the existing cgiemail on your system. Move it out of your cgi-bin directory or its equivalent or take away its execute status. Forms using it will now no longer work.

There is no official, or at least timely, support from MIT for cgiemail. However various folks have patched or fixed the exploit individually. One example for those that have the source code (it's part of the distribution available at MIT) is provided here.

Aside from replacing cgiemail with a patched or updated version the only real alternative is to find or build an alternative. One of the more popular is called FormMail.

I wanted something that was a little closer to a plug-in replacement for cgiemail to minimize changes to either the forms that use it or the templates used. I wrote tmail.pl which while not quite as full featured as cgiemail, tackles common cgiemail-like templates with more of an eye to security.

The major differences that tmail.pl introduces are:

• Template parameters are required by default. Unless explicitly stated otherwise, it generates an error if a parameter is used in a template but not present in the form's input.
• A new type of parameter has been created: "email". When a template indicates that a parameter is of type email, some rudimentary checks are made to ensure that the entered data is in fact somewhat like a valid email address.
• Additional restrictions can be placed on a parameter. Specifically the value can be scanned for newlines (the source of the current exploit). If one is found an error results.

In addition, tmail.pl is a Perl script and takes an additional form parameter which is the name of the template. The template is typically found relative to the location of the Perl script so they can be moved to the cgibin directory where they are not directly readable by site visitors.

tmail.pl can be downloaded here.