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

  - 在之前 1.86的 Java 版 Bouncy Castle 中，高级 OpenPGP 证书 API 接受来自发行证书的任何组件密钥的第三方证书或信任委托，而无需该组件已获得认证机构。OpenPGPCertificate.getCertificationBy（） 和 getDelegationBy（） 通过将第三方签名的发行者密钥标识符与第三方证书的每个密钥进行匹配来解析第三方签名，然后验证发行组件的绑定链和签名本身;未检查发行组件是否携带 RFC 9580 秒。 5.2.3.29 创建签名时的证书密钥标记 （CERTIFY_OTHER）。因此，仅与 SIGN_DATA绑定的子密钥（正是这些密钥标记存在以表达的离线主安排的在线签名子密钥）可因而通过攻击者控制的身份发出肯定的用户 ID 证书，或介绍者信任的完全信任深度一直接密钥委派，且 API 将其作为归因于第三方证书的有效签名链返回。处理 getCertificationBy（...） 的应用程序。isValid（） 或 getDelegationBy（...） 作为身份或 trusted-introducer 决策时，会将攻击者的断言归因于离线主键。这同样适用于仅用于加密的旧版 RSA 子密钥，其算法仍然能够签名。这不会伪造主密钥的签名或恢复任何私钥;它将已经遭到破坏的受限子密钥提升至主密钥的身份颁发机构，破坏密钥标记分离提供的遏制。现在，仅当第三方证书或委派的组件密钥是主密钥，或者创建签名时是保存CERTIFY_OTHER的子密钥时，才会归因于颁发证书，因此继续接受支持证书的子密钥;无论其密钥标志显示什么，都会接受主密钥，因为主密钥通过构造能够进行认证，并且证书根本不携带密钥标志子数据包是常见的。第三方撤销是故意超出规则的范围，因为拒绝兑现信任会保持信任而不是撤回信任。（CVE-2026-71886）

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

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

  - 在之前 1.86的 Bouncy Castle for Java 中，高階 OpenPGP 憑證 API 接受來自發行憑證的任何元件金鑰的第三方認證或信任委派，而不需要該元件已被授予認證權限。OpenPGPCertificate.getCertificationBy（） 和 getDelegationBy（） 透過將其簽發者金鑰識別碼與第三方憑證的每個金鑰進行比對來解析第三方簽章，然後驗證簽發元件的綁定鏈和簽章本身;沒有檢查發出元件是否攜帶 RFC 9580 秒。 5.2.3.29 建立簽章時的認證金鑰旗標 （CERTIFY_OTHER）。因此，僅與 SIGN_DATA 繫結的子金鑰 （這些金鑰旗標所代表的離線主要安排的線上簽署子金鑰） 可能會針對攻擊者控制的身分識別發出正面的使用者識別碼認證，或透過引入者信任的完全信任深度直接金鑰委派，而 API 會將其傳回為歸因於第三方憑證的有效簽章鏈結。處理 getCertificationBy（...） 的應用程式。isValid（） 或 getDelegationBy（...） 作為身分識別或受信任引入器決策，會將攻擊者的判斷提示歸因於離線主金鑰。僅用於加密的舊版 RSA 子金鑰也是如此，其演算法仍然能夠簽署。這不會偽造主金鑰的簽名或恢復任何私密金鑰;它會將已入侵的受限制子金鑰提升為主金鑰的身分識別簽發授權單位，從而破壞金鑰旗標分離所提供的遏制。現在，只有在建立第三方認證或委派的元件金鑰是主金鑰，或是建立簽章時持有CERTIFY_OTHER的子金鑰時，才會歸因於簽發憑證，因此會繼續接受具有認證功能的子金鑰;無論主金鑰旗標所表示，都會接受主金鑰，因為主金鑰可透過建構進行認證，而且完全不攜帶金鑰旗標子封包的憑證很常見。第三方撤銷是故意超出規則的範圍，因為拒絕兌現信任會保持信任而不是撤回信任。（CVE-2026-71886）

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

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

  - 1.86 より前の Java 用の Bouncy Castle では、高レベルの OpenPGP 証明書 API は、コンポーネントに認証権限が付与されている必要なしに、発行証明書のコンポーネントキーからサードパーティの証明書または信頼委任を受け入れていました。OpenPGPCertificate.getCertificationBy() および getDelegationBy() は、発行元キー識別子をサードパーティ証明書のすべてのキーと照合することでサードパーティ署名を解決し、次に発行コンポーネントのバインディングチェーンと署名自体を検証します。発行元コンポーネントが RFC 9580 sec. 5.2.3.29 を伝送しているかどうかは何もチェックしていませんでした署名作成されたときの証明書キーフラグ (CERTIFY_OTHER)。したがって、SIGN_DATA(これらのキーフラグが表現するために存在しているとまったく同じオフラインとプライマリの配置のオンライン署名サブキー)のみにバインドされたサブキーは、攻撃者が制御するIDに対して肯定的なユーザーID証明書、または紹介者信頼の完全信頼深度1直接キー委任を発行する可能性があります。API はそれをサードパーティ証明書に帰属する有効な署名チェーンとして返します。getCertificationBy(...) を扱うアプリケーション。isValid() または getDelegationBy(...) を ID または trusted-introducer の決定として行うと、攻撃者のアサーションはオフラインのプライマリキーに起因すると考えられます。暗号化専用にバインドされたレガシーRSAサブキーの場合も同様ですが、それにもかかわらず、そのアルゴリズムは署名できます。これは、プライマリキーの署名を偽造したり、秘密キーを復元したりしません。これは、すでに侵害された制限付きサブキーをプライマリキーのID発行権限に昇格させ、キーとフラグの分離によってもたらされる封じ込めを破ります。サードパーティの証明書または委任は、それを作成したコンポーネントキーがプライマリキーである場合、または署名が作成されたときにCERTIFY_OTHERを保持するサブキーである場合にのみ、発行証明書に帰属するようになりました。そのため、証明書が可能なサブキーは引き続き受け入れられます。主キーは構築によって認証可能であり、キーフラグサブパケットをまったく運ばない証明書は一般的であるため、主キーはキーフラグが何を言っても受け入れられます。第三者の失効は、それを尊重することを拒否することで、信頼を撤回するのではなく、維持することになるため、意図的にルールの外れです。(CVE-2026-71886)

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, the high-level OpenPGP certificate API accepted a third-party     certification or trust delegation from any component key of the issuing certificate, without requiring     that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and     getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key     of the third-party certificate, then verify the issuing component's binding chain and the signature     itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key     flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online     signing subkey of exactly the offline-primary arrangement those key flags exist to express - could     therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust     depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain     attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or     getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's     assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption,     whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover     any private key; it promotes an already-compromised restricted subkey to the primary key's identity-     issuing authority, defeating the containment the key-flag separation provides. A third-party certification     or delegation is now attributed to the issuing certificate only when the component key that made it is the     primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable     subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary     key is certification-capable by construction and certificates carrying no key flags subpacket at all are     common. Third-party revocations are deliberately outside the rule, since declining to honour one would     keep trust alive rather than withdraw it. (CVE-2026-71886)

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

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

检测

插件搜索

high

high

high

high