<?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://vulnerability.circl.lu</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>Fri, 02 Oct 2026 10:51:43 +0000</lastBuildDate>
    <item>
      <title>GHSA-cmm3-54f8-px4j — Netty's Default QUIC token handler accepts any client-supplied token</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-cmm3-54f8-px4j</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-codec-classes-quic&lt;/p&gt;
&lt;p&gt;NoQuicTokenHandler is the tokenHandler used when the application does not set one. Its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as &amp;#39;token is valid, ODCID starts at offset 0&amp;#39;, causing the server to call quiche_accept as if the client&amp;#39;s address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct &amp;#39;no token handler&amp;#39; semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-codec-classes-quic&lt;/p&gt;
&lt;p&gt;NoQuicTokenHandler is the tokenHandler used when the application does not set one. Its writeToken() returns false (server will not send Retry — acceptable), but validateToken() unconditionally `return 0`. In QuicheQuicServerCodec.handlePacket(), a non-negative return from validateToken() is interpreted as &amp;#39;token is valid, ODCID starts at offset 0&amp;#39;, causing the server to call quiche_accept as if the client&amp;#39;s address had been validated by a Retry round-trip. Per RFC 9000 §8.1, a validated address lifts the 3× anti-amplification send limit. Thus any attacker who includes ANY non-empty token bytes in an Initial packet — with a spoofed victim source IP — causes the Netty server to treat the victim as validated and reflect full-size handshake flights (certificates, etc.) toward it without the 3× cap. The correct &amp;#39;no token handler&amp;#39; semantics would be to return -1 (invalid) so the normal un-validated path and amplification limit apply.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-cmm3-54f8-px4j</guid>
    </item>
  </channel>
</rss>
