CVE-2026-21876: OWASP CRS Multipart Detection Vulnerability

CVE-2026-21876 Overview

CVE-2026-21876 is a critical security bypass vulnerability in the OWASP Core Rule Set (CRS), a widely-used set of generic attack detection rules for web application firewalls. The vulnerability exists in rule 922110, which fails to properly process multipart requests containing multiple parts. When the first rule in a chain iterates over a collection (like MULTIPART_PART_HEADERS), capture variables (TX:0, TX:1) are overwritten with each iteration. This means only the last captured value is available to the chained rule, allowing malicious charsets in earlier parts to evade detection if a later part contains a legitimate charset.

Critical Impact

Attackers can bypass web application firewall protections by crafting multipart requests with malicious content in earlier parts, followed by legitimate content in later parts, effectively evading security detection.

Affected Products

• OWASP Core Rule Set versions prior to 4.22.0
• OWASP Core Rule Set versions prior to 3.3.8
• Compatible web application firewalls using vulnerable CRS versions (ModSecurity, Coraza, etc.)

Discovery Timeline

• January 8, 2026 - CVE-2026-21876 published to NVD
• January 8, 2026 - Last updated in NVD database

Technical Details for CVE-2026-21876

Vulnerability Analysis

This vulnerability is classified as CWE-794 (Incomplete Filtering of Multiple Instances of Special Elements), which accurately describes the root cause. The OWASP CRS rule 922110 is designed to validate charsets in multipart request headers, ensuring that only approved character encodings are used. However, the implementation contains a logic flaw in how it processes collections during rule chain iteration.

When processing multipart requests, ModSecurity rules iterate over the MULTIPART_PART_HEADERS collection to examine each part's Content-Type header. The capture mechanism stores matched values in transaction variables (TX:0, TX:1, etc.). The critical flaw is that these capture variables are global within the rule chain context—each iteration overwrites the previous capture. Consequently, when the chained rule executes its validation logic, it only sees the capture from the final iteration, completely missing any malicious content in preceding parts.

Root Cause

The root cause is the improper handling of captured regex values when iterating over collections in chained rules. The original rule design assumed that capture variables would be evaluated independently for each collection element. In reality, the ModSecurity engine overwrites capture variables with each iteration, and the chained rule only receives the last captured value. This is a fundamental misunderstanding of how the ModSecurity rule engine processes collections in conjunction with capture groups and rule chaining.

Attack Vector

An attacker can exploit this vulnerability by sending a multipart HTTP request where malicious charset specifications are placed in earlier parts of the request body, followed by a final part containing a legitimate charset. The attack requires network access to any web application protected by a vulnerable OWASP CRS installation. No authentication is required, and no user interaction is needed. The attacker crafts a multipart request with multiple Content-Type headers—earlier parts may contain dangerous charsets like utf-7 or other encodings that could enable further attacks, while the final part uses an allowed charset like utf-8. The WAF only validates the last charset and allows the entire request through.

The following patches from the CRS repository demonstrate the fix:

# Security patch from rules/REQUEST-922-MULTIPART-ATTACK.conf
# Source: https://github.com/coreruleset/coreruleset/commit/80d80473abf71bd49bf6d3c1ab221e3c74e4eb83

 # Only allow specific charsets same as Rule 920600
 # Note: this is in phase:2 because these are headers that come in the body
-SecRule MULTIPART_PART_HEADERS "@rx ^content-type\s*+:\s*+(.*)$" \
+#
+# How do these rules work:
+# * rule 922140 sets the multipart counter TX variable to 0
+#   note that this is why does not matter if more parts have the same name - see rule's test
+# * rule 922150 collects all multipart headers' 'Content-Type' value
+#   eg. 'text/plain; charset=utf-8'
+# * rule 922110 checks all the collected headers' content type and charset
+SecRule &MULTIPART_PART_HEADERS "@gt 0" \
+    "id:922140,\
+    phase:2,\
+    pass,\
+    t:none,\
+    nolog,\
+    tag:'OWASP_CRS',\
+    ver:'OWASP_CRS/3.3.7',\
+    setvar:'tx.multipart_headers_content_counter=0'"
+
+SecRule MULTIPART_PART_HEADERS "@rx ^content-type\s*:\s*(.*)$" \
+    "id:922150,\
+    phase:2,\
+    pass,\
+    capture,\
+    t:none,t:lowercase,\
+    nolog,\
+    tag:'OWASP_CRS',\
+    ver:'OWASP_CRS/3.3.7',\

The fix introduces a two-stage approach: rule 922140 initializes a counter variable, and rule 922150 collects all Content-Type values into indexed transaction variables, ensuring each multipart header is stored separately and can be validated individually by rule 922110.

Detection Methods for CVE-2026-21876

Indicators of Compromise

• Multipart HTTP requests with unusual or varying charset specifications across different parts
• Requests containing potentially dangerous charsets like utf-7, iso-2022-jp, or other non-standard encodings in non-final multipart sections
• Increased volume of multipart requests with many boundary parts from single sources
• WAF logs showing inconsistent charset detection patterns in multipart form submissions

Detection Strategies

• Review WAF logs for multipart requests that contain multiple Content-Type headers with different charset values
• Implement custom logging rules to capture all multipart part headers before rule chain processing occurs
• Deploy network monitoring to identify multipart requests with anomalous structures or excessive parts
• Compare WAF detection rates before and after patching to identify potential bypass attempts that previously succeeded

Monitoring Recommendations

• Enable verbose logging on rules 922110, 922140, and 922150 to track multipart header processing
• Monitor for sudden decreases in blocked requests related to charset violations, which may indicate bypass attempts
• Implement alerting for multipart requests containing more than typical number of parts
• Configure SentinelOne to correlate WAF bypass indicators with endpoint activity for comprehensive threat detection

How to Mitigate CVE-2026-21876

Immediate Actions Required

• Upgrade OWASP Core Rule Set to version 4.22.0 or 3.3.8 immediately
• Review recent WAF logs for multipart requests that may have bypassed charset validation
• Consider temporarily increasing logging verbosity on multipart-related rules during the patching window
• Audit any applications that process multipart uploads for potential secondary exploitation

Patch Information

OWASP has released patched versions that address this vulnerability. The fix restructures the rule chain to properly collect and validate all multipart Content-Type headers rather than relying on overwritten capture variables.

• Version 4.22.0: Available at GitHub Release v4.22.0
• Version 3.3.8: Available at GitHub Release v3.3.8

For additional technical details, refer to the GitHub Security Advisory GHSA-36fv-25j3-r2c5.

Workarounds

• If immediate patching is not possible, consider implementing custom rules that explicitly validate charsets on all multipart parts before the chain executes
• Deploy additional application-layer validation of Content-Type headers in multipart requests independent of WAF rules
• Temporarily block or increase scrutiny on multipart requests with multiple parts from untrusted sources
• Use SentinelOne's web application protection features to provide defense-in-depth while WAF rules are updated

# Verify your current CRS version
cat /path/to/coreruleset/CHANGES | head -20

# Update CRS via git
cd /path/to/coreruleset
git fetch --tags
git checkout v4.22.0  # or v3.3.8 for 3.x branch

# Alternatively, download directly
wget https://github.com/coreruleset/coreruleset/archive/refs/tags/v4.22.0.tar.gz
tar -xzf v4.22.0.tar.gz

# Restart your WAF service after updating
systemctl restart modsecurity  # or appropriate service command