I have not verified whether or not both of these are security holes yet, but the first one is very probably a security hole. 1) overlong domain bug in Proxy mode Symptom: send a proxy request to the server, for instance GET http://overlongdomain HTTP/1.0 This is the same bug that's in Netscape 1.1. The domain buffer is a 256 byte buffer declared on the stack. (char host[256]) 2) too many headers from CGI script Symptom: HTScript.c allocates an array of pointers to char on the stack. This array has size 100. The loop where they parse the output of a CGI script is not bounds checked. To crash the server, create a CGI script that outputs a large number of headers before the document body. (I simply made a perl script that did for($i=0; $i<1000; $i++) { print "Header$i: $i\n") Although this bug can coredump the process servicing the request, I doubt it is exploitable. All that happens is an unchecked header_line[header_index++]=malloc(some space) gets executed. In the worst case, you overwrite the stack with excessive malloc pointers. You may be able to cause a foreign server to crash by having your own fake server return the exploit, and then getting the foreign server to read the headers by issuing a proxy request to your server. Suffice it to say, the CERN code is *littered* with temporary local stack arrays, and I'm guessing that many of them have faulty bounds checking (or none at all) -Ray