GHSA-g4qm-m288-5cp9: Coraza WAF: cookie parser mismatch enables WAF bypass

GHSA-g4qm-m288-5cp9MEDIUM
Published October 8, 2026
CISO Take

Coraza, a Go web application firewall, parsed cookies differently from some backends because it only trimmed space and tab, not other ASCII control characters, around the cookie name and value. An attacker can pad a cookie with a control character next to the '=' sign so the WAF indexes a different cookie than the application does, hiding a payload from cookie-scoped rules. Severity is medium (CVSS 4.0, high attack complexity) and the bypass only works against specific backend parsers such as PHP and Python http.cookies, plus Node and Werkzeug for the 3.8.0 regression. There is no public exploit, no Nuclei template, no KEV listing and no EPSS data, but the package has 6,147 downstream dependents, so any WAF-fronted AI API or inference gateway using Coraza is in scope. Upgrade to github.com/corazawaf/coraza/v3 3.8.1, because 3.8.0 is only a partial fix, and do not rely on cookie-scoped rules alone for protecting AI endpoints.

Sources:GitHub AdvisoryATLAS

What is the risk?

Low-to-medium. Exploitation is network-reachable and needs no privileges or user interaction, but it depends on the specific backend cookie parser, hence high attack complexity. It is a defense-evasion primitive and not a direct compromise: the protected application must also be vulnerable to the hidden payload. No known exploitation, no public exploit, no scanner template. Exposure is greatest for AI/ML services (inference gateways, LLM APIs, ML dashboards) that sit behind Coraza and rely on cookie-based rules to block attacks.

How does the attack unfold?

Initial Access
Attacker sends an HTTP request with a crafted Cookie header containing a control character next to '=' to an AI service behind Coraza.
AML.T0049
Defense Evasion
Coraza parses a different cookie name or value than the backend, so cookie-scoped WAF rules do not match.
AML.T0107
Impact
The backend normalizes the cookie and processes the hidden payload, letting an attack reach the AI application uninspected.

What systems are affected?

PackageEcosystemVulnerable RangePatched
Anthropic Pythongo< 3.8.13.8.1
4.0K5.4K dependentsPushed 8d ago93% patched~9d to patchFull package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1
4.0 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AVACPRUISCIA
AVNetwork
ACHigh
PRNone
UINone
SChanged
CNone
ILow
ANone

What should I do?

1 step
  1. 1) Upgrade github.com/corazawaf/coraza/v3 to 3.8.1 or later; 3.8.0 is also affected. 2) Rebuild and redeploy every product that embeds Coraza (Caddy plugins, ingress and proxy filters, custom Go services), checking go.mod and SBOMs. 3) Validate that backend applications reject or normalize cookies containing control characters. 4) Do not depend only on cookie-name-scoped rules; add application-level input validation and defense in depth. 5) Detection: alert on Cookie headers containing bytes 0x00-0x1F or 0x7F in proxy or WAF logs, especially adjacent to '='.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.6-AI system operation and monitoring
NIST AI RMF
MANAGE 2.3-Responses to identified risks and unknown risks
OWASP LLM Top 10
LLM05-Improper Output Handling / Supply Chain Vulnerabilities

Frequently Asked Questions

What is GHSA-g4qm-m288-5cp9?

Coraza, a Go web application firewall, parsed cookies differently from some backends because it only trimmed space and tab, not other ASCII control characters, around the cookie name and value. An attacker can pad a cookie with a control character next to the '=' sign so the WAF indexes a different cookie than the application does, hiding a payload from cookie-scoped rules. Severity is medium (CVSS 4.0, high attack complexity) and the bypass only works against specific backend parsers such as PHP and Python http.cookies, plus Node and Werkzeug for the 3.8.0 regression. There is no public exploit, no Nuclei template, no KEV listing and no EPSS data, but the package has 6,147 downstream dependents, so any WAF-fronted AI API or inference gateway using Coraza is in scope. Upgrade to github.com/corazawaf/coraza/v3 3.8.1, because 3.8.0 is only a partial fix, and do not rely on cookie-scoped rules alone for protecting AI endpoints.

Is GHSA-g4qm-m288-5cp9 actively exploited?

No confirmed active exploitation of GHSA-g4qm-m288-5cp9 has been reported, but organizations should still patch proactively.

How to fix GHSA-g4qm-m288-5cp9?

1) Upgrade github.com/corazawaf/coraza/v3 to 3.8.1 or later; 3.8.0 is also affected. 2) Rebuild and redeploy every product that embeds Coraza (Caddy plugins, ingress and proxy filters, custom Go services), checking go.mod and SBOMs. 3) Validate that backend applications reject or normalize cookies containing control characters. 4) Do not depend only on cookie-name-scoped rules; add application-level input validation and defense in depth. 5) Detection: alert on Cookie headers containing bytes 0x00-0x1F or 0x7F in proxy or WAF logs, especially adjacent to '='.

What systems are affected by GHSA-g4qm-m288-5cp9?

This vulnerability affects the following AI/ML architecture patterns: WAF-protected LLM API gateways, model serving endpoints, ML web dashboards, agent backends behind reverse proxies.

What is the CVSS score for GHSA-g4qm-m288-5cp9?

GHSA-g4qm-m288-5cp9 has a CVSS v3.1 base score of 4.0 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

WAF-protected LLM API gatewaysmodel serving endpointsML web dashboardsagent backends behind reverse proxies

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application
AML.T0107Exploitation for Defense Evasion

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: MANAGE 2.3
OWASP LLM Top 10: LLM05

What are the technical details?

Original Advisory

## Summary Coraza's cookie parser (`internal/cookies.ParseCookies`) does not strip ASCII control characters (CTLs) from the edges of a cookie name/value before they're matched against `REQUEST_COOKIES` / `REQUEST_COOKIES_NAMES`. When a CTL sits directly next to the `=` separator, Coraza absorbs it into the adjacent name or value, while several backend cookie parsers trim it away — so the WAF and the application disagree about the cookie it just received. ## Root cause - `ParseCookies` (`internal/cookies/cookies.go:17,26,31`) trims via `net/textproto.TrimString`, which strips only space (`0x20`) and tab (`0x09`). - RFC 6265 §4.1.1 defines cookie `name` as an HTTP `token` and `value` as `cookie-octet`, both excluding the full C0 control range (`0x00–0x1F`, `0x7F`) — not just space/tab. - Input `a\v=\t'` (vertical tab `\v` next to `=`) keeps `\v` in the name (`a\v`), yielding name=`a\v`, value=`\t'`. ## Confirmed divergence from real backends | Implementation | Name | Value | |---|---|---| | Coraza (< 3.8.0) | `a\v` | `\t'` | | Python `http.cookies`, and the Werkzeug/Flask version in the report below | `a` | `'` | | PHP `$_COOKIE` | `a` | `\t'` | | Node.js `cookie` package | `a\v` | `'` | RFC 6265 itself calls this exact cookie-pair invalid, so there's no single spec-correct reference — but Coraza's boundary handling diverges from 2 of these 3 widely-used backends. Correction (2026-10-02): current Werkzeug (3.1.9, checked during review of the 3.8.1 follow-up) keeps `a\v` as the name, like Node's `cookie` package. The name divergence therefore applies to PHP and to Python's `http.cookies`, not to every Werkzeug version. ## Impact An attacker can pad a `Cookie` header with a CTL adjacent to `=` so Coraza indexes a different name/value than the backend application does. A `SecRule` scoped to a specific cookie name or value can then miss the cookie the application actually processes — a WAF bypass for cookie-carried attacks. ## Affected component `internal/cookies.ParseCookies`, consumed via `REQUEST_COOKIES` / `REQUEST_COOKIES_NAMES`. ## Fix Trim the full CTL range (not just space/tab) from both ends of the extracted name and value, treating a boundary-adjacent CTL as a delimiter rather than token content — aligning with RFC 6265's `token`/`cookie-octet` grammar. The fix does not attempt to resolve what happens when a CTL lands in the *interior* of an otherwise-plausible name (e.g. `ab\vcd`). That case is disputed among the backends themselves — Python's `http.cookies` rejects the whole pair, PHP strips the CTL from the middle, Node's `cookie` package keeps it — so there is no consensus to converge on. It is left as a separate follow-up rather than guessed at here. ### Implementation note The trim is deliberately hand-rolled (a byte-wise scan on `b <= ' ' || b == 0x7f`, which covers octets `0x00–0x20` plus `0x7F`) rather than delegated to the standard library. This is a conscious choice on a security hot path and should not be "simplified" away later: - **`strings.TrimFunc` was measured and rejected.** It invokes its predicate through a func value once per byte scanned, which Go cannot devirtualize through `strings.indexFunc`. On an Apple M2, parsing a 64 KiB CTL-saturated `Cookie` header costs **167.6 µs** via `TrimFunc` versus **33.9 µs** byte-wise — a ~5× CPU amplification handed to an attacker, on input that is attacker-controlled and parsed on every request. Allocation counts are identical either way; the cost is purely the per-byte indirect call. - **`strings.TrimSpace` is not a substitute.** It misses most of the CTL range (`0x00–0x08`, `0x0E–0x1F`, `0x7F`) and additionally trims `U+0085` and `U+00A0`, whose multi-byte UTF-8 encodings a backend would not strip — reintroducing the very parser-disagreement class this advisory closes. The byte-wise implementation was verified equivalent to a `TrimFunc`-based one across all 16,843,009 byte strings of length 0–3, including invalid UTF-8, with zero mismatches. `BenchmarkParseCookies/CTLFlood` guards the hot path against a future regression to a per-byte indirect call. ## Proof of Concept (original report) > Hi, @fzipi, i hope you doing well, i'm RelunSec from InsiteTech.jp > > we discovered a parser confusion in cookie parser, i used a simple flask app that print the cookies > > ```py > from flask import Flask, request > > app = Flask(__name__) > > @app.route('/') > def index(): > # 1. Print all cookies as a dictionary to your terminal console > print("All cookies:", request.cookies) > > return "Cookies logged in terminal!" > > if __name__ == '__main__': > app.run(debug=True) > ``` > > and a go setup > > ```go > package cookies > > import ( > "fmt" > "testing" > ) > > func TestParseCookie(t *testing.T) { > inputs := []string{ > "a\v=\t'", > } > > fmt.Println("\n==========================================") > fmt.Println(" COOKIE PARSE DIRECT LOCAL RUN ") > fmt.Println("==========================================") > > for _, input := range inputs { > // Calling the exact lowercase function name from the repo > cookies := ParseCookies(input) > > fmt.Printf("-> Input: %q\n", input) > fmt.Printf(" Output: %q\n", cookies) > fmt.Println("------------------------------------------") > } > fmt.Println("==========================================") > } > ``` > > i runned the go program as you can see > > ```go > relunsec@relunsec:~/software/coraza/internal/cookies$ go test > > ========================================== > COOKIE PARSE DIRECT LOCAL RUN > ========================================== > -> Input: "a\v=\t'" > Output: map["a\v":["\t'"]] > ------------------------------------------ > ========================================== > PASS > ok github.com/corazawaf/coraza/v3/internal/cookies 0.003s > ``` > > and then i sended a curl request to the python flask web app > > ```bash > relunsec@relunsec:~/software/coraza/internal/cookies$ curl 127.0.0.1:5000 -H $'Cookie: a\v=\t' > Cookies logged in terminal! > ``` > > and then i saw in the running flask app terminal > > ```python > All cookies: ImmutableMultiDict([('a', "'")]) > ``` > > as you can see python see that as the a cookie and the value of it is `'`, while coraza see it in a different name and a value > > an attacker can craft a crafted payload that evade cookie inspection and then perfom their attack ### Patched in 3.8.1 The 3.8.0 fix was incomplete. 3.8.1 completes it: trimming control characters in 3.8.0 turned a cookie whose name is only control characters (`\x01=payload`) into a cookie with an empty name, and empty names have always been skipped, so its value was no longer inspected. Node's `cookie` package (`{"\x01": "payload"}`, `{"": "payload"}`) and Werkzeug still pass such pairs to the application. 3.8.1 keeps them in `REQUEST_COOKIES` under the name `""`. This is an intentional deviation from ModSecurity v2 and v3, which skip empty names. Upgrade to 3.8.1; 3.8.0 is listed as affected. ### Severity (revised 2026-10-02) `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N` (4.0, Medium). Unchanged vector; precondition stated per the project's triage guidance. Attack Complexity is High because the bypass depends on a specific backend cookie parser: the original trim discrepancy affects backends that split `a\v` as `a` (PHP's `$_COOKIE`, Python's `http.cookies`) and only rules keyed on a cookie name, and the 3.8.0 regression affects backends that pass empty or control-character-only cookie names to the application (Node's `cookie` package, Werkzeug for `\x01`). Impact metrics follow the convention used across Coraza's WAF-bypass advisories: the vulnerable component is Coraza, but the impact lands on the protected application, so Scope is Changed. The bypass hides a payload from inspection; the application still has to be vulnerable to it, so Integrity is Low and Confidentiality is not scored separately. _AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project's triage guidance (AGENTS.md, "CVSS preconditions get verified, not copied from the report") and drafted this text. A human maintainer (fzipi) chose the `S:C/I:L` impact convention and directed this update._

Exploitation Scenario

An attacker targets an LLM API portal behind Coraza, with a Python backend, that has a rule blocking a malicious value in a specific cookie. The attacker sends a Cookie header such as 'a\v=<payload>' with a vertical tab next to the equals sign. Coraza indexes the name as 'a\v' and does not match the rule, while the backend parses the cookie as 'a' and processes the payload. The request passes inspection, and the attacker abuses the application flaw the WAF was meant to shield.

Weaknesses (CWE)

CWE-436 — Interpretation Conflict: Product A handles inputs or steps differently than Product B, which causes A to perform incorrect actions based on its perception of B's state.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N

Timeline

Published
October 8, 2026
Last Modified
October 8, 2026
First Seen
October 8, 2026

Related Vulnerabilities