CVE-2022-39957

Executive Summary

CVE-2022-39957 is a response body inspection bypass vulnerability in the OWASP ModSecurity Core Rule Set (CRS). By crafting an HTTP Accept header that includes an optional charset parameter, a remote unauthenticated attacker can cause the WAF to receive response bodies in an encoded form that the firewall cannot decode, effectively evading detection rules that inspect response content. This affects legacy CRS versions 3.0.x and 3.1.x, as well as supported versions 3.2.1 and 3.3.2. The vulnerability has a CVSS score of 7.3, indicating high severity, and allows attackers to exfiltrate data from restricted resources that would ordinarily be blocked by the WAF.

Technical Analysis

The OWASP ModSecurity Core Rule Set is a widely deployed rule engine used with ModSecurity to provide web application firewall (WAF) protection. A core function of the CRS is detecting and blocking sensitive information leakage — for example, files containing credentials, configuration files with secrets, or source code inadvertently exposed by a web application.

The vulnerability resides in the way the CRS handles HTTP response bodies. When a web server responds to a client request, the Accept header in the HTTP request can include both a Media-Type and an optional charset parameter. The charset parameter, defined in the HTTP/1.1 specification (RFC 7231), allows the client to specify the character set in which the response should be encoded. Some servers honor this request and transcode the response body accordingly.

The attack mechanism is straightforward: an attacker sends a request to a target application with an Accept header that requests a response encoded in a non-standard or exotic charset. The origin server, if it honors the charset negotiation, returns the response body in that encoding. The ModSecurity CRS, depending on the version, attempts to decode response bodies to apply content inspection rules. However, for certain charsets, this decoding fails or is not implemented. As a result, the WAF fails to inspect the response body content, and sensitive data can traverse the firewall undetected.

The affected versions are all legacy CRS 3.0.x and 3.1.x releases, plus the then-current 3.2.1 and 3.3.2 versions. This indicates a fundamental flaw in the response body decoding logic that predates the 3.2.x branch. The fix, applied in CRS 3.2.2 and 3.3.3, presumably hardens the charset handling — either by whitelisting supported charsets, rejecting unknown ones, or ensuring that undecodable response bodies are treated as suspicious rather than ignored. The NVD description does not provide function names, class names, or specific rule identifiers, so implementation-level detail is insufficient — however, the attack class is clearly a content inspection evasion via encoding negotiation.

Exploitation Scenarios

The attack can be executed by an unauthenticated remote attacker against any web application using an affected OWASP CRS version. The Insufficient technical detail available means the full attack chain is inferred from the vulnerability class and the NVD description.

Step 1 — Reconnaissance/Target Identification: The attacker identifies a target web application protected by OWASP ModSecurity CRS. This can be done via HTTP response headers (e.g., Server: ModSecurity), error pages that reveal the WAF version, or public exploitation databases. The attacker must confirm the CRS version is in the affected range (3.0.x, 3.1.x, 3.2.1, or 3.3.2). Shodan searches for exposed ModSecurity instances can accelerate this.

Step 2 — Flaw Trigger: The attacker identifies a sensitive resource that the CRS would normally block from being returned in a response — for example, a .env file, a backup file, or an administrative endpoint that returns credentials. The attacker crafts a standard HTTP request (e.g., GET /restricted-resource HTTP/1.1), but includes an Accept header such as:

Accept: text/plain; charset=iso-2022-jp

The specific charset used must be one that the ModSecurity CRS decoder does not support or fails to decode. The origin web server, if it honors the charset parameter, transcodes the response body into that encoding.

Step 3 — Payload/Execution: At the vulnerability-class level, this is purely an encoding negotiation bypass. The attacker does not inject malicious payloads into the request; rather, the attack lies in the response handling. The server returns the sensitive resource encoded in an unrecognized charset. The CRS attempts to match its response rules against the raw byte stream, but because the body is in an unsupported encoding, either the decoding step throws an error (and the rule evaluation is skipped) or the content is so transformed that signature-based detection fails. The sensitive content is then delivered to the attacker in the HTTP response.

Step 4 — Post-Exploitation Impact: The attacker receives the full content of the restricted resource. If the resource is an environment file, the attacker obtains API keys, database credentials, or cloud secrets. If it is source code, the attacker gains knowledge of internal application logic and additional attack surface. This can pivot to lateral movement, further application compromise, or data exfiltration. Note that no public PoC is available; the attack chain is inferred from the vulnerability class and the NVD description.

Impact Assessment

The CVSS score of 7.3 (High) is appropriate given the attack vector is network-based (AV:N) with low attack complexity (AC:L). No user interaction or authentication is required (PR:N, UI:N). The exploit has a significant confidentiality impact (C:H) — the WAF's ability to block sensitive information disclosure is completely neutralized — with no direct integrity or availability impact (I:N, A:N). The scope is unchanged (S:U) because the compromise is limited to the resource the attacker requested.

The business impact is substantial for any organization relying on OWASP CRS as a compensating control for information leakage. Web applications that inadvertently expose sensitive files (misconfigured directories, server-side includes, backup archives) rely on the WAF as their last line of defense. This flaw removes that safety net entirely for the affected requests. Given that CRS 3.x is deployed on tens of thousands of web servers globally, the blast radius is broad. The EPSS score of 0.00800 (53.3rd percentile) suggests low current exploitation likelihood, but this is likely because the issue has only recently been disclosed — the CISA KEV list does not yet include this CVE, and no public PoC has been released. The high CVSS score coupled with trivial exploitation mechanics makes this a candidate for future inclusion in automated exploit chains.

Detection Guidance

Sigma Rule

title: ModSecurity CRS Response Body Bypass via Charset in Accept Header
id: e3d9b7c2-6a1f-4b8e-9c2d-5f1a3b7e9d21
status: experimental
description: Detects HTTP requests with Accept headers containing charset parameters that may bypass ModSecurity CRS response inspection
logsource:
  category: webserver
  product: apache
  definition: Requires HTTP access logs that include the Accept header
detection:
  selection:
    cs-method:
      - GET
      - POST
    cs-user-agent: '*'  # any UA
  filter:
    cs-accept|contains: 'charset='   # any charset param in Accept
  condition: selection and filter
falsepositives:
  - Legitimate clients that request specific charsets for accessibility reasons
  - Browsers that include charset in Accept header (rare)
level: medium

YARA Rule

rule CVE_2022_39957_ModSecurity_Charset_Bypass {
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects HTTP Accept headers with charset parameters targeting ModSecurity CRS bypass"
        cve = "CVE-2022-39957"
        date = "2024-01-01"
    strings:
        $accept_hdr = "Accept: " nocase
        $charset = "charset=" nocase
        $http_get = "GET " ascii
        $http_post = "POST " ascii
    condition:
        uint16(0) == 0x0d0a and
        ($accept_hdr at 0..512) and
        ($charset in (0..1024)) and
        (any of ($http_get, $http_post) in (0..256))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2022-39957 ModSecurity CRS Response Body Bypass via Accept Charset"; flow:established,to_server; content:"Accept"; http_header_names; content:"charset"; http_header; pcre:"/charset\s*=/iH"; classtype:attempted-admin; sid:10039957; rev:1;)

Elastic Detection

network where event.category == "network" and event.action == "connection" 
  and network.protocol == "http" 
  and http.request.method in ("GET", "POST")
  and http.request.headers.accept == "*charset*"

Splunk SPL Query

index=webserver sourcetype=access_combined
| regex form_data="(?i)charset="
| search http_method=GET OR http_method=POST
| eval is_suspicious = if(match(form_data, "(?i)charset\s*=(?!.*utf-8)"), 1, 0)
| where is_suspicious == 1
| stats count by src_ip, dest_ip, http_method, uri_path, form_data, status

Wazuh OSSEC Rule

<group name="modsecurity_crs,">
  <rule id="100399" level="10">
    <decoded_as>web-accesslog</decoded_as>
    <field name="accept" type="pcre2">(?i)charset\s*=</field>
    <description>CVE-2022-39957: ModSecurity CRS bypass attempt via charset parameter in Accept header</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack.initial_access,</group>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 — LIKELY (CNA and Debian independently confirm the fix).

Immediate mitigations:

1. If immediate upgrade is not possible, consider adding an additional WAF rule or reverse proxy layer that enforces a strict Accept header whitelist — for example, reject requests with any Accept header containing a charset parameter other than utf-8. This can be done at the web server or load balancer level.
2. Review and restrict the actual exposure of sensitive resources (.env, backups, config files) at the application/web server layer — do not depend solely on WAF rules as the last line of defense.
3. Monitor access logs for unusual charset= usage in Accept headers and alert on them (see detection rules above).

Patch/Upgrade Steps:

1. Upgrade the OWASP ModSecurity Core Rule Set to version 3.2.2 or 3.3.3 (depending on your supported branch) as recommended by the CNA and Debian.
2. For legacy deployments on CRS 3.0.x or 3.1.x, migrate to a supported branch (3.2.x or 3.3.x) and apply the latest patch.
3. After upgrade, verify that the CRS correctly logs and blocks responses with unsupported charset parameters — run a test request with an exotic Accept charset against a test resource.
4. Debian users should apply the latest package updates for modsecurity-crs as soon as they are published.

Long-term hardening:

1. Treat WAF response inspection as a defense-in-depth layer — do not rely on it as the sole mechanism for protecting sensitive files. Implement proper server-side access controls, deny-by-default static file serving, and directory traversal protection.
2. Implement regular patch management cycles for WAF rulesets — subscribe to OWASP CRS releases and evaluate updates in a staging environment prior to production deployment.
3. Consider adding an additional layer of response filtering via a security-aware reverse proxy or application-level content inspection security module.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-39957
2. OWASP ModSecurity Core Rule Set — Official GitHub: https://github.com/coreruleset/coreruleset
3. Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2022-39957
4. OWASP CRS Release Notes (3.3.3): https://github.com/coreruleset/coreruleset/releases/tag/v3.3.3

Threat actor activity: No known threat actor campaigns or exploit-in-the-wild evidence exist at the time of writing. No public exploit code or PoC has been released. The CISA Known Exploited Vulnerabilities (KEV) catalog does not include this CVE. The EPSS score of 0.008 (53.3rd percentile) indicates low observed exploitation activity, but the vulnerability's low exploitation complexity and high confidentiality impact make it a credible candidate for future inclusion in automated attack tooling.