GHSA-G4QM-M288-5CP9

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

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.

Affected component

internal/cookies.ParseCookies, consumed via REQUEST_COOKIES / REQUEST_COOKIES_NAMES.

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

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

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

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

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

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.