Coraza WAF CVE-2026-114100

Exploitation requires that the Coraza deployment rely on custom rules inspecting ARGS_POST or REQUEST_BODY to catch malicious payloads, and that a client send a valid urlencoded body with any media-type parameter (e.g. 'application/x-www-form-urlencoded; charset=UTF-8'); the backend must still parse the forwarded body. The decisive LIMITING factor is that the current OWASP CRS bundles rule 901340, which forces fallback inspection and neutralizes this bypass - so sites running an unmodified modern CRS are not affected, and only setups with custom body rules or CRS lacking 901340 are exposed. No authentication or user interaction is needed (PR:N/UI:N), and it works against default parsing behavior of the affected versions.

This is a genuine but moderate-priority WAF evasion issue, not a critical server compromise. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms it is remotely reachable by unauthenticated attackers with low complexity against default parsing behavior, but the impact metrics are deliberately limited to VI:L and SI:L (no confidentiality or availability impact), yielding a Medium 6.9 - which matches the vendor's own 'suggested severity: Medium'. The real risk is contextual: Coraza does not itself execute attacker code; the flaw only hides a request body from inspection, so actual harm depends entirely on whether the protected backend is independently vulnerable to whatever payload slips through. No EPSS score, no CISA KEV listing, and no explicit POC flag are present in the input, so there is no signal of active or probable exploitation - this appears to be a vendor/researcher-disclosed hardening issue (reported by VulnCheck) rather than an observed attack. Critically, the vendor states the current OWASP CRS ships rule 901340 that forces fallback inspection and mitigates this path, so sites running an unmodified modern CRS are NOT bypassed; the exposure is specific to deployments relying on custom ARGS_POST/REQUEST_BODY rules. Bottom line: patch in routine cycles - this is a defense-in-depth bypass, not a directly exploitable high-risk flaw.

An unauthenticated attacker targeting a backend protected by Coraza with custom body-inspection rules sends a POST with Content-Type 'application/x-www-form-urlencoded; charset=UTF-8'. Because Coraza's exact-match processor selection ignores the request due to the charset parameter, ARGS_POST and REQUEST_BODY stay empty and the body (e.g. SQLi/XSS/command-injection parameters) is never evaluated, yet the Go middleware forwards it and the backend parses it normally. No public exploit is identified in the input, but the advisory documents the exact deterministic technique, making reproduction trivial.