OWASP CoreRuleSet Multipart Charset WAF Bypass (CVE-2026-21876)

Metadata

Summary

CVE-2026-21876 is a bypass in the OWASP Core Rule Set (CRS) rule 922110, which is meant to block multipart/form-data parts that declare a forbidden (non-ASCII-safe) character set such as IBM037/EBCDIC. The rule only inspects the charset of the last part in a multipart body; by placing the forbidden-charset part earlier and appending a harmless UTF-8 part last, an attacker satisfies the rule’s check while the origin application still decodes the earlier part using its own declared charset. Several backend stacks (Flask with the Python email parser, ASP.NET Core [FromForm], and Spring Boot on Undertow) decode multipart fields per-part rather than at the request level, so they faithfully reconstruct the smuggled payload (e.g., a <script> XSS string) even though the WAF believed the request was safe. The repository ships a full Docker lab (CRS proxy + each vulnerable backend) and a demo script that sends both a baseline (blocked) and bypass (passed) request. Fixed upstream in CRS 4.22.0 / 3.3.8.

Vulnerability Details

Root Cause

OWASP CRS rule 922110 validates the multipart charset only on the final MIME part of the request body instead of every part, so a forbidden charset placed in a non-last part slips past the WAF while still being decoded by charset-aware backends (Undertow, ASP.NET Core, and the demo Flask app using Python’s email parser).

Attack Vector

1. Attacker crafts a multipart/form-data body where the first part (e.g., username) uses a disallowed charset such as IBM037 and contains the actual malicious payload (e.g., <script>alert(1)</script>).
2. Attacker appends a second, throwaway part (e.g., dummy) using an allowed charset (utf-8).
3. The CRS-protected reverse proxy inspects only the last part’s charset, sees utf-8, and forwards the request (HTTP 200) instead of blocking it (HTTP 403).
4. The backend application decodes each part with its own declared charset, reconstructing the original payload from the first part and reflecting/processing it as if it had passed sanitization.

Impact

Allows attackers to smuggle payloads (e.g., stored/reflected XSS or other injection strings) past a CRS-protected WAF into applications that perform per-part multipart charset decoding, defeating the intended protection entirely for this input path.

Environment / Lab Setup

Target:   OWASP CRS reverse proxy (ModSecurity/nginx) in front of a Flask, ASP.NET Core, or Spring Boot (Undertow) backend
Attacker: Docker + Docker Compose, Python 3

Proof of Concept

PoC Script

See modsec_stand1/ (Flask), aspnet_stand/ (ASP.NET Core), springboot_stand/ and springboot_undertow_stand/ (Spring Boot) in this folder, each with its own docker-compose.yml and demo/send.py.

1
2
3

cd springboot_undertow_stand   # or aspnet_stand
docker compose up --build
python3 demo/send.py           # BASELINE -> 403 (blocked), BYPASS -> 200 + reconstructed payload

Each stand spins up the CRS-protected proxy and a vulnerable backend, then demo/send.py sends a baseline multipart request (charset violation in the last part, correctly blocked) followed by the bypass variant (charset violation in an earlier part, forwarded and decoded by the backend).

Detection & Indicators of Compromise

Signs of compromise:

• Multipart requests with mixed/unusual per-part charsets that were not blocked by the WAF
• Reflected content in application responses matching bytes that decode only under a rare charset (e.g., IBM037)
• CRS rule 922110 hit-count anomalies or absence of expected 403 responses for crafted multipart traffic

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/daytriftnewgen/CVE-2026-21876 on 2026-07-05.