Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1359 CNY

100%
Buy Us a Coffee

CVE-2026-71886— OpenPGP certification accepted from a subkey without certification authority

Quick assessment

Affected
Legion of the Bouncy Castle Inc. BC-JAVA
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

在 Bouncy Castle for Java 1.86 之前的版本中，高级 OpenPGP 证书 API 接受了来自发行证书的任何组件密钥（component key）的第三方认证或信任委派，而未要求该组件密钥必须拥有认证权限。 和 方法通过将被验证签名的发行方密钥标识符与第三方证书中的所有密钥进行匹配，从而解析出第三方签名；随后验证该发行组件的绑定链及其签名本身。然而，在签名创建时，系统并未检查该发行组件密钥是否设置了 RFC 9580 第 5.2.3.29 节中定义的“认证密钥标志位”（CERTIFY_OT

CVSS 8.2 · High EPSS 0.17% · P5

Possible ATT&CK Techniques 1 AI

T1556 · Modify Authentication Process

Affected Version Matrix 1

VendorProduct Version RangeStatus
Legion of the Bouncy Castle Inc. BC-JAVA 1.81< 1.86 affected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-71886

Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
OpenPGP certification accepted from a subkey without certification authority
Source: CVE Program / CVE List V5
Vulnerability Description
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.
Source: CVE Program / CVE List V5
CVSS Information
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber
Source: CVE Program / CVE List V5
Vulnerability Type
授权机制不正确
Source: CVE Program / CVE List V5

Affected Products

Vendor Product Affected Versions CPE Subscribe
Legion of the Bouncy Castle Inc. BC-JAVA 1.81 ~ 1.86 -

II. Public POCs for CVE-2026-71886

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-71886

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-71886 (1)

Proof of Concept for CVE-2026-71886 (1)

Same Patch Batch · Legion of the Bouncy Castle Inc. · 2026-10-03 · 12 CVEs total

CVE-2026-71885 9.2 CRITICAL MLS X.509 credential not bound to the LeafNode signature key
CVE-2026-71888 8.7 HIGH CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent
CVE-2026-71889 8.7 HIGH PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate
CVE-2026-71890 8.7 HIGH MLS external commit can remove an arbitrary group member
CVE-2026-85515 8.2 HIGH OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check
CVE-2026-71887 8.2 HIGH OpenPGP data signature accepted from a signing subkey without cross-certification
CVE-2026-71883 8.2 HIGH Native AES packet cipher returns the raw AES key on an alias
CVE-2026-71891 7.1 HIGH BLS12-381 key validation accepts a public key built on a foreign curve
CVE-2026-71892 6.9 MEDIUM CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys
CVE-2026-18040 5.9 MEDIUM HQC leaks private key information through secret-indexed GF(2^8) tables and a secret-depen
CVE-2026-97873 5.3 MEDIUM Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider

IV. Related Vulnerabilities

Same product: BC-JAVA
Same vendor: Legion of the Bouncy Castle Inc.
Same weakness: CWE-863

V. Comments for CVE-2026-71886

No comments yet

Leave a comment