OWASP Coraza WAF EUVD-2026-95924

Requires deployment through a non-net/http integration that forwards the raw request target directly to Coraza - specifically coraza-spoa, coraza-proxy-wasm, or a custom FFI/WASM host - AND a downstream component that still parses and acts on the query parameters Coraza dropped. The attacker must place a raw control byte (0x00-0x1F or 0x7F, e.g. NUL, bare CR/LF, tab) in the URI so url.ParseRequestURI fails. The decisive limiting factor is that the bundled coraza/v3/http integration is NOT vulnerable because Go's net/http rejects such malformed request targets with a 400 before Coraza is ever invoked; deployments using only that integration are unaffected. Exploitation is unauthenticated (PR:N) but constrained to the specific vulnerable integrations and to rules targeting ARGS_GET/ARGS/ARGS_NAMES/ARGS_GET_NAMES/QUERY_STRING.

This is a genuine but defense-in-depth-only WAF rule bypass that merits a MEDIUM, not urgent, priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N = 4.0) is internally consistent with the description: network-reachable and unauthenticated (PR:N), but high complexity (AC:H) because exploitation only matters for specific non-net/http integrations AND requires a downstream component that still processes the dropped query parameters. The scope change (S:C) correctly reflects that the impact lands on the protected downstream application rather than Coraza itself, and the Integrity-Low/Confidentiality-None/Availability-None profile matches a signature-evasion issue rather than direct compromise. On the threat-intel side the signals are uniformly low: KEV status is NO (no confirmed active exploitation), no public exploit is indicated, and no EPSS score was supplied in the input - so exploitation probability cannot be quantified from the data given. There is no conflict between signals; they all point the same direction (low real-world urgency). The one caveat defenders must weigh is that this is a protection-bypass primitive: its true risk is entirely contingent on (a) whether a vulnerable integration is in use and (b) what the downstream app does with the smuggled parameters, so the 4.0 base score understates impact for a specific at-risk deployment and overstates it for the common bundled-HTTP deployment that is immune.

An organization fronts an application with Coraza via coraza-spoa (HAProxy) or coraza-proxy-wasm (Envoy) running OWASP CRS. An unauthenticated attacker sends a request whose query string contains a raw control byte (e.g. a NUL or bare CR/LF), causing url.ParseRequestURI to fail so Coraza leaves QUERY_STRING and ARGS_GET empty; CRS GET-side signatures therefore never match, and the malicious parameters pass through to the backend that still parses them. No public exploit code is identified at time of analysis, and AC:H reflects that the attacker must be hitting a non-net/http integration and relying on a lenient downstream parser.