CVE-2026-59643: Bouncy Castle OpenPGP Signature Flaw

CVE-2026-59643 Overview

CVE-2026-59643 affects the Bouncy Castle for Java cryptographic library before version 1.85 and Bouncy Castle for Java FIPS (BC-FJA) bcpg-fips before 2.0.13. The vulnerability resides in the OpenPGP inline-signature verification path, where policy failures such as weak hash rejections are silently ignored. Signatures that should be rejected under the configured policy are instead treated as valid, allowing an attacker to bypass integrity guarantees on signed messages. The flaw is classified under CWE-347: Improper Verification of Cryptographic Signature and is exploitable over the network without authentication or user interaction.

Critical Impact
Applications relying on Bouncy Castle OpenPGP inline signatures may accept messages signed with policy-violating algorithms as authentic, undermining data integrity for signed communications and files.

Affected Products

Bouncy Castle for Java before 1.85
Bouncy Castle for Java FIPS (BC-FJA) bcpg-fips before 2.0.13
Applications embedding vulnerable versions of the bcpg OpenPGP module

Discovery Timeline

2026-08-03 - CVE-2026-59643 published to NVD
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-59643

Vulnerability Analysis

The vulnerability affects OpenPGPMessageInputStream in the pg/src/main/java/org/bouncycastle/openpgp/api/ package. When processing one-pass inline OpenPGP signatures, the stream handler catches PGPSignatureException thrown by policy checks, such as rejection of weak hash algorithms. The original code path used // continue without propagating or recording the rejection.

Execution then fell through into the standard verification report, marking the signature as successfully verified. The result is that a message signed with a policy-violating algorithm, for example a deprecated hash like SHA-1, is reported to the calling application as if it passed verification. This behavior diverges from the detached-signature and prefixed-signature code paths, which correctly reject the signature.

Root Cause

The root cause is silent exception suppression during signature policy enforcement. The catch (PGPSignatureException e) block for one-pass signatures did not call processor.onException(e) and did not skip the signature before subsequent verification logic executed. This is a signature verification logic flaw rather than a cryptographic primitive weakness.

Attack Vector

An attacker crafts an OpenPGP message using an inline one-pass signature signed with an algorithm the receiving application's policy is configured to reject. When the vulnerable application processes the message, the policy exception is discarded and the message is reported as validly signed. This enables signature forgery in scenarios where downgraded algorithms are computationally attackable, or where the attacker controls a signer key using a disallowed algorithm.

java

                 }
                 catch (PGPSignatureException e)
                 {
-                    // continue
+                    // signature rejected by policy (e.g. weak hash) - skip it, do NOT fall through to
+                    // verify()/report it as correct. Matches the detached- and prefixed-signature paths.
+                    processor.onException(e);
+                    continue;
                 }
 
                 if (!dataSignature.createdInBounds(processor.getVerifyNotBefore(), processor.getVerifyNotAfter()))

Source: Bouncy Castle bc-java commit d3f8cc4 — the patch invokes processor.onException(e) and issues a continue, aligning one-pass signature handling with the detached and prefixed paths.

Detection Methods for CVE-2026-59643

Indicators of Compromise

Inbound OpenPGP messages using deprecated hash algorithms (for example SHA-1 or MD5) that are nonetheless processed as valid by application logs.
Application audit trails showing successful signature verifications with no accompanying policy warnings, despite policy configuration rejecting weak algorithms.
Bouncy Castle bcpg JAR versions below 1.85 or bcpg-fips below 2.0.13 present on production hosts.

Detection Strategies

Inventory Java application dependencies using Software Composition Analysis (SCA) tools to identify vulnerable bcpg and bcpg-fips versions.
Add unit or integration tests that submit an OpenPGP message signed with a policy-rejected algorithm and assert that verification fails.
Compare signature verification outcomes across detached, prefixed, and inline paths; inconsistencies suggest the vulnerable code path is in use.

Monitoring Recommendations

Log all OpenPGP signature verification outcomes with the signing hash algorithm and key algorithm identifiers.
Alert when signatures reported as valid use algorithms outside the organization's approved cryptographic policy.
Track application build manifests (Maven, Gradle) for org.bouncycastle:bcpg-jdk18on and bcpg-fips versions in CI pipelines.

How to Mitigate CVE-2026-59643

Immediate Actions Required

Upgrade Bouncy Castle for Java to version 1.85 or later.
Upgrade Bouncy Castle for Java FIPS bcpg-fips to version 2.0.13 or later.
Audit any application using OpenPGPMessageInputStream for inline-signature verification and treat prior verification results as untrusted.
Re-verify recently processed OpenPGP messages using the patched library where signature validity is security-critical.

Patch Information

The fix is committed in Bouncy Castle bc-java commit d3f8cc4. It modifies the catch (PGPSignatureException e) handler in OpenPGPMessageInputStream.java to call processor.onException(e) and continue, preventing policy-rejected signatures from being reported as verified. Additional details are available in the Bouncy Castle CVE-2026-59643 wiki.

Workarounds

Where upgrading is not immediately possible, use detached or prefixed OpenPGP signatures rather than inline one-pass signatures, since those code paths correctly enforce policy.
Add application-layer checks that inspect the signature hash algorithm after verification and reject deprecated algorithms explicitly.
Restrict acceptable signer keys and algorithms at the trust store level to reduce reliance on library-level policy enforcement.

bash

# Maven dependency update example
# pom.xml
# <dependency>
#   <groupId>org.bouncycastle</groupId>
#   <artifactId>bcpg-jdk18on</artifactId>
#   <version>1.85</version>
# </dependency>

mvn versions:use-dep-version -Dincludes=org.bouncycastle:bcpg-jdk18on -DdepVersion=1.85 -DforceVersion=true
mvn dependency:tree | grep bcpg