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

  - 在之前 1.86的 Java 版 Bouncy Castle 中，接受截断的 OpenPGP 加密消息，未报告任何错误，并且在 SEIPD 版本 1 路径上完全未执行完整性检查。RFC 9580 秒 13.7 允许实现在流化时释放完全认证的区块的明文，但要求其在检测到截断时立即指出明确的错误，并在发现可延展的密文时报告可疑的完整性。检测到截断后将其丢弃：当消息被截断但封闭数据包的长度字段保持不变时，BCPGInputStream.PartialInputStream 会针对缺失的密文引发 EOFException，而 BCPGInputStream.nextPacketTag（） 会将 EOFException 报告为消息的干净结尾，因此其上方的数据包流会停止，就像没有数据包一样。在 AEAD 路径（SEIPD 第 2 版和第 5 版 AEAD 数据包）上，当文字数据包在 AEAD 区块边界上结束并且使用者读取的增量小于一个区块时，文字之后对数据包的预向会触发截断区块读取，因此 BcAEADUtil 和 JceAEADUtil 永远不会到达 sec 的尾部消息标签。 5.13.2 验证总明文长度;调用方收到完全认证的区块的明文，文本后面的每个数据包都会被静默丢弃，并且不会引发任何异常，因此已签名和加密的消息被读回为格式良好的未签名消息。该路径上释放的每个字节都保持单独认证，因此这是一个缺少截断错误，而非伪造，并且它是 的 CVE-2026-12817残余，这使得更正外部数据包长度的攻击者能够获得相同的结果。在 SEIPD 版本 1 路径中，后果更为严重：IntegrityProtectedInputStream 验证来自 close（） 的修改检测代码，并且仅在读取返回返回 -1（截断消息从不生成）时关闭自身来达到 close（），因此 PGPEncryptedData.verify（） 从不运行，并且接收方收到未执行任何类型的完整性检查的 CFB 解密明文。根据截断成该形状的消息进行测量，密文的 136 个不同的单字节修改会产生可接受的、被修改的明文，没有一例外。可访问性是消息的属性，而不是攻击者提供的输入的属性：AEAD 形状保留了测量的 131 个连续负载长度中的 3 个，而 SEIPD 版本 1 形状保留了 16 个负载长度中的 1 个负载长度，其截断偏移不随负载长度移动。低级 API 不受影响，调用 PGPEncryptedData.verify（） 的调用程序无论如何直接获取检查，以整个 AEAD 区块或更多增量读取的消费者也是如此。AEAD 解密流现在将此类 EOFException 重新抛出为普通 IOException，nextPacketTag（） 不会清洗该 EOEXCEPTION;OpenPGPMessageInputStream.close（） 现在会关闭其层的受完整性保护的流本身，而不是依赖该流已经看到其数据末端;和 IntegrityProtectedInputStream.close（） 被设为幂等，如 java.io.Closeable 所要求，这取决于这一点，因为流在普通路径上真正关闭了两次，而 PGPEncryptedData.verify（） 消耗了其背后的摘要状态并且无法第二次运行。此问题还仅在 AEAD 路由上影响低于 Java LTS 2.73.13的 Bouncy Castle，因为该版本未随附 SEIPDv1 路由运行的高级 OpenPGP API。它还影响 bcpg-fips 1.0.14 （1.0.X 系列）、 2.0.14.1 （2.0.X 系列）和 2.1.14 （2.1.X 系列）之前的 Bouncy Castle for Java FIPS （BC-FJA），仅在 AEAD 路由上，因为这些版本未搭载高级 OpenPGP API。（CVE-2026-85515）

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

检测

Linux Distros 未修补的漏洞：CVE-2026-85515

high Nessus 插件 ID 362875

版本 1.1