<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-10T05:56:36.617310+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-385204</id>
    <title>EUVD-2026-385204</title>
    <updated>2026-10-10T05:56:36.663089+00:00</updated>
    <content>EUVD-2026-385204</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-385204"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-107835</id>
    <title>fkie_cve-2026-107835</title>
    <updated>2026-10-10T05:56:36.663135+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-107835"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-g4qm-m288-5cp9</id>
    <title>GHSA-g4qm-m288-5cp9 — Coraza has Cookie Parser Confusion</title>
    <updated>2026-10-10T05:56:36.663192+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/corazawaf/coraza/v3</p>
<p>## 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.</p>
<p>## 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'`.</p>
<p>## Confirmed divergence from real backends
| Implementation | Name | Value |
|---|---|---|
| Coraza (&lt; 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` | `'` |</p>
<p>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.</p>
<p>Correction (2026-10-02): current Werkzeug (3.1.9, checked during review of the 3.8.1 follow-up) keeps `a\v` as…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-g4qm-m288-5cp9"/>
  </entry>
</feed>
