Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify coraza-spoa/proxy-wasm integration
-
DeliveryEmbed raw control byte in query string
-
Exploiturl.ParseRequestURI fails on malformed target
-
ExecutionARGS_GET/QUERY_STRING left empty
-
PersistGET-side CRS rules fail to match
-
ImpactPayload reaches downstream application
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | 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. |
| Impact | 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. |
| Exploit ScenarioDerived | 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. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 09, 2026
GET-side WAF rule bypass in OWASP Coraza WAF 3.0.0 through 3.7.x lets unauthenticated attackers evade signature matching when the library is deployed through non-net/http integrations such as coraza-spoa, coraza-proxy-wasm, or custom FFI/WASM hosts. When a URI containing a raw control byte (0x00-0x1F or 0x7F) makes Go's url.ParseRequestURI fail, Coraza's error branch leaves QUERY_STRING, ARGS_GET, ARGS_GET_NAMES, and the GET-derived portion of ARGS empty, so rules targeting those variables - the default target set for most OWASP CRS GET-side rules - never fire on the attacker-controlled query content, even though a downstream component may still parse and act on it. The bundled coraza/v3/http integration is unaffected because Go net/http rejects such malformed request targets with a 400 before Coraza is invoked, and exploitation additionally requires a backend that still consumes the dropped parameters, so this is a genuine but defense-in-depth-only bypass; no public exploit code was identified at time of analysis and CVSS is 4.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N). Fixed in 3.8.0.
RemediationAI
Vendor-released patch: 3.8.0. Upgrade the Go module github.com/corazawaf/coraza/v3 to v3.8.0 or later, which restores best-effort query-string and ARGS_GET population by splitting the raw URI on "?" when url.ParseRequestURI fails, wires up a dedicated URI_PARSE_ERROR variable, and makes it usable in phase 1 rules; the change is in commit 0321af96cef18fbafb40980cf075d7cc449a66fa and the release is at https://github.com/corazawaf/coraza/releases/tag/v3.8.0, with the advisory at https://github.com/corazawaf/coraza/security/advisories/GHSA-x26q-wvhg-fh4m. If upgrading immediately is not possible, add the recommended rule from coraza.conf-recommended - SecRule URI_PARSE_ERROR "@eq 1" "id:'200009',phase:1,t:none,log,deny,status:400,msg:'URI failed to parse.'" - after patching, or apply the equivalent logic manually; the trade-off is that this denies any request whose URI fails parsing (including benign-but-malformed clients and some legacy scanners), so validate it against production traffic before enforcing, and consider running it in detection-only mode first. Note this mitigation depends on the URI_PARSE_ERROR variable being available, which only exists in 3.8.0 and later; on unpatched versions a compensating control is to reject request targets containing raw control bytes (0x00-0x1F or 0x7F) at the integration or reverse-proxy layer before they reach Coraza, accepting the same false-positive trade-off. The lowest-risk structural mitigation is to front the service with an integration that uses Go net/http or another HTTP server that rejects malformed request targets with a 400 - for example the bundled coraza/v3/http integration, which is not affected - though this may not be feasible for SPOA- or WASM-based deployments. Restricting Coraza's rule set to only REQUEST_URI_RAW-based signatures is not recommended, as it weakens coverage more broadly than this issue warrants.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in go, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The flaw is an improper input validation issue (CWE-20) in internal/corazawaf/transaction.go, specifically the ProcessURI function (lines ~834-866). Coraza calls url.ParseRequestURI on the request target; Go's net/url rejects any URI containing raw control bytes (NUL, bare CR/LF, tab, other 0x00-0x1F, and 0x7F). On the error path, the code set path = uri and REQUEST_URI_RAW correctly, but never called ExtractGetArguments, so QUERY_STRING stayed at its initial empty string and ARGS_GET / ARGS_GET_NAMES / the GET-derived union ARGS were left empty; REQUEST_FILENAME and REQUEST_BASENAME also absorbed the whole URI including any ?query suffix. The correct fallback logic - splitting on "?" and extracting GET arguments - existed in the source as a commented-out block referencing a URI_PARSE_ERROR variable that was never wired up, and URLENCODED_ERROR was set instead, which is indistinguishable from a body-decode failure without string matching. In WAF terms this is not a memory-safety or RCE issue but a detection gap: OWASP CRS GET-side signatures default to ARGS, ARGS_GET, ARGS_NAMES, ARGS_GET_NAMES, and QUERY_STRING, so payloads smuggled in a query string behind a control byte become invisible to those rules while remaining visible to the backend the WAF is supposed to protect. The bundled coraza/v3/http integration avoids the problem entirely because Go's net/http server rejects malformed request targets with a 400 response before Coraza sees them, which is why only integrations that forward raw request targets (coraza-spoa, coraza-proxy-wasm, custom FFI/WASM hosts) are exposed. The CPE cpe:2.3:a:corazawaf:coraza:*:*:*:*:*:*:*:* and the Go module go/github.com/corazawaf/coraza/v3 both point at the same vulnerable version range >= 3.0.0, < 3.8.0.
Know when Coraza gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N
Unauthenticated network attacker (PR:N/AV:N), but AC:H because it only affects non-net/http integrations with a lenient downstream; scope change (S:C) as the bypassed input hits the protected app, integrity-only impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
1DescriptionCVE.org
OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. From 3.0.0 until 3.8.0, ProcessURI in internal/corazawaf/transaction.go handles a url.ParseRequestURI failure by retaining the raw URI but leaving QUERY_STRING, ARGS_GET, ARGS_GET_NAMES, and the GET-derived portion of ARGS empty. An unauthenticated attacker can place control bytes in a URI passed directly by integrations such as coraza-spoa, coraza-proxy-wasm, custom FFI hosts, or WASM hosts, causing Coraza to omit query parameters that the downstream integration may still process and allowing rules targeting those variables to be bypassed. The bundled coraza/v3/http integration is not affected because Go net/http rejects such malformed request targets before calling Coraza. This issue is fixed in version 3.8.0.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Unauthenticated remote denial of service in the OWASP Coraza WAF Go library (versions 3.0.0 through 3.8.0) allows any cl
OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Rated high severity (CVSS 7.5), th
CPU exhaustion in OWASP Coraza WAF versions 3.0.0 through 3.7.x allows a remote, unauthenticated network attacker to pin
Resource exhaustion in OWASP Coraza WAF 3.0.0 through 3.7.x lets an unauthenticated remote attacker (CVSS vector PR:N/UI
Cookie-parser confusion in OWASP Coraza WAF prior to 3.8.1 allows unauthenticated remote attackers to hide cookie-carrie
EUVD-2026-95924
GHSA-x26q-wvhg-fh4m
NVD
CVE.org
EPSS
Exploit-DB