Vulnerability-Lookup

GHSA-G4QM-M288-5CP9

Vulnerability from github – Published: 2026-10-08 17:51 – Updated: 2026-10-08 17:51

Summary

Coraza has Cookie Parser Confusion

Details

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.

Severity

4.0 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/corazawaf/coraza/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-436"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T17:51:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nCoraza\u0027s cookie parser (`internal/cookies.ParseCookies`) does not strip ASCII control characters (CTLs) from the edges of a cookie name/value before they\u0027re 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 \u2014 so the WAF and the application disagree about the cookie it just received.\n\n## Root cause\n- `ParseCookies` (`internal/cookies/cookies.go:17,26,31`) trims via `net/textproto.TrimString`, which strips only space (`0x20`) and tab (`0x09`).\n- RFC 6265 \u00a74.1.1 defines cookie `name` as an HTTP `token` and `value` as `cookie-octet`, both excluding the full C0 control range (`0x00\u20130x1F`, `0x7F`) \u2014 not just space/tab.\n- Input `a\\v=\\t\u0027` (vertical tab `\\v` next to `=`) keeps `\\v` in the name (`a\\v`), yielding name=`a\\v`, value=`\\t\u0027`.\n\n## Confirmed divergence from real backends\n| Implementation | Name | Value |\n|---|---|---|\n| Coraza (\u003c 3.8.0) | `a\\v` | `\\t\u0027` |\n| Python `http.cookies`, and the Werkzeug/Flask version in the report below | `a` | `\u0027` |\n| PHP `$_COOKIE` | `a` | `\\t\u0027` |\n| Node.js `cookie` package | `a\\v` | `\u0027` |\n\nRFC 6265 itself calls this exact cookie-pair invalid, so there\u0027s no single spec-correct reference \u2014 but Coraza\u0027s boundary handling diverges from 2 of these 3 widely-used backends.\n\nCorrection (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\u0027s `cookie` package. The name divergence therefore applies to PHP and to Python\u0027s `http.cookies`, not to every Werkzeug version.\n\n## Impact\nAn 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 \u2014 a WAF bypass for cookie-carried attacks.\n\n## Affected component\n`internal/cookies.ParseCookies`, consumed via `REQUEST_COOKIES` / `REQUEST_COOKIES_NAMES`.\n\n## Fix\nTrim 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 \u2014 aligning with RFC 6265\u0027s `token`/`cookie-octet` grammar.\n\nThe 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 \u2014 Python\u0027s `http.cookies` rejects the whole pair, PHP strips the CTL from the middle, Node\u0027s `cookie` package keeps it \u2014 so there is no consensus to converge on. It is left as a separate follow-up rather than guessed at here.\n\n### Implementation note\nThe trim is deliberately hand-rolled (a byte-wise scan on `b \u003c= \u0027 \u0027 || b == 0x7f`, which covers octets `0x00\u20130x20` 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:\n\n- **`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 \u00b5s** via `TrimFunc` versus **33.9 \u00b5s** byte-wise \u2014 a ~5\u00d7 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.\n- **`strings.TrimSpace` is not a substitute.** It misses most of the CTL range (`0x00\u20130x08`, `0x0E\u20130x1F`, `0x7F`) and additionally trims `U+0085` and `U+00A0`, whose multi-byte UTF-8 encodings a backend would not strip \u2014 reintroducing the very parser-disagreement class this advisory closes.\n\nThe byte-wise implementation was verified equivalent to a `TrimFunc`-based one across all 16,843,009 byte strings of length 0\u20133, including invalid UTF-8, with zero mismatches. `BenchmarkParseCookies/CTLFlood` guards the hot path against a future regression to a per-byte indirect call.\n\n## Proof of Concept (original report)\n\n\u003e Hi, @fzipi, i hope you doing well, i\u0027m RelunSec from InsiteTech.jp\n\u003e\n\u003e we discovered a parser confusion in cookie parser, i used a simple flask app that print the cookies\n\u003e\n\u003e ```py\n\u003e from flask import Flask, request\n\u003e\n\u003e app = Flask(__name__)\n\u003e\n\u003e @app.route(\u0027/\u0027)\n\u003e def index():\n\u003e     # 1. Print all cookies as a dictionary to your terminal console\n\u003e     print(\"All cookies:\", request.cookies)\n\u003e\n\u003e     return \"Cookies logged in terminal!\"\n\u003e\n\u003e if __name__ == \u0027__main__\u0027:\n\u003e     app.run(debug=True)\n\u003e ```\n\u003e\n\u003e and a go setup\n\u003e\n\u003e ```go\n\u003e package cookies\n\u003e\n\u003e import (\n\u003e \t\"fmt\"\n\u003e \t\"testing\"\n\u003e )\n\u003e\n\u003e func TestParseCookie(t *testing.T) {\n\u003e \tinputs := []string{\n\u003e \"a\\v=\\t\u0027\",\n\u003e \t}\n\u003e\n\u003e \tfmt.Println(\"\\n==========================================\")\n\u003e \tfmt.Println(\"     COOKIE PARSE DIRECT LOCAL RUN       \")\n\u003e \tfmt.Println(\"==========================================\")\n\u003e\n\u003e \tfor _, input := range inputs {\n\u003e \t\t// Calling the exact lowercase function name from the repo\n\u003e \t\tcookies := ParseCookies(input)\n\u003e\n\u003e \t\tfmt.Printf(\"-\u003e Input:   %q\\n\", input)\n\u003e \t\tfmt.Printf(\"   Output:  %q\\n\", cookies)\n\u003e \t\tfmt.Println(\"------------------------------------------\")\n\u003e \t}\n\u003e \tfmt.Println(\"==========================================\")\n\u003e }\n\u003e ```\n\u003e\n\u003e i runned the go program as you can see\n\u003e\n\u003e ```go\n\u003e relunsec@relunsec:~/software/coraza/internal/cookies$ go test\n\u003e\n\u003e ==========================================\n\u003e      COOKIE PARSE DIRECT LOCAL RUN\n\u003e ==========================================\n\u003e -\u003e Input:   \"a\\v=\\t\u0027\"\n\u003e    Output:  map[\"a\\v\":[\"\\t\u0027\"]]\n\u003e ------------------------------------------\n\u003e ==========================================\n\u003e PASS\n\u003e ok  \tgithub.com/corazawaf/coraza/v3/internal/cookies\t0.003s\n\u003e ```\n\u003e\n\u003e and then i sended a curl request to the python flask web app\n\u003e\n\u003e ```bash\n\u003e relunsec@relunsec:~/software/coraza/internal/cookies$ curl 127.0.0.1:5000 -H $\u0027Cookie: a\\v=\\t\u0027\n\u003e Cookies logged in terminal!\n\u003e ```\n\u003e\n\u003e and then i saw in the running flask app terminal\n\u003e\n\u003e ```python\n\u003e All cookies: ImmutableMultiDict([(\u0027a\u0027, \"\u0027\")])\n\u003e ```\n\u003e\n\u003e as you can see python see that as the a cookie and the value of it is `\u0027`, while coraza see it in a different name and a value\n\u003e\n\u003e an attacker can craft a crafted payload that evade cookie inspection and then perfom their attack\n\n### Patched in 3.8.1\n\nThe 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\u0027s `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.\n\n\n### Severity (revised 2026-10-02)\n\n`CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N` (4.0, Medium).\n\nUnchanged vector; precondition stated per the project\u0027s 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\u0027s `$_COOKIE`, Python\u0027s `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\u0027s `cookie` package, Werkzeug for `\\x01`).\n\nImpact metrics follow the convention used across Coraza\u0027s 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.\n\n_AI involvement in this section: Claude Opus 5.5 (Anthropic), via Claude Code, re-derived the CVSS vector from the project\u0027s 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._",
  "id": "GHSA-g4qm-m288-5cp9",
  "modified": "2026-10-08T17:51:31Z",
  "published": "2026-10-08T17:51:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-g4qm-m288-5cp9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/0b940e197ad9983fb3aa36e84f1f81ff985461af"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/commit/9f8521398d1ff023b958fad0b944cac265763866"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/corazawaf/coraza"
    },
    {
      "type": "WEB",
      "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coraza has Cookie Parser Confusion"
}

CVE-2026-107835 (GCVE-0-2026-107835)

Vulnerability from cvelistv5 – Published: 2026-10-09 17:46 – Updated: 2026-10-09 18:24

Title

OWASP Coraza WAF: Cookie Parser Confusion

Summary

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.

Severity

4 (Medium)


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

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-09 18:23 UTC

CWE

CWE-436 - Interpretation Conflict

Assigner

GitHub_M mitre root Scorecard

References

4 references

URL	Tags
https://github.com/corazawaf/coraza/security/advi…	x_refsource_CONFIRM
https://github.com/corazawaf/coraza/commit/0b940e…	x_refsource_MISC
https://github.com/corazawaf/coraza/commit/9f8521…	x_refsource_MISC
https://github.com/corazawaf/coraza/releases/tag/v3.8.1	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
corazawaf	coraza	Affected: < 3.8.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-107835",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-09T18:23:53.273353Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-09T18:24:00.100Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-g4qm-m288-5cp9"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "coraza",
          "vendor": "corazawaf",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 3.8.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s remediation. This issue is fixed in version 3.8.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "HIGH",
            "attackVector": "NETWORK",
            "availabilityImpact": "NONE",
            "baseScore": 4,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "LOW",
            "privilegesRequired": "NONE",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-436",
              "description": "CWE-436: Interpretation Conflict",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-09T17:46:58.890Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/corazawaf/coraza/security/advisories/GHSA-g4qm-m288-5cp9",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/corazawaf/coraza/security/advisories/GHSA-g4qm-m288-5cp9"
        },
        {
          "name": "https://github.com/corazawaf/coraza/commit/0b940e197ad9983fb3aa36e84f1f81ff985461af",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/corazawaf/coraza/commit/0b940e197ad9983fb3aa36e84f1f81ff985461af"
        },
        {
          "name": "https://github.com/corazawaf/coraza/commit/9f8521398d1ff023b958fad0b944cac265763866",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/corazawaf/coraza/commit/9f8521398d1ff023b958fad0b944cac265763866"
        },
        {
          "name": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/corazawaf/coraza/releases/tag/v3.8.1"
        }
      ],
      "source": {
        "advisory": "GHSA-g4qm-m288-5cp9",
        "discovery": "UNKNOWN"
      },
      "title": "OWASP Coraza WAF: Cookie Parser Confusion"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-107835",
    "datePublished": "2026-10-09T17:46:58.890Z",
    "dateReserved": "2026-10-08T22:34:49.289Z",
    "dateUpdated": "2026-10-09T18:24:00.100Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-G4QM-M288-5CP9

Summary

Root cause

Confirmed divergence from real backends

Impact

Affected component

Fix

Implementation note

Proof of Concept (original report)

Patched in 3.8.1

Severity (revised 2026-10-02)

CVE-2026-107835 (GCVE-0-2026-107835)

Tags

Sightings

Nomenclature

Related by attack behaviour