A newly disclosed vulnerability in the OWASP Core Rule Set (CRS) allows attackers to bypass charset validation in web application firewalls (WAFs), enabling dangerous payloads to reach backend applications.
Tracked as CVE-2026-21876, the flaw affects CRS rule 922110 and can expose applications to cross-site scripting (XSS) and other encoding-based attacks.
Administrators are strongly advised to upgrade immediately and review historical logs for suspicious multipart requests using disallowed charsets.
| CVE ID | Component / Rule | Vulnerability Type | CVSS v3.1 / Severity |
| CVE-2026-21876 | OWASP CRS rule 922110 | Charset validation bypass | 9.3 (CRITICAL) |
How the charset validation bypass works
Rule 922110 is a Paranoia Level 1 (PL1) rule enabled by default in CRS. Its purpose is to validate charset parameters in Content-Type headers of multipart/form-data requests and block risky encodings such as UTF-7, UTF-16, UTF-32, Shift-JIS, EUC-JP, and other non-whitelisted character sets.
However, due to a logic issue in how ModSecurity processes chained rules over multipart collections, the rule only validated the charset of the last multipart section, ignoring malicious charsets used in earlier parts.
In a real-world attack scenario, an attacker could place a UTF-7–encoded XSS payload in the first multipart part using charset=utf-7, followed by a benign final part with charset=utf-8.
Because the captured charset value was overwritten during iteration and evaluated only once at the end, the WAF validated only the safe charset and allowed the request through.
This enabled UTF-7 XSS and other charset confusion attacks to bypass CRS protections and reach vulnerable backend applications.
The vulnerability affects CRS 3.3. x and CRS 4.0.0 through 4.21.0 across all supported engines, including ModSecurity 2.x, ModSecurity 3. x/ x/libmodsecurity, and Coraza.
Since the issue lies in the rule logic rather than the engine, all deployments using these versions are impacted.
The flaw is rated CRITICAL, with a CVSS v3.1 score of 9.3, reflecting network-based exploitation, no required authentication or user interaction, low attack complexity, and a scope change that bypasses the WAF boundary.
To address the issue, the CRS team redesigned rule 922110 and introduced helper rules 922140 and 922150.
The fix stores each multipart Content-Type value in uniquely indexed transaction variables and validates every detected charset, rather than only the last one.
This approach works consistently across all supported engines, avoids unsupported regex features, and adds minimal performance overhead. Fixes were released in CRS 4.22.0 and CRS 3.3.8.
Administrators are strongly advised to upgrade immediately and review historical logs for suspicious multipart requests using disallowed charsets.
Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.