CVE-2026-73856 in ModSecurity
Summary
by MITRE • 11/05/2026
ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. From 3.0.0 until 3.0.17, src/transaction.cc compares a response Content-Type value against SecResponseBodyMimeType entries case-sensitively. A mixed-case response media type that is semantically equivalent to a configured lowercase type can therefore be treated as unconfigured, causing ModSecurity to skip RESPONSE_BODY inspection. An unauthenticated requester can then receive response content that a phase 4 rule would otherwise block, including sensitive error or debug data. This issue is fixed in version 3.0.17.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 11/05/2026
ModSecurity serves as a critical open-source web application firewall engine deployed across major HTTP servers such as Apache, IIS, and Nginx to filter and monitor HTTP traffic. A significant security flaw was identified within the response body inspection logic of ModSecurity versions ranging from 3.0.0 through 3.0.17. The vulnerability stems from a case-sensitivity issue in how the engine processes Content-Type headers during the RESPONSE_BODY phase, which is designated as Phase 4 in the ModSecurity processing pipeline. This specific phase is responsible for inspecting the body of HTTP responses to enforce security rules that might block sensitive data leakage or malicious content before it reaches the client.
The technical root cause lies in the comparison logic implemented within the src/transaction.cc module. When a response is received, ModSecurity checks whether the Content-Type header matches any entries defined in the SecResponseBodyMimeType configuration directive. In vulnerable versions, this comparison was performed strictly case-sensitively according to RFC standards for exact string matching rather than semantic equivalence. Consequently, if an application returns a media type with mixed-case characters that are semantically identical to a configured lowercase MIME type, such as returning text/HTML instead of the expected text/html, ModSecurity fails to recognize it as a managed response body. This mismatch causes the engine to incorrectly classify the response as unconfigured or irrelevant for inspection purposes.
The operational impact of this flaw is substantial because it effectively creates an evasion vector against Phase 4 security rules. Since the response body is skipped during inspection, any rule designed to detect and block sensitive information in the response payload becomes ineffective for these specific content types. An attacker can exploit this by manipulating the Content-Type header or targeting applications that return mixed-case MIME types to bypass protections intended to prevent data exfiltration. This allows unauthenticated requesters to receive potentially sensitive error messages, debug traces, stack dumps, or other internal application details that should have been blocked or sanitized by ModSecurity rulesets.
This vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to correctly validate and normalize input data (the Content-Type header) against expected security policies. Furthermore, it relates to ATT&CK technique T1537, which involves Communication via Distributed Component Object Model or similar protocols where attackers communicate directly with backdoors using non-standard channels; in this context, it represents a bypass of defensive detection mechanisms allowing unauthorized information disclosure. The flaw highlights the importance of case-insensitive matching for MIME types as per RFC 2046, which states that media type and subtype names are case-insensitive despite common convention to use lowercase.
To mitigate this risk, organizations running ModSecurity must upgrade immediately to version 3.0.17 or later where the comparison logic has been corrected to handle mixed-case MIME types appropriately. Until an upgrade is feasible, administrators should review their SecResponseBodyMimeType configurations and ensure that all expected response content types are explicitly listed in lowercase to minimize the attack surface. Additionally, implementing strict Content-Type validation at the web server level can help enforce consistent header formatting before it reaches the WAF engine. Regular auditing of ModSecurity rule sets against real-world traffic patterns is also recommended to identify any potential bypasses resulting from similar normalization issues.