Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class

apache 3375


Getting Apache unpatched application errors (code 3375) when scanning apps run in RHEL 6x64.  It doesn't recognize our version of Apache.  See attached screenshot.  Any patch in the works or setting I can set up?  I'd rather not flag it as a false positive if it can be properly recognized.  Thanks!


Labels (1)
3 Replies
Micro Focus Expert
Micro Focus Expert

Are you sure that the CheckId was 3375?  That comes back with an entirely different name and issue when searching the Policy Manager (in WebInspect 16.20).  This one also indicates that the fix is to switch to a newer release of Apache, so perhaps the issue is that WebInspect cannot fully identify the version of your Apache system.  I will pose this checkID 3375 to our research team and see what response they might have.

If you deem this finding a False Positive, you can right-click on it and set it as a FP.  To then filter this same item out of subsequent scans, you can Import the False Positives during the scan wizard or in the post-scan analysis (False Positives panel) by selecting this prior scan as the "template" of known FP.

Summary: Apache Chunked Encoding Overflow Test

Vulnerability ID: 3375
CWE ID: 120
Kingdom: Environment

A chunked encoding buffer overflow vulnerability was found on an Apache server. The HTTP specification (RFC 2068, section 3.6) requires web servers to allow a client to break up a request into multiple sections of a specific length. The Apache HTTP Server has a software flaw that misinterprets the size of the incoming data chunks. If exploited, a remote attacker may be able to execute arbitrary commands on the host running the vulnerable software. Recommendations include upgrading to a version of Apache HTTP Server that is no longer vulnerable to this issue.


How to verify or exploit the issue.

You can test for the issue by entering this information at a command line.

telnet ~RemoteHost~ ~Port~POST /x.html HTTP/1.1Host: ~RemoteHost~Transfer-Encoding: chunkedc00000000

If the connection terminates immediately, the server is vulnerable.

WARNING: This test will crash servers running on Windows and certain 64-bit Unix operating systems, resulting in a denial of service.


How to remediate the issue.

For Security Operations:

For sites running Apache 1.x, upgrade to version 1.3.26 or greater.
For sites running Apache 2.x, upgrade to version 2.0.39 or greater.

-- Habeas Data
Micro Focus Fortify Customers-Only Forums –
Cadet 2nd Class Cadet 2nd Class
Cadet 2nd Class


Yes, definitely 3375. I’m using 16.10. Here’s a screenshot.

I know I can mark it as a false positive, but just reporting the issue because I’d like to get the cleanest scan I can without having to mark too many false positives.


Michael T. Weber | CISSP |<>

Information Security Continuous Monitoring Assessor - Information Systems Security Staff

Rural Development – United States Department of Agriculture

4300 Goodfellow Blvd, Room 52C13

St Louis, MO 63120-0011

Desk: 314-457-4789 | Fax 314-457-4408<>

"Committed to the future of rural communities"

P — Go Green! Please consider the environment before printing this E-mail.

Micro Focus Expert
Micro Focus Expert

I am a bit mystified as to why your screen shot has a different name for the same CheckID.  According to the Policy Manager in WebInspect 16.20, this check was last updated 2/7/2013.

Here was the response I received from one of our researchers.  They feel that despite the version of your Apache system that it was the server's Response or lack of response (or timing delay in that response) that caused this finding to trigger, i.e. that you appear to have this issue despite having a modern Apache version in place.  Many of our DoS probes operate on this principal, that they send a payload that is just short of the exploit, and if there is a sizeable delay in response then that flags as vulnerable to the actual DoS attack, without (purposefully) bringing down the target.  See what you find using the CLI test steps detailed in the Execution section I copied in my earlier response.


This check actually sends a malformed request to exploit the vulnerability and expects that the server would fail to respond to it. Can you check with the customer if they indeed had a crash on the server? OR alternatively can you try to repeat the request as mentioned in the Execution section of the report?  If the response is an request fail vs. “application error” then the server should be vulnerable. It could also be that they have an appliance (firewall, load balancer, etc…) in between the application server and the WebInspect client that is processing the request and happens to run an older version of Apache! ( or happens to have an undisclosed similar vulnerability in its software! )


-- Habeas Data
Micro Focus Fortify Customers-Only Forums –
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.