OWASP CRS Vulnerability Allows Attackers to Bypass Charset Validation

A critical security vulnerability in the OWASP Core Rule Set (CRS) has been disclosed, allowing attackers to bypass charset validation in multipart form data requests.

The vulnerability, tracked as CVE-2026-21876 with a CVSS score of 9.3 (CRITICAL), affects all supported versions of CRS and has been present since the vulnerable rule was first introduced.

The flaw in rule 922110, which is enabled by default as a Paranoia Level 1 protection, allows attackers to deliver UTF-7-encoded XSS payloads and other charset-based attacks to backend applications.

The vulnerability stems from how ModSecurity’s chained rules process collection variables, validating only the final multipart part rather than all parts of a request.

“This is not a simple coding error, but rather an interaction between ModSecurity’s design, collection iteration mechanics, and how chained rules execute,” according to the vulnerability disclosure by Felipe Zipitria and the OWASP CRS team. Patches have already been released for CRS 4.22.0 and CRS 3.3.8 as of January 6, 2026.

Understanding the Vulnerability

The vulnerability exploits a fundamental behavior in how ModSecurity processes chained rules when iterating over collection variables.

Rule 922110 was designed to validate charset parameters in Content-Type headers within multipart/form-data requests, blocking dangerous encodings such as UTF-7, UTF-16, and UTF-32 that can be weaponized for XSS attacks.

However, the rule only validated the last multipart part’s charset parameter. When ModSecurity iterates through MULTIPART_PART_HEADERS during rule processing, each iteration overwrites the capture variable (TX:1) with the current value.

After all iterations are complete, the chained rule executes once with only the final captured value, leaving earlier parts unvalidated.

An attacker could craft a multipart request with a UTF-7 encoded XSS payload in the first part and a legitimate UTF-8 charset in the final part.

The vulnerable rule would only validate the legitimate final part, allowing the attack to bypass the WAF:

textContent-Type: text/plain; charset=utf-7
+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

Content-Type: text/plain; charset=utf-8
legitimate_data

In this example, the first part contains UTF-7 encoded JavaScript (+ADw-script+AD4- = <script>), but the rule only validates the second part, resulting in a bypass.

The vulnerability earned a CRITICAL rating because it crosses the security boundary between WAF protections and backend applications.

Attack vectors are trivial to construct, requiring no authentication or user interaction, and affect all CRS installations running versions 3.0.0 through 4.21.0.

The OWASP CRS team has released patched versions that address the vulnerability by validating all components rather than just the final one.

The fix introduces two new helper rules (922140 and 922150) that work alongside the updated rule 922110:

• CRS 4.x users: Upgrade to CRS 4.22.0 (released January 6, 2026)
• CRS 3.3.x users: Upgrade to CRS 3.3.8 (released January 6, 2026)

The patch uses an incremental counter mechanism to create unique storage keys for each captured charset value, then validates all stored values rather than relying on overwritten capture variables.

This approach maintains compatibility across ModSecurity v2, v3, and Coraza WAF engines.

Organizations deploying OWASP CRS should prioritize upgrading to the patched versions immediately.

The vulnerability enables attackers to deliver charset-encoded attacks that bypass WAF protections and reach vulnerable backend applications, making this one of the most critical CRS security issues in recent years.

No workaround is available for unpatched versions beyond disabling rule 922110 entirely, which would leave applications exposed to charset-based attack vectors.

Follow us on Google News , LinkedIn and X to Get More Instant Updates. Set Cyber Press as a Preferred Source in Google.