CVE-2026-59651: Bouncy Castle Information Disclosure Flaw

CVE-2026-59651 Overview

CVE-2026-59651 affects Bouncy Castle for Java versions prior to 1.85 and Bouncy Castle for Java LTS versions prior to 2.73.12. The default BKS keystore implementation silently accepts legacy version 0/1 stores that derive the HMAC integrity key at only the digest size in bits, producing a 16-bit key when SHA-1 is used. An attacker who can supply or tamper with a keystore file can brute-force this integrity MAC offline. Successful exploitation lets the attacker downgrade the on-disk version field, forge a valid MAC over modified contents, and inject rogue trusted certificates. The weakness is classified under [CWE-326: Inadequate Encryption Strength].

Critical Impact
An attacker who can supply or modify a BKS keystore file can forge integrity MACs offline and inject rogue trusted certificates into applications that load the store.

Affected Products

Bouncy Castle for Java versions prior to 1.85
Bouncy Castle for Java LTS versions prior to 2.73.12
Java applications relying on the default BKS keystore type from Bouncy Castle

Discovery Timeline

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

Technical Details for CVE-2026-59651

Vulnerability Analysis

The Bouncy Castle BKS (Bouncy Castle Keystore) format stores keys and trusted certificates with an HMAC integrity check. In the legacy version 0 and version 1 formats, the HMAC integrity key was derived at the digest size in bits rather than bytes. With SHA-1 as the underlying digest, the resulting key is only 16 bits wide. An attacker with offline access to a keystore file can enumerate the 2^16 candidate keys and locate one that produces a valid MAC over attacker-modified contents. Version 2 of the format, introduced in response to CVE-2018-5382, writes a full-length integrity key. However, the load path in affected releases still honored the unauthenticated version field, so a tampered store presenting itself as version 0 or 1 was silently loaded through the default BKS type.

Root Cause

The root cause is a cryptographic strength deficiency combined with a trust-on-header parsing flaw. The version field within the keystore is unauthenticated, and the loader selects the integrity key derivation based on that field. Legacy derivations produce a MAC key that is brute-forceable within seconds on commodity hardware.

Attack Vector

Exploitation requires the attacker to place a crafted or modified BKS file where the target application will load it, and to persuade the application or user to consume it. Once loaded, forged trusted certificates or altered key material are accepted without alerting the caller.

java

      */
     public static final String GCM_ALLOW_SHORT_TAGS = "org.bouncycastle.gcm.allow_short_tags";
 
+    /**
+     * Opt in to handling legacy version 0/1 BKS keystores. Those stores derive the HMAC integrity
+     * key at only the digest size in bits (a 16-bit key for SHA-1; CVE-2018-5382), which is
+     * brute-forceable offline, so by default the default {@code BKS} keystore type refuses to load
+     * them and only writes the current version 2 format. Set this property to read or create the
+     * weak legacy format (e.g. to migrate an old store); it also gates registration of the separate
+     * {@code BKS-V1} keystore type. Read via {@link #isOverrideSet(String)}.
+     */
+    public static final String BKS_ENABLE_V1 = "org.bouncycastle.bks.enable_v1";
+
     private Properties()
     {
     }

Source: Bouncy Castle patch commit faf5daa

Detection Methods for CVE-2026-59651

Indicators of Compromise

BKS keystore files whose header declares version 0 or version 1 in production applications where version 2 is expected.
Unexpected trusted certificate entries appearing in application keystores after file replacement or backup restore events.
Presence of the org.bouncycastle.bks.enable_v1 system property in Java command lines or configuration files.

Detection Strategies

Inventory Java application dependencies and flag any use of bcprov versions earlier than 1.85 or Bouncy Castle LTS earlier than 2.73.12.
Parse the first bytes of .bks files across managed systems and alert on legacy version markers (0 or 1).
Monitor build pipelines and artifact repositories for downgraded Bouncy Castle library versions.

Monitoring Recommendations

Track file integrity for keystore paths referenced by production JVM processes and alert on unexpected writes.
Log JVM startup arguments and system properties, and alert when org.bouncycastle.bks.enable_v1 is set outside migration windows.
Correlate keystore modifications with subsequent TLS or code-signing trust anchor changes.

How to Mitigate CVE-2026-59651

Immediate Actions Required

Upgrade Bouncy Castle for Java to version 1.85 or later, or Bouncy Castle for Java LTS to 2.73.12 or later.
Re-save any legacy BKS v0/v1 stores as version 2 during a controlled migration and then remove the originals.
Audit systems for the presence of the org.bouncycastle.bks.enable_v1 property and remove it unless a documented migration is active.

Patch Information

The fix ships in Bouncy Castle for Java 1.85 and Bouncy Castle for Java LTS 2.73.12. After patching, the default BKS type refuses to load version 0/1 stores and only writes version 2. Loading a legacy store now throws an IOException unless the caller opts in through the org.bouncycastle.bks.enable_v1 system or security property, which also gates the separate BKS-V1 keystore type. Details are available in the Bouncy Castle CVE-2026-59651 wiki entry and the upstream commit faf5daa.

Workarounds

Restrict filesystem permissions on BKS keystore files so only the JVM service account can read or write them.
Reject inbound keystore uploads whose header indicates legacy version 0 or 1.
Migrate to modern keystore formats such as PKCS12 for new deployments where interoperability allows.

bash

# Confirm patched Bouncy Castle version on the classpath
java -cp bcprov-jdk18on-1.85.jar org.bouncycastle.LICENSE | head -n 2

# Ensure the legacy opt-in is NOT set in production JVMs
unset JAVA_TOOL_OPTIONS
java -Dorg.bouncycastle.bks.enable_v1=false -jar app.jar