<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Sat, 10 Oct 2026 01:46:36 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-385204</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-385204</link>
      <description>EUVD-2026-385204</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-385204</guid>
    </item>
    <item>
      <title>fkie_cve-2026-107835</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-107835</link>
      <description>&lt;p&gt;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&amp;#39;s remediation. This issue is fixed in version 3.8.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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&amp;#39;s remediation. This issue is fixed in version 3.8.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-107835</guid>
    </item>
    <item>
      <title>GHSA-g4qm-m288-5cp9 — Coraza has Cookie Parser Confusion</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-g4qm-m288-5cp9</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/corazawaf/coraza/v3&lt;/p&gt;
&lt;p&gt;## Summary
Coraza&amp;#39;s cookie parser (`internal/cookies.ParseCookies`) does not strip ASCII control characters (CTLs) from the edges of a cookie name/value before they&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## 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&amp;#39;` (vertical tab `\v` next to `=`) keeps `\v` in the name (`a\v`), yielding name=`a\v`, value=`\t&amp;#39;`.&lt;/p&gt;
&lt;p&gt;## Confirmed divergence from real backends
| Implementation | Name | Value |
|---|---|---|
| Coraza (&amp;lt; 3.8.0) | `a\v` | `\t&amp;#39;` |
| Python `http.cookies`, and the Werkzeug/Flask version in the report below | `a` | `&amp;#39;` |
| PHP `$_COOKIE` | `a` | `\t&amp;#39;` |
| Node.js `cookie` package | `a\v` | `&amp;#39;` |&lt;/p&gt;
&lt;p&gt;RFC 6265 itself calls this exact cookie-pair invalid, so there&amp;#39;s no single spec-correct reference — but Coraza&amp;#39;s boundary handling diverges from 2 of these 3 widely-used backends.&lt;/p&gt;
&lt;p&gt;Correction (2026-10-02): current Werkzeug (3.1.9, checked during review of the 3.8.1 follow-up) keeps `a\v` as…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/corazawaf/coraza/v3&lt;/p&gt;
&lt;p&gt;## Summary
Coraza&amp;#39;s cookie parser (`internal/cookies.ParseCookies`) does not strip ASCII control characters (CTLs) from the edges of a cookie name/value before they&amp;#39;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.&lt;/p&gt;
&lt;p&gt;## 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&amp;#39;` (vertical tab `\v` next to `=`) keeps `\v` in the name (`a\v`), yielding name=`a\v`, value=`\t&amp;#39;`.&lt;/p&gt;
&lt;p&gt;## Confirmed divergence from real backends
| Implementation | Name | Value |
|---|---|---|
| Coraza (&amp;lt; 3.8.0) | `a\v` | `\t&amp;#39;` |
| Python `http.cookies`, and the Werkzeug/Flask version in the report below | `a` | `&amp;#39;` |
| PHP `$_COOKIE` | `a` | `\t&amp;#39;` |
| Node.js `cookie` package | `a\v` | `&amp;#39;` |&lt;/p&gt;
&lt;p&gt;RFC 6265 itself calls this exact cookie-pair invalid, so there&amp;#39;s no single spec-correct reference — but Coraza&amp;#39;s boundary handling diverges from 2 of these 3 widely-used backends.&lt;/p&gt;
&lt;p&gt;Correction (2026-10-02): current Werkzeug (3.1.9, checked during review of the 3.8.1 follow-up) keeps `a\v` as…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-g4qm-m288-5cp9</guid>
    </item>
  </channel>
</rss>
