CVE-2022-39956

Executive Summary

CVE-2022-39956 is a partial rule-set bypass vulnerability in the OWASP ModSecurity Core Rule Set (CRS) that allows attackers to evade detection of malicious multipart HTTP payloads by using alternative character encoding schemes declared in the Content-Type or deprecated Content-Transfer-Encoding MIME header fields. All CRS versions from 3.0.x through 3.3.2 (including the then-current 3.2.1 and 3.3.2) are affected, meaning any web application firewall deployment relying on these rule sets can be bypassed for multipart request inspection. Successful exploitation could allow an attacker to deliver payloads (e.g., SQL injection, cross-site scripting, command injection) past the WAF to vulnerable backend applications that support the encoding schemes, with a CVSS score of 7.3 (High).

Technical Analysis

The OWASP ModSecurity Core Rule Set is a widely deployed set of generic attack-detection rules used with the ModSecurity web application firewall engine. The CRS parses incoming HTTP requests, decodes multiple layers of encoding (URL encoding, JSON, XML, etc.), and applies pattern-matching and anomaly-scoring rules to identify and block malicious traffic.

This vulnerability resides in the multipart form-data parsing and inspection path of the CRS. The NVD description states that the bypass is achieved by "submitting a payload that uses a character encoding scheme via the Content-Type or the deprecated Content-Transfer-Encoding multipart MIME header fields" — these encoding declarations cause the WAF engine to fail to decode and inspect the multipart payload body. The result is that the rule set's inspection logic processes the request as an encoded blob without applying its decoding logic, so attack signatures embedded in the payload bypass detection entirely.

The core issue is a mismatch between what the WAF decodes and what the backend application decodes. The multipart MIME standard allows each part to declare its own Content-Type with a charset parameter (e.g., Content-Type: text/plain; charset=utf-16) and, historically, a Content-Transfer-Encoding header (e.g., quoted-printable, base64, or custom encoding schemes). While backend frameworks and application servers may honor these decoding instructions and process the uploaded/parsed data after decoding, ModSecurity CRS did not — it inspected the raw bytes as received. An attacker who crafts a multipart payload using a non-default encoding scheme can therefore smuggle attack payloads (SQLi, XSS, path traversal, etc.) that remain encoded on the wire, invisible to CRS signature matching, yet are decoded and executed by the backend.

The NVD description notes that "a vulnerable backend that supports these encoding schemes can potentially be exploited." The bypass is only useful if the target backend interprets these encoding headers. The fix requires two components: an updated CRS version (3.2.2/3.3.3) and an updated ModSecurity engine version (v2.9.6 / v3.0.8), because the decode-and-reinspect logic is dependent on the engine's parser behavior.

The vulnerability affects the legacy CRS 3.0.x and 3.1.x branches, plus the actively maintained 3.2.1 and 3.3.2 releases at time of disclosure. No CVSS vector string was provided in the data, so the standard vector corresponds to a High-severity, network-exploitable, no-authentication vulnerability with partial CIA impact.

Exploitation Scenarios

No public PoC or exploit code is known for this vulnerability as of the data provided. The following attack chain is inferred from the vulnerability class and the NVD description.

Step 1 — Reconnaissance / Target Identification: An attacker identifies a target web application protected by a ModSecurity WAF running a vulnerable CRS version (3.0.x–3.3.2). Version identification may be performed via error messages, response headers (e.g., X-Powered-By or WAF-specific headers), or by sending benign multipart requests and observing anomaly-scoring behavior. The attacker also needs to confirm the backend application parses multipart MIME headers with an alternate encoding (e.g., a Java servlet, .NET, or Python framework that honors charset or Content-Transfer-Encoding decoding).

Step 2 — Triggering the Flaw: The attacker sends an HTTP POST request with Content-Type: multipart/form-data; boundary=.... Within one or more MIME parts, the attacker includes a Content-Type header with an unusual charset parameter (e.g., charset=utf-16, charset=iso-2022-jp, or a non-ASCII superset), or includes the deprecated Content-Transfer-Encoding: base64 (or quoted-printable) header on the part. The ModSecurity engine, due to the bug, does not perform the character-set conversion or content-transfer decoding on these parts, so CRS rules that look for plain-text attack signatures (e.g., ' OR 1=1--, <script>, ../../etc/passwd) see encoded bytes and fail to match.

Step 3 — Payload Execution: The payload embedded in the multipart part is encoded per the declared scheme. For example, a SQL injection payload in the username field could be UTF-16-encoded and sent with Content-Type: text/plain; charset=utf-16 inside the multipart part. The WAF sees UTF-16 bytes (e.g., \x00'\x00 \x00O\x00R\x00...) and the rule set's regexes do not match. The backend, honoring the charset declaration, decodes the bytes to ASCII/UTF-8 and processes the SQLi payload against its database layer. A similar mechanism applies to XSS in stored/user-content fields or OS command injection in filename parameters.

Step 4 — Post-Exploitation Impact: Once the WAF bypass is successful, the attacker can exploit whichever underlying application vulnerability was smuggled through. Depending on the application, this may result in SQL injection (database exfiltration, auth bypass), stored XSS (session hijacking, credential theft), or arbitrary file read/write. Because the WAF is a perimeter control, successful bypass means the attacker operates as though the WAF did not exist, with the only residual defense being the application's own input-validation hygiene. The CVSS 7.3 score reflects high attack complexity being low, no privileges required, no user interaction, and partial impacts to confidentiality, integrity, and availability.

Impact Assessment

• Business Impact: This is a WAF-bypass vulnerability, so the impact is indirect but severe: it neutralizes the primary network-layer defense for many organizations. Applications that rely solely on ModSecurity CRS for input filtering (and have weak in-application validation) become fully exploitable for the classes of attacks the CRS was designed to block — SQLi, XSS, command injection, path traversal, and others. This changes the effective security posture of the entire web tier.
• Affected Systems: All sites using OWASP CRS 3.0.x, 3.1.x, 3.2.1, or 3.3.2 behind ModSecurity v2.9.x or v3.0.x with multipart/form-data support (the default for file uploads and form submissions). The vulnerability is only exploitable if the backend honors the encoding headers. Cloud WAF providers and reverse proxies that embed or forward CRS rules may also be affected indirectly.
• Blast Radius: Network-level, no authentication required (AV:N / PR:N). Exploitation complexity is low from the attacker's perspective if they know which encodings the backend accepts. The CVSS of 7.3 (High) reflects partial but meaningful loss to confidentiality, integrity, and availability. The EPSS score of 0.00987 suggests low active exploitation probability; CISA KEV does not list this CVE, indicating no confirmed in-the-wild exploitation campaign as of the data cutoff.

Detection Guidance

Sigma Rule

title: ModSecurity CRS Multipart Encoding Bypass Attempt
id: 8f5bc3f2-1a04-4a13-9c22-8a8e7b9e0011
status: experimental
description: Detects HTTP multipart requests with non-standard charset or content-transfer-encoding headers that may indicate an attempt to bypass ModSecurity CRS detection.
author: Valtersit Threat Intel
logsource:
    category: webserver
    product: apache
detection:
    selection_multipart:
        http.content_type|startswith: 'multipart/form-data'
    selection_encoding:
        http.headers|contains|all:
            - 'charset=utf-16'
            - 'charset=utf-32'
            - 'charset=iso-2022'
            - 'charset=unicode'
            - 'Content-Transfer-Encoding'
    condition: selection_multipart and selection_encoding
falsepositives:
    - Legitimate applications that intentionally use non-UTF-8 charsets for multipart uploads
level: medium
tags:
    - attack.t1190
    - cve.2022-39956

YARA Rule

rule ModSecurity_CRS_Multipart_Encoding_Bypass {
    meta:
        author = "Valtersit Threat Intel"
        description = "Detects HTTP multipart content with unusual charset or Content-Transfer-Encoding that may bypass CRS"
        cve = "CVE-2022-39956"
        reference = "https://owasp.org/www-project-modsecurity-core-rule-set/"
        date = "2023-01-01"
        score = 70

    strings:
        $cte = "Content-Transfer-Encoding" nocase
        $cte_base64 = "Content-Transfer-Encoding: base64" nocase
        $cte_qp = "Content-Transfer-Encoding: quoted-printable" nocase
        $charset_16 = "charset=utf-16" nocase
        $charset_32 = "charset=utf-32" nocase
        $charset_2022 = "charset=iso-2022" nocase
        $charset_unicode = "charset=unicode" nocase
        $boundary = "boundary=" nocase

    condition:
        $boundary and 2 of ($cte*) or ($boundary and 1 of ($charset*) and 1 of ($cte*))
}

Suricata IDS Rule

alert http any any -> $HOME_NET any (msg:"CVE-2022-39956 ModSecurity CRS Multipart Encoding Bypass Attempt"; flow:to_server,established; http.method; content:"POST"; http.request_line; pcre:"/multipart\/form-data/i"; http.header_names; pcre:"/Content-Transfer-Encoding|charset=(utf-16|utf-32|iso-2022|unicode)/i"; classtype:web-application-attack; reference:cve,2022-39956; sid:4000560; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5m
  [ network where event.category == "http" and
    http.request.method == "POST" and
    http.request.content_type == "*multipart/form-data*" ]
  [ network where event.category == "http" and
    http.request.headers contains "*Content-Transfer-Encoding*" or
    http.request.headers contains "*charset=utf-16*" or
    http.request.headers contains "*charset=utf-32*" or
    http.request.headers contains "*charset=iso-2022*" ]

Splunk SPL Query

index=web sourcetype=access_combined
| eval is_multipart = if(match(cs_content_type, "multipart/form-data"), 1, 0)
| eval has_encoding = if(match(_raw, "(?i)(Content-Transfer-Encoding|charset=(utf-16|utf-32|iso-2022|unicode))"), 1, 0)
| where is_multipart=1 AND has_encoding=1
| stats count by src_ip, cs_uri_stem, cs_content_type, _raw
| sort - count

Wazuh OSSEC Rule

<group name="web,modsecurity,attack,">
  <rule id="100560" level="10">
    <decoded as="json">modsecurity</decoded>
    <field name="request_method">POST</field>
    <regex>Content-Type: multipart/form-data</regex>
    <regex>(?i)(Content-Transfer-Encoding|charset=(utf-16|utf-32|iso-2022|unicode))</regex>
    <description>Possible CVE-2022-39956 ModSecurity CRS multipart encoding bypass attempt</description>
    <mitre>
      <id>T1190</id>
    </mitre>
    <group>attack_exploitation,waf_bypass,</group>
  </rule>
</group>

Mitigation & Patch Guidance

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

1. Immediate Mitigations (until patched):

• Restrict or block Content-Transfer-Encoding headers in multipart MIME parts at the reverse proxy or load balancer level (e.g., Nginx, HAProxy) by stripping these headers.
• Enforce that all multipart Content-Type parts use only a whitelist of safe charsets (e.g., utf-8, iso-8859-1). Reject requests declaring other charsets.
• If the backend does not require multipart uploads from untrusted clients, disable file-upload endpoints temporarily or add IP allowlisting.

2. Patch/Upgrade Steps:

• Upgrade the OWASP CRS to version 3.2.2 or 3.3.3 (whichever matches your deployment branch).
• Simultaneously upgrade the ModSecurity engine to v2.9.6 (for ModSecurity 2.x) or v3.0.8 (for ModSecurity 3.x). The NVD description explicitly states the mitigation depends on the latest ModSecurity version — do not upgrade the CRS alone.
• For Debian-based systems, apply the security update from the Debian security tracker for modsecurity-crs. Confirm the installed package version matches the patched release.
• After upgrade, run the CRS default self-check to confirm both engine and ruleset version compatibility.

3. Long-Term Hardening:

• Implement defense-in-depth: do not rely on WAF rules as the sole input-validation layer. Ensure web applications perform their own robust input validation and parameterized queries.
• Deploy a second layer of detection (e.g., the Sigma/YARA/Suricata rules above) in front of or beside the WAF to catch encoding-based bypass attempts.
• Monitor for unusual charset declarations or Content-Transfer-Encoding headers in normal traffic baselines; alert on anomalies.
• Subscribe to upstream ModSecurity and CRS release notifications to apply future updates within a defined SLA (e.g., 7 days).

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-39956
2. OWASP ModSecurity Core Rule Set Project: https://owasp.org/www-project-modsecurity-core-rule-set/
3. OWASP CRS GitHub Advisory / Release Notes (v3.3.3): https://github.com/coreruleset/coreruleset/releases
4. Debian Security Tracker (modsecurity-crs): https://security-tracker.debian.org/tracker/CVE-2022-39956
5. ModSecurity Release Notes (v3.0.8 / v2.9.6): https://github.com/SpiderLabs/ModSecurity/releases

Threat actor activity / in-the-wild exploitation: As of the data provided, CISA KEV does not list this CVE, and no public exploit code or PoC has been identified. EPSS percentile of 59.3% suggests moderate attention but low observed exploitation probability. No specific threat actor campaigns have been publicly attributed to this vulnerability.