There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Netty is a network application framework for development of protocol servers and clients.
    NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version
    4.2.15.Final, 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 'token is valid, ODCID starts at offset 0', causing the server to
    call quiche_accept as if the client'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 'no token handler' semantics would be to return -1 (invalid) so the normal
    un-validated path and amplification limit apply. Version 4.2.15.Final patches the issue. (CVE-2026-44894)

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - Netty 是用於開發通訊協定伺服器和用戶端的網路應用程式架構。
    NoQuicTokenHandler 是應用程式未設定時使用的 tokenHandler。在 4.2.15.Final 版本之前，其 writeToken（） 傳回 false（伺服器不會發送可接受的重試），但 validateToken（） 無條件「傳回 0」。在 QuicheQuicServerCodec.handlePacket（） 中，validateToken（） 的非負傳回會解譯為「token 有效，ODCID 從位移 0 開始」，導致伺服器呼叫 quiche_accept，就好像用戶端的位址已透過重試來回驗證一樣。根據 RFC 9000 8.1，經過驗證的位址會解除 3 次反放大傳送限制。因此，任何攻擊者在具有欺騙性受害者來源 IP 的初始封包中包含任何非空權杖位元組，都會導致 Netty 伺服器將受害者視為已驗證，並向其反映完整大小的交握飛行 （憑證等），而沒有 3 個上限。正確的「無權杖處理常式」語意是傳回 -1 （無效），因此會套用一般未經驗證的路徑和放大限制。Version 4.2.15.Final 修補了此問題。（CVE-2026-44894）

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - Netty 是用于开发协议服务器和客户端的网络应用程序框架。
    NoQuicTokenHandler 是应用程序未设置时使用的 tokenHandler。在低于 4.2.15.Final 的版本中，其 writeToken（） 返回 false（服务器不会发送可接受的重试），但 validateToken（） 会无条件“返回 0”。在 QuicheQuicServerCodec.handlePacket（） 中，validateToken（） 的非负返回值被解释为“token is valid， ODCID starts at offset 0”，从而导致服务器调用 quiche_accept，就像客户端的地址已通过 Retry 往返验证一样。根据 RFC 9000 8.1，经过验证的地址可解除 3 个防放大发送限制。因此，在具有伪造受害者源 IP 的初始数据包中包含任何非空标记字节的任何攻击者，会导致 Netty 服务器将受害者视为经过验证，并反射针对受害者的全尺寸握手飞行（证书等），而无需 3 上限。正确的“无标记处理程序”语义应返回 -1（无效），因此应用正常的未验证路径和放大限制。版本 4.2.15.Final 修补了该问题。（CVE-2026-44894）

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Netty は、プロトコルサーバーおよびクライアントを開発するためのネットワークアプリケーションフレームワークです。
    NoQuicTokenHandlerは、アプリケーションがtokenHandlerを設定していない場合に使用されるtokenHandlerです。バージョン 4.2.15.Final より前では、writeToken() は false を返しますが(サーバーは Retry acceptable を送信しません)、validateToken() は無条件で「0 を返します」。QuicheQuicServerCodec.handlePacket() で、validateToken() からの非負の戻り値が「トークンは有効であり、ODCID はオフセット 0 で開始します」と解釈され、クライアントのアドレスがラウンドトリップ再試行で検証されたかのように、サーバーが quiche_accept を呼び出します。RFC 9000 8.1に従い、検証済みアドレスは 3 アンチアンプ送信制限を解除します。このため、偽装された被害者のソース IP を持つ初期パケットに空でないトークンバイトを含める攻撃者は、Netty サーバーに被害者を検証済みとして扱わせ、3 キャップなしで被害者に対するフルサイズのハンドシェイクフライト(証明書など)を反映させます。正しい「no token handler」セマンティックは-1(無効)を返すため、通常の非検証パスと増幅制限が適用されます。バージョン 4.2.15.Final は、この問題にパッチを適用します。(CVE-2026-44894)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Netty is a network application framework for development of protocol servers and clients.
    NoQuicTokenHandler is the tokenHandler used when the application does not set one. Prior to version     4.2.15.Final, 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 'token is valid, ODCID starts at offset 0', causing the server to     call quiche_accept as if the client'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 'no token handler' semantics would be to return -1 (invalid) so the normal     un-validated path and amplification limit apply. Version 4.2.15.Final patches the issue. (CVE-2026-44894)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
458822	Echo: io.netty:netty-codec-classes-quic: security update to 4.2.15.Final	Tenable Self-Hosted Container Security	Echo Local Security Checks	10/2/2026	10/5/2026	high
458822	Echo: io.netty:netty-codec-classes-quic: security update to 4.2.15.Final	Tenable Cloud Security	Echo Local Security Checks	10/2/2026	10/5/2026	high
320904	Linux Distros 未修補弱點：CVE-2026-44894	Nessus	Misc.	6/12/2026	9/29/2026	high
320904	Linux Distros 未修补的漏洞：CVE-2026-44894	Nessus	Misc.	6/12/2026	9/29/2026	high
320904	Linux Distros のパッチ未適用の脆弱性: CVE-2026-44894	Nessus	Misc.	6/12/2026	9/29/2026	high
320904	Linux Distros Unpatched Vulnerability : CVE-2026-44894	Nessus	Misc.	6/12/2026	9/29/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high