CVE-2026-107835

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Prior to 3.8.1, internal/cookies.ParseCookies in internal/cookies/cookies.go handles boundary ASCII control characters and control-only or empty cookie names differently from several backend cookie parsers. An unauthenticated attacker can craft a Cookie header so Coraza indexes or drops a cookie under a different name or value from the backend application, causing rules targeting REQUEST_COOKIES or REQUEST_COOKIES_NAMES to miss application-visible attacker data. Exploitation depends on the backend parser and affected rule scope, and interior control characters with inconsistent backend behavior are outside this advisory's remediation. This issue is fixed in version 3.8.1.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Prior to 3.8.1, internal/cookies.ParseCookies in internal/cookies/cookies.go handles boundary ASCII control characters and control-only or empty cookie names differently from several backend cookie parsers. An unauthenticated attacker can craft a Cookie header so Coraza indexes or drops a cookie under a different name or value from the backend application, causing rules targeting REQUEST_COOKIES or REQUEST_COOKIES_NAMES to miss application-visible attacker data. Exploitation depends on the backend parser and affected rule scope, and interior control characters with inconsistent backend behavior are outside this advisory's remediation. This issue is fixed in version 3.8.1.

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,…

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Prior to 3.8.1, internal/cookies.ParseCookies in internal/cookies/cookies.go handles boundary ASCII control characters and control-only or empty cookie names differently from several backend cookie parsers. An unauthenticated attacker can craft a Cookie header so Coraza indexes or drops a cookie under a different name or value from the backend application, causing rules targeting REQUEST_COOKIES or REQUEST_COOKIES_NAMES to miss application-visible attacker data. Exploitation depends on the backend parser and affected rule scope, and interior control characters with inconsistent backend behavior are outside this advisory's remediation. This issue is fixed in version 3.8.1.

OWASP Coraza WAF is a golang modsecurity compatible web application firewall library. Prior to 3.8.1, internal/cookies.ParseCookies in internal/cookies/cookies.go handles boundary ASCII control characters and control-only or empty cookie names differently from several backend cookie parsers. An unauthenticated attacker can craft a Cookie header so Coraza indexes or drops a cookie under a different name or value from the backend application, causing rules targeting REQUEST_COOKIES or REQUEST_COOKIES_NAMES to miss application-visible attacker data. Exploitation depends on the backend parser and affected rule scope, and interior control characters with inconsistent backend behavior are outside this advisory's remediation. This issue is fixed in version 3.8.1.

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,…

Coraza has Cookie Parser Confusion in github.com/corazawaf/coraza