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

  - 在之前的 1.86Bouncy Castle for Java 中，驗證 MLS （RFC 9420） 外部提交的提案清單 org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals 會依類型計算提案，並限制已移除的葉索引，但從未確定已移除的葉與加入者有任何關係。RFC 9420 秒 12.2 在外部提交中最多允許一個 Remove 提案，加入者使用該提案刪除自己的舊版本，並要求提交路徑欄位中的 LeafNode 在存在的情況下滿足其在已刪除葉的更新中必須滿足的條件，特別是其憑據提供已刪除參與者可接受的標識符。普通提案清單驗證器的自我刪除規則故意不應用於此路徑，因為重新同步提交合法地刪除了加入者擁有的葉子，但沒有放置任何內容來取代它。因此，任何持有群組公用 GroupInfo 的參與方 （這正是外部加入者所要獲得的） 都可以提交命名任何成員的 LeafIndex 的 Remove，並讓每個成員都套用它，驅逐該成員並接管其在棘輪樹狀結構中的插槽。本應防止此情況的憑證檢查僅存在於 gRPC 互操作工具中，因此不會保護公用 Group.externalJoin 和 Group.handle API 的其他呼叫端。現在只有在已移除分葉的認證與傳送端和接收端的加入者自己的新分葉中的認證相同時，才會接受帶有 Remove 的外部提交。（CVE-2026-71890）

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

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

  - 在适用于 1.86Java 的 Bouncy Castle 之前，验证 MLS （RFC 9420） 外部提交的提案列表 org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals 中，按类型计算提案并限制删除的叶索引，但从未确定删除的叶与加入者有任何关系。RFC 9420 秒 12.2 在外部提交中最多允许一个 Remove 提案，加入者通过该提案删除自己的旧版本，并要求提交路径字段中的 LeafNode 满足它在删除的叶的更新中必须满足的条件，特别是其凭据呈现被删除的参与者可接受的标识符。故意不在此路径上应用普通提案列表验证器的自我删除规则，因为重新同步提交会合法地删除加入者拥有的叶，但没有任何内容来代替它。因此，持有该组的公共 GroupInfo 的任何一方（这正是外部 joiner 应该被赋予的），都可以提交 Remove 命名任何成员的 LeafIndex 并让每个成员应用它，驱逐该成员并接管他们在棘轮树中的槽。本应防止此情况的凭据检查仅存在于 gRPC 互操作工具中，因此不会保护公共 Group.externalJoin 和 Group.handle API 的其他调用程序。现在仅当删除的叶的凭据与加入者自己的新叶中的凭据相同时，才接受带有 Remove 的外部提交（在发送端和接收端）。（CVE-2026-71890）

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

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

  - 1.86 より前の Java 用の Bouncy Castle では、MLS(RFC 9420)外部コミットの提案リスト、org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals の検証では、タイプ別に提案をカウントし、削除されたリーフインデックスがバインドされていますが、削除されたリーフがジョイナーと関係があることは確立されませんでした。RFC 9420 秒 12.2 は、外部コミットで最大 1 つの Remove proposal を許可します。これにより、joiner は自身の古いバージョンを削除し、コミットのパスフィールドの LeafNode が存在する場合に、削除されたリーフの更新で満たす必要がある基準を満たすこと、特にその認証情報が削除された参加者に受け入れられる識別子を提示する必要があります。通常のプロポーザルリストバリデーターの自己削除ルールは、このパスには意図的に適用されません。これは、再同期コミットがジョイナーが所有するリーフを正当に削除するためですが、その代わりに何も置かれなかったためです。グループの公開 GroupInfo を保持している当事者は、外部ジョイナーに与えられるべきものであり、任意のメンバーの LeafIndex に名前を付けて Remove をコミットし、全メンバーにそれを適用させ、そのメンバーを退去させ、ラチェットツリーのスロットを引き継ぐ可能性があります。これを防ぐ必要がある認証情報チェックは、gRPC 相互運用機能ハーネスにのみ存在していたため、パブリック Group.externalJoin と Group.handle API の他の呼び出し元は保護されませんでした。削除を伴う外部コミットは、削除されたリーフの認証情報が、送信側と受信側の両方で、ジョイナー自身の新しいリーフの認証情報と同一である場合のみ受け入れられるようになりました。(CVE-2026-71890)

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

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

  - In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit's proposal list,     org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and     bounded the removed leaf index but never established that the removed leaf had anything to do with the     joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the     joiner removes an old version of themselves, and requires that where one is present the LeafNode in the     commit's path field meet the criteria it would have to meet in an Update for the removed leaf, in     particular that its credential present identifiers acceptable for the removed participant. The ordinary     proposal-list validator's self-remove rule is deliberately not applied on this path, because a resync     commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding     the group's public GroupInfo, which is precisely what an external joiner is meant to be given, could     therefore commit a Remove naming any member's LeafIndex and have every member apply it, evicting that     member and taking over their slot in the ratchet tree. The credential check that should have prevented     this existed only in the gRPC interop harness and so protected no other caller of the public     Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when     the removed leaf's credential is identical to the one in the joiner's own new leaf, on both the sending     and the receiving side. (CVE-2026-71890)

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

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
362873	Linux Distros 未修補弱點：CVE-2026-71890	Nessus	Misc.	2026/10/3	2026/10/5	high
362873	Linux Distros 未修补的漏洞：CVE-2026-71890	Nessus	Misc.	2026/10/3	2026/10/5	high
362873	Linux Distros のパッチ未適用の脆弱性: CVE-2026-71890	Nessus	Misc.	2026/10/3	2026/10/5	high
362873	Linux Distros Unpatched Vulnerability : CVE-2026-71890	Nessus	Misc.	2026/10/3	2026/10/5	high

检测

插件搜索

high

high

high

high