Skip to main content

Bouncy Castle CVE-2026-71886

| EUVDEUVD-2026-92002 HIGH
Incorrect Authorization (CWE-863)
2026-10-03 bcorg GHSA-7hrr-mw36-px4x
8.2
CVSS 4.0 · Vendor: bcorg
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Compromise restricted signing/encryption subkey
  2. Delivery
    Craft third-party User ID certification or introducer delegation
  3. Exploit
    Deliver certificate to app using getCertificationBy()/getDelegationBy()
  4. Execution
    BC omits CERTIFY_OTHER key-flag check
  5. Impact
    Attacker identity attributed to offline primary key

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires all of: (1) a third-party certificate using the offline-primary arrangement where an online subkey is bound only with SIGN_DATA (or a legacy RSA subkey bound only for encryption but algorithmically able to sign) and lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER key flag; (2) the attacker already controls that restricted subkey's private key; (3) a relying application using Bouncy Castle's high-level OpenPGP certificate API and treating OpenPGPCertificate.getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision; (4) an affected version (vendor: 1.81 through 1.85.2; fixed in 1.86). Limiting factors: this is privilege promotion of an ALREADY-compromised subkey - it does not forge the primary key's signature or recover private keys; third-party revocations are deliberately excluded from the fix; applications not using this high-level API, not using OpenPGP, or whose certificates carry no key-flags subpacket (primary keys are always accepted) are not affected by the certification-attribution bypass.

Impact

Signals point to a genuine but conditional trust-integrity flaw rather than a mass-exploitable emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 8.2 (High) and isolates the impact to integrity (VI:H) with no confidentiality or availability effect (VC:N/VA:N) and no subsequent-system impact - consistent with CWE-863 (Incorrect Authorization) over OpenPGP trust decisions. The critical qualifier is AT:P (Attack Requirements: Present): exploitation is not self-contained because it presupposes an attacker who has ALREADY compromised a restricted subkey of a third-party certificate. There is no EPSS score, no CISA KEV listing, and no public exploit in the provided data, so this is best read as a targeted-precondition weakness, not a worm-able internet-facing bug. The CVSS AV:N is defensible because certificates/signatures propagate over the network, but the real gating factor is the offline-primary/online-subkey arrangement plus a compromised subkey - a non-default, security-conscious key topology. Net: a real priority for organizations that both (a) use Bouncy Castle's high-level OpenPGP certificate API for identity/introducer-trust decisions and (b) rely on key-flag separation to contain online subkeys; for everyone else the practical risk is lower than the 8.2 headline suggests. Note the version-scope conflict below (NVD 'before 1.86' vs vendor 'affects 1.81 through 1.85.2') - verify the applicable range with the vendor advisory before deciding patch urgency.

Exploit ScenarioDerived

An organization uses an offline certification primary key with an online signing subkey (bound only SIGN_DATA), and an attacker compromises that online subkey. Using the compromised subkey, the attacker issues a positive User ID certification over an attacker-controlled identity (or a full-trust depth-one introducer delegation); a relying application calling OpenPGPCertificate.getCertificationBy(...).isValid() or getDelegationBy() in affected Bouncy Castle treats the assertion as attributed to the offline primary key. No public exploit code is identified at time of analysis, and the attack neither forges the primary key's signature nor recovers any private key.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.2% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 03, 2026

Bouncy Castle for Java 1.81 through 1.85.2 fails to verify that a third-party OpenPGP signature was issued by a component key actually granted certification authority, so the high-level certificate API will attribute an attacker-made certification or trust delegation to the certificate's offline primary key. An attacker must already hold the private key of a restricted subkey (one bound only with SIGN_DATA, or a legacy RSA encryption subkey whose algorithm can still sign) that lacks the RFC 9580 sec. 5.2.3.29 CERTIFY_OTHER flag; they can then issue a positive User ID certification or a full-trust depth-one direct-key delegation that getCertificationBy()/getDelegationBy() report as a valid chain, and any application treating isValid() as an identity or trusted-introducer decision will accept the forged assertion at the primary key's authority. The flaw is a privilege promotion of an already-compromised subkey rather than a key-recovery attack, no public exploit code has been identified at time of analysis, and vendor fixes are available in 1.86.

RemediationAI

Vendor-released patch: upgrade Bouncy Castle for Java to 1.86 (fixes 1.81 through 1.85.2); the change is the mayHaveIssued() gate added in commit f0d5c8535aeff3f34b7b6b6289ee78c2ea36a3fb and described in the advisory at https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071886. If upgrading immediately is not possible, treat getCertificationBy(...).isValid() and getDelegationBy(...) as unsigned assertions for any third-party issuer whose matching component key is a subkey: re-check the issuing component's key flags yourself and require CERTIFY_OTHER (KeyFlags.CERTIFY_OTHER) at signature creation time, accepting the primary key unconditionally - the trade-off is additional application-layer code and a risk of rejecting legitimate certifications from older certificates that omit the key-flags subpacket, so a flags-absent certificate should be treated as the primary-key case only. Note that certificates accepted through this API are not otherwise weakened, third-party revocations remain honoured by design, and no fix is needed for applications that do not use this high-level identity/introducer path. Rotating or revoking any subkey whose private key may be compromised removes the precondition for exploitation entirely.

Affected VersionsENISA

BC-JAVA 1.81 <1.86

Affected Packages

euvd bc_java fix: 1.86

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

OpenPGP certificates separate a long-lived offline primary key from online subkeys, and RFC 9580 sec. 5.2.3.29 key flags express what each component key is allowed to do - CERTIFY_OTHER ("this key may be used to certify other keys") is distinct from SIGN_DATA. Bouncy Castle's org.bouncycastle.openpgp.api.OpenPGPCertificate resolved a third-party signature by matching the signature's issuer key identifier against every component key of the third-party certificate, then verifying that component's binding chain and the signature bytes, but never consulted the issuing component's key flags at signature creation time. This is CWE-863 (incorrect authorization): the key identifier authenticates which component signed, not whether that component was authorized to sign. The fix introduces a mayHaveIssued(issuerKey, signature) check in the external-signature chain resolution path, accepting a third-party certification or delegation only when the issuer is the primary key (certification-capable by construction, and accepted regardless of key flags because certificates without a key-flags subpacket are common) or a subkey holding CERTIFY_OTHER at creation time. Third-party revocations are deliberately excluded, since declining to honour a revocation keeps trust alive rather than withdrawing it. The affected code is in the bc-java pg module (CPE cpe:2.3:a:legion_of_the_bouncy_castle_inc.:bc-java).

Know when Java gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (bcorg) PRIMARY 8.2 HIGH
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
vuln.today AI 5.9 MEDIUM

No privileges on the verifying application (PR:N), but a pre-compromised non-certification subkey plus the specific offline-primary topology make it AC:H; only identity/trust integrity is affected (I:H), with no confidentiality or availability impact.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE 6.5 MEDIUM
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:H/A:N

Primary rating from Vendor (bcorg).

CVSS VectorVendor: bcorg

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
None
Vulnerable system: Confidentiality
None
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

DescriptionCVE.org

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.

Executive ViewAI

Why It Matters

Bouncy Castle for Java versions 1.81 through 1.85.2 contains a HIGH-severity signature-validation flaw that can cause applications to trust forged OpenPGP identity certifications or trust delegations. Organizations using this library for OpenPGP-based identity, signing, or trusted-introducer workflows could suffer incorrect trust decisions if an attacker already possesses a restricted subkey. Although there is no public exploit identified at time of analysis, affected product owners should prioritize vendor patching and review any identity-trust logic that relies on the affected API.

Business Impact: High
Compensating Controls

Apply vendor patch.

Threat Intelligence Overview

EPSS Score
0.2%
Top 95% exploitable
Prevalence
High
widely deployed Java crypto library; vulnerable high-level OpenPGP API is a narrower surface
Social Media
1
Sightings
Data Quality
6 sources
Confidence: High
EUVD NVD CVE.org EPSS Vulnrichment Vendor CIRCL GitHub

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.2%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
None
System Exposure· derived
Open
Automatable
No
Human Impact
High
Technical Impact
Partial

Priority Score

41
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +41
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

More in Java

View all
CVE-2012-4681 CRITICAL POC
9.8 Aug 28

Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m

CVE-2015-7450 CRITICAL POC
9.8 Jan 02

Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti

CVE-2013-2465 CRITICAL POC
9.8 Jun 18

Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent

CVE-2011-3544 CRITICAL POC
9.8 Oct 19

Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug

CVE-2010-1871 HIGH POC
8.8 Aug 05

JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to

CVE-2012-1723 CRITICAL POC
9.8 Jun 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up

CVE-2013-0422 CRITICAL POC
9.8 Jan 10

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using

CVE-2012-0507 CRITICAL POC
9.8 Jun 07

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up

CVE-2015-4852 CRITICAL POC
9.8 Nov 18

The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers

CVE-2012-5076 CRITICAL POC
9.8 Oct 16

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow

CVE-2017-3066 CRITICAL POC
9.8 Apr 27

Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla

CVE-2012-0391 CRITICAL POC
9.8 Jan 08

The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise Module for Development Tools 15 SP7 Affected
SUSE Linux Enterprise Server 15 SP7 Affected
SUSE Linux Enterprise Server 16.0 Affected
SUSE Linux Enterprise Server 16.1 Affected

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy