Coraza URL-encoded form body inspection bypass via Content-Type parameters

Severity: medium · CVSS 5.8 · Published 2026-10-08

Coraza, a Web Application Firewall engine, fails to inspect form request bodies when the Content-Type header includes media-type parameters like "charset=UTF-8". An attacker can use this to hide malicious form data from Coraza's inspection rules while the backend application still receives and parses the payload, enabling injection attacks that would normally be blocked.

Technologies: Coraza, github.com/corazawaf/coraza/v3 (Go). Vendors: Coraza, Go.

Quick answers

Is This vulnerability exploited in the wild?
No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
How severe is This vulnerability?
Medium severity, with a CVSS score of 5.8, published 8 October 2026.
Which products and versions are affected?
Coraza 3.8.0 and earlier; github.com/corazawaf/coraza/v3 (Go) >= 3.0.4, < 3.8.1.
Is there a fix for This vulnerability?
Yes: fixed in 3.8.1. Until then: Enable OWASP CRS rule 901340 (forceRequestBodyVariable=On) or rule 920620 (Content-Type header sanity check) to detect anomalies; deploy custom rules to reject requests with multiple Content-Type headers using `SecRule &REQUEST_HEADERS:Content-Type "@gt 1"`. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is This vulnerability attacked?
It is attacked over the network, in a software library.
Am I affected?
Check whether you run Coraza or github.com/corazawaf/coraza/v3 (Go) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • Fixed in: 3.8.1

Enable OWASP CRS rule 901340 (forceRequestBodyVariable=On) or rule 920620 (Content-Type header sanity check) to detect anomalies; deploy custom rules to reject requests with multiple Content-Type headers using `SecRule &REQUEST_HEADERS:Content-Type "@gt 1"`.

Technical details

The vulnerability stems from exact string matching on the Content-Type header in Transaction.AddRequestHeader; when parameters are present (e.g., "application/x-www-form-urlencoded; charset=UTF-8"), the comparison fails and reqbodyProcessor remains unset. ProcessRequestBody then silently skips body parsing, leaving ARGS_POST, REQUEST_BODY, and related variables empty, while the bundled middleware and backend still parse the body normally. A second variant affects duplicate Content-Type headers, where processor selection follows the last header but mimeType extraction (and backend parsing) follow the first, creating a desynchronization bypass.

Affected products

  • Coraza Coraza 3.8.0 and earlier

Timeline

  • 2026-10-08: disclosed: GHSA-w253-m66g-rx24 published

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.