CVE-2022-39955

Executive Summary

CVE-2022-39955 is a partial rule set bypass in the OWASP ModSecurity Core Rule Set (CRS) that allows an attacker to evade detection by submitting an HTTP request with a specially crafted Content-Type header declaring multiple charset values. The vulnerability affects CRS versions 3.0.x, 3.1.x, 3.2.1, and 3.3.2; both legacy and currently supported branches are impacted. Successful exploitation enables an attacker to deliver encoded payloads that bypass CRS detection rules, with the payload subsequently decoded by a vulnerable back-end server, potentially leading to injection attacks (SQL injection, XSS, or command injection) against the target application.

The vulnerability carries a CVSS score of 7.3 (High), reflecting the low complexity of exploitation and the high confidentiality impact. While no public exploit code is currently available and the CVE is not listed on the CISA KEV catalog, the EPSS score of 0.01157 (64.2 percentile) indicates that threat actors are actively monitoring this vulnerability class. The patch availability is well-confirmed across two independent sources (CNA and Debian), making the upgrade path clear and urgent for all affected deployments.

Technical Analysis

The OWASP ModSecurity Core Rule Set is a widely deployed Web Application Firewall (WAF) rule engine used to detect and block common web-based attacks. CRS operates by inspecting HTTP request components—including headers, URI parameters, and body content—against a comprehensive set of detection rules. The vulnerability arises from how CRS parses and validates the Content-Type header field.

When an HTTP request is sent, the Content-Type header may declare both a media type (e.g., application/x-www-form-urlencoded) and one or more character encoding schemes via the charset parameter (e.g., charset=utf-8). The CRS includes a configurable allow-list that determines which charset values are acceptable. Under default and supported configurations, CRS validates the charset parameter to ensure it matches expected encoding schemes before applying body-parsing and rule-decoding logic.

The flaw in CVE-2022-39955 is that CRS fails to properly handle a Content-Type header that declares multiple charset names. By submitting a specially crafted header—for example, Content-Type: application/x-www-form-urlencoded; charset=utf-8; charset=iso-8859-1—CRS may either: (1) validate only the first charset parameter while ignoring the second, or (2) incorrectly parse the header such that the allow-list check is bypassed entirely. The result is that CRS treats the payload as belonging to a character encoding it may not fully decode or inspect, allowing encoded payloads to pass through the WAF undetected.

The root cause is a parsing ambiguity in the HTTP header syntax itself. RFC 7231 permits multiple parameters in a field value, but the CRS parser does not correctly reconcile the presence of duplicate charset attributes when the allow-list validation is performed. The allow-list logic checks for the existence of a charset token but does not correctly reject or re-validate when more than one charset is declared. A back-end server—depending on its own Content-Type parser—may subsequently decode the payload using the last declared charset (or the first unsupported one), resulting in a decoding mismatch between what CRS inspected and what the application consumed.

For instance, an attacker could URL-encode payload bytes using a charset that CRS's rule set does not detect (e.g., iso-8859-1) while declaring a benign charset (e.g., utf-8) first to pass the allow-list. The back-end decodes using the malicious charset, and CRS never sees the decoded payload. This is a classic parser differential—the WAF and the application disagree on how to interpret the incoming bytes.

The attack surface is any web application behind ModSecurity with the CRS rule set enabled, where rules depend on decoding content prior to inspection. The vulnerability affects the core rule parsing logic, meaning that all rule categories (SQL injection, XSS, command injection, path traversal) are potentially bypassable for payloads delivered via this header manipulation technique.

Exploitation Scenarios

Step 1: Reconnaissance / Target Identification An attacker first identifies a target web application protected by ModSecurity with the CRS rule set. This is typically discovered via HTTP response headers (e.g., Server: ModSecurity), bypass behavior testing (sending obvious attack payloads and observing whether they are blocked), or by fingerprinting specific error responses that reveal WAF presence. The attacker may also use Shodan queries such as http.title:"ModSecurity" or http.body:"OWASP Core Rule Set" to identify internet-facing assets using the vulnerable CRS.

Step 2: Triggering the Flaw Class Once a target is confirmed, the attacker crafts HTTP requests with a Content-Type header that declares multiple charset parameters. The attacker sets the first charset to a value present in the CRS allow-list (e.g., utf-8) to pass any header validation checks. A second charset value is then appended (e.g., iso-8859-1), which the back-end application honors during body decoding. This exploits the parser differential: CRS validates only the first charset, while the application uses the second.

Step 3: Payload / Execution Method Malicious payloads—such as SQL injection strings or XSS vectors—are encoded according to the second charset's rules. For example, with iso-8859-1, an attacker might send bytes that represent a Unicode-compatible injection sequence when interpreted by the back-end, but which CRS fails to decode into a recognizable attack pattern. Because CRS inspects the body using the first (validated) charset, the encoded payload does not match any detection signatures, and the request is forwarded to the application. The back-end server then decodes the payload using the declared (malicious) charset and processes it in an unsafe manner—executing SQL queries, reflecting script content, or triggering command execution.

Step 4: Post-Exploitation Impact Successful exploitation results in the WAF being completely ineffective against that specific request. Depending on the application's backend, an attacker can achieve: SQL injection leading to data exfiltration; XSS allowing session hijacking or client-side code execution; or OS command injection providing remote access. The blast radius is limited only by the application's own security posture—the WAF layer has been removed from the equation for the crafted request.

Note: No public PoC is available for this CVE; the attack chain is inferred from the vulnerability class and NVD description. The actual charset values that successfully bypass CRS may vary depending on the specific CRS version and configuration.

Impact Assessment

The vulnerability carries a CVSS score of 7.3 (High), with a vector emphasizing network-based, low-complexity, unauthenticated exploitation (AV:N/AC:L/PR:N/UI:N). The confidentiality impact is rated High (C:H), meaning successful exploitation can lead to substantial data disclosure—typically databases behind the WAF. Integrity and availability impacts are rated Low (I:L/A:L), reflecting that the vulnerability enables targeted attacks rather than full system compromise or denial-of-service.

Business Impact: Organizations running affected CRS versions are exposed to one of the most damaging scenarios for a WAF deployment—a silent bypass. Security teams may believe they are protected by CRS rule sets while in reality attackers can deliver arbitrary payloads through a simple header manipulation. The primary business risk is data breach: SQL injection against databases behind the WAF can result in customer data exfiltration, credential theft, or financial fraud.

Affected Systems: All deployments using OWASP ModSecurity CRS 3.0.x, 3.1.x, 3.2.1, or 3.3.2. This includes Apache, Nginx, and IIS environments where ModSecurity is compiled as a module, as well as commercial WAF products that embed CRS as their rule engine. Cloud-hosted service providers using CRS-based filtering may also be impacted if they have not applied the upgrade.

Blast Radius: While the immediate affected component is the WAF layer, the actual impact cascades to every application protected by the vulnerable CRS. A single exploited instance can give an attacker access to databases, internal services, and potentially pivot deeper into the network if the web application has further privileges. The EPSS percentile of 64.2% indicates elevated ongoing threat activity targeting this vulnerability class.

Detection Guidance

Sigma Rule

title: OWASP CRS Bypass via Multiple Content-Type Charset Parameters
id: 9c54e049-99f1-4c2c-9a3e-2d6f7a8b1c2d
status: experimental
description: Detects HTTP requests with multiple charset parameters in the Content-Type header, indicative of attempts to bypass OWASP ModSecurity CRS allow-list validation.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2022-39955
author: Valters IT Security Team
date: 2025/03/25
tags:
    - attack.t1190
    - cve.2022.39955
    - attacker.waf-bypass
logsource:
    category: webserver
    product: apache
    definition: 'Requires access logs or reverse proxy logs that capture full HTTP headers.'
detection:
    selection:
        cs-method:
            - 'GET'
            - 'POST'
            - 'PUT'
            - 'PATCH'
        cs-headers.content-type|contains:
            - 'charset='
    filter_multi_charset:
        cs-headers.content-type|re: '(?i)(charset\s*=\s*[^\s;]+).*(charset\s*=\s*[^\s;]+)'
    condition: selection and filter_multi_charset
falsepositives:
    - Application frameworks that legitimately send multiple charset declarations in a single Content-Type header (rare)
    - Misconfigured client libraries
level: high

YARA Rule

rule CVE_2022_39955_CRS_Charset_Bypass {
    meta:
        author = "Valters IT Security Team"
        description = "Detects HTTP traffic with multiple Content-Type charset parameters indicating CVE-2022-39955 exploitation attempts"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2022-39955"
        date = "2025-03-25"
        cve = "2022-39955"
        score = 80
    strings:
        $charset1 = "charset=" nocase
        $charset2 = "charset=" nocase
        $semicolon = ";" 
        $content_type = "Content-Type:" nocase
        $url_encoded = "application/x-www-form-urlencoded" nocase
        $multipart = "multipart/form-data" nocase
    condition:
        #charset1 >= 2 and
        $content_type and
        ($url_encoded or $multipart) and
        uint8(0) >= 0x20 and uint8(0) <= 0x7E
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2022-39955 OWASP CRS Charset Bypass Attempt"; flow:to_server,established; content:"charset="; http_header; nocase; pcre:"/(?i)(charset\s*=\s*[^\s;]+);[^;\r\n]*charset\s*=/"; sid:20220399; rev:1; metadata:attack_target Web_Server, CVE CVE-2022-39955, tag waf-bypass; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2022-39955; classtype:attempted-admin; priority:1;)

Elastic Detection

sequence by source.ip with maxspan=30s
  [network where event.action == "connection_established"]
  [http where http.request.method in ("POST", "PUT", "PATCH") and
     http.request.headers["content-type"] like "*charset=*charset=*" or
     wildcard(http.request.headers["content-type"], "*charset=*;*charset=*")]

Splunk SPL Query

index=web sourcetype=modsecurity:access OR sourcetype=apache:access
| rex field=content_type "charset=(?P<charset1>[^;]+)"
| rex field=content_type "(?:.*;.*charset=(?P<charset2>[^;]+))"
| where isnotnull(charset2) AND charset1 != charset2
| stats count by src_ip, uri, content_type, _time
| sort - _time

Wazuh OSSEC Rule

<group name="waf-bypass,">
  <rule id="100399" level="15">
    <decoded_as>web-accesslog</decoded_as>
    <field name="content_type">\.*charset=.*charset=\.*</field>
    <description>CVE-2022-39955: OWASP CRS bypass via multiple Content-Type charset parameters detected</description>
    <group>waf-bypass,attack,t1190,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
    <options>no_full_log</options>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 — LIKELY. Two independent sources (CNA and Debian) confirm the fix. The patch addresses the parsing logic to correctly handle Content-Type headers with multiple charset declarations, ensuring that the allow-list is enforced against all declared charsets.

Immediate Mitigations (before patching):

1. Restrict Content-Type filtering at the reverse proxy or load balancer level: block or log any request where the Content-Type header contains more than one charset parameter. This can be done with a simple Lua/OpenResty hook, Apache mod_rewrite rule, or Nginx if directive checking against the Content-Type variable.
2. Enforce strict Content-Type validation downstream of ModSecurity: configure the application server to reject or ignore requests with ambiguous Content-Type declarations. Most modern frameworks (e.g., Spring, Express, Django) can be configured to fail closed on malformed headers.
3. Temporarily disable body-parsing detection rules that rely on charset-decoded inspection and instead enable signature-based rules that do not require body decoding (accepting potential false negatives for encoded payloads).
4. Add out-of-band monitoring (IDS/IPS rules above) to detect and alert on requests with multiple charset declarations, allowing SOC teams to manually review and block such traffic.

Patch / Upgrade Path:

1. For CRS 3.2.x users: Upgrade to OWASP CRS version 3.2.2 or later. The patch is included in the official release.
2. For CRS 3.3.x users: Upgrade to OWASP CRS version 3.3.3 or later.
3. For legacy 3.0.x and 3.1.x: Upgrade to any currently supported version (3.2.2+ or 3.3.3+)—legacy branches are no longer maintained and will not receive patches.
4. Debian users: Apply the backported fix via standard package manager (apt-get update && apt-get upgrade modsecurity-crs). Confirm the installed version includes the CVE-2022-39955 fix (≥3.2.2-1).
5. After upgrading, verify the fix by sending a test request with multiple charset parameters and confirming that ModSecurity applies allow-list validation to all declared charsets.

Long-Term Hardening:

1. Adopt fail-closed principles: Configure ModSecurity with SecRuleEngine On and SecDefaultAction "phase:2,deny,status:403,log" so that any parsing ambiguity (rather than just a detected rule match) results in request rejection.
2. Maintain a CSIRT review process for CRS version upgrades: subscribe to the OWASP CRS mailing list and security advisories to receive timely notifications of vulnerabilities and patches.
3. Implement request normalization at the edge: Use a dedicated request-parsing proxy (e.g., HAProxy with body inspection) to canonicalize Content-Type headers before they reach ModSecurity, ensuring only a single, unambiguous charset value is ever forwarded.
4. Regular penetration testing should include tests for WAF parsing differentials—crafting requests that the application and WAF interpret differently—to uncover bypasses before attackers do.
5. Monitor EPSS and CISA KEV feeds for this CVE periodically, as active exploitation status may change; adjust detection rule priorities accordingly.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2022-39955 — Official CVE record with NVD description and CVSS score.
2. OWASP CRS GitHub Advisories: https://github.com/coreruleset/coreruleset/security/advisories — Contains the official advisory for CVE-2022-39955, including patched version details.
3. OWASP CRS Release Notes (3.3.3): https://github.com/coreruleset/coreruleset/releases/tag/v3.3.3 — Official release containing the fix; release notes describe the Content-Type charset parsing fix.
4. Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2022-39955 — Debian's tracking record confirming the availability of a backported patch for the modsecurity-crs package.
5. OWASP Core Rule Set Official Site: https://owasp.org/www-project-modsecurity-core-rule-set/ — Project page for documentation on the rule set, configuration options (including charset allow-list), and upgrade guides.

Threat Actor / Exploit-in-the-Wild Evidence: No public exploit code is available as of this report's date. The CVE is not listed on the CISA KEV catalog, and no confirmed in-the-wild exploitation has been reported in public threat intelligence feeds. However, the EPSS score (0.01157, 64.2 percentile) indicates a higher-than-average probability of active exploit development or awareness among threat actors. Organizations should treat this as a routine but urgent patching priority, given the ease of exploitation and the potential for silent WAF bypass.