CVE-2026-58061: Bouncy Castle Information Disclosure Flaw

CVE-2026-58061 Overview

CVE-2026-58061 affects Bouncy Castle for Java cryptographic libraries. The Counter with CBC-MAC (CCM) family of authenticated encryption modes writes plaintext to the caller's output buffer before verifying the authentication tag. On a tag mismatch, the library throws InvalidCipherTextException but leaves the unverified plaintext in the caller-supplied buffer. This violates NIST SP 800-38C section 6.2, which requires returning FAIL without revealing the payload. The flaw is tracked under CWE-354: Improper Validation of Integrity Check Value.

Critical Impact
An attacker who can observe the caller's output buffer on the failure path can use forged ciphertexts as an unauthenticated Counter (CTR) mode decryption oracle.

Affected Products

Bouncy Castle for Java before 1.85
Bouncy Castle for Java LTS before 2.73.12
Bouncy Castle for Java FIPS (BC-FJA) before 1.0.2.7 (1.0.X), 2.0.2 (2.0.X), and 2.1.3 (2.1.X)

Discovery Timeline

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

Technical Details for CVE-2026-58061

Vulnerability Analysis

The vulnerability resides in three cipher mode implementations: CCMBlockCipher, KCCMBlockCipher, and KGCMBlockCipher. During decryption, each class runs the CTR-mode keystream over the ciphertext and writes the resulting plaintext directly into the caller's output buffer. Only after this write does the code compute and compare the Message Authentication Code (MAC). If the MAC comparison fails, the code raises an exception but never zeroes the output buffer.

A calling application that reuses pooled buffers, logs partial output, or exposes memory through debugging interfaces can leak the unverified plaintext. Because CTR-mode plaintext equals AES-CTR(key, nonce) XOR ciphertext, an attacker submitting chosen ciphertexts under a known nonce recovers the keystream and thus arbitrary plaintexts. This turns the failure path into a CTR decryption oracle.

Root Cause

The implementations decrypt in place before authentication. NIST SP 800-38C section 6.2 mandates the opposite order: verify the tag, then release plaintext. The Bouncy Castle GCMSIVBlockCipher class already followed the correct pattern, but the CCM, KCCM, and KGCM classes did not.

Attack Vector

Exploitation requires the attacker to submit ciphertexts to a decryption endpoint and observe the output buffer after a tag-check failure. The attack is network-reachable when the vulnerable code path deserializes attacker-supplied ciphertext. No authentication or user interaction is required.

java

// Patch for CCMBlockCipher.java - verify MAC before exposing plaintext
// Source: https://github.com/bcgit/bc-java/commit/cd4a5ab3ad619ff03c7767c1b8b19d5dea2970af

// Decrypt into a private buffer and verify the MAC before writing any plaintext to the
// caller's output: on a tag-check failure the caller's buffer must not be left holding
// unverified CTR plaintext (NIST SP 800-38C 6.2 returns FAIL without revealing P; this
// matches GCMSIVBlockCipher). CCM is non-streaming, so the whole payload is buffered here
// regardless.
byte[] plain = new byte[outputLen];
int plainIndex = 0;

while (inIndex < (inOff + outputLen - blockSize))
{
    ctrCipher.processBlock(in, inIndex, plain, plainIndex);
    plainIndex += blockSize;
    inIndex += blockSize;
}

The equivalent patch for KCCMBlockCipher and KGCMBlockCipher is available in commit 08d67510.

Detection Methods for CVE-2026-58061

Indicators of Compromise

Repeated InvalidCipherTextException exceptions from CCMBlockCipher, KCCMBlockCipher, or KGCMBlockCipher under a stable key and nonce combination.
High-volume decryption failures from a single source targeting an authenticated API endpoint.
Application logs containing partial decrypted payloads following an authentication failure.

Detection Strategies

Inventory application dependencies for bcprov-jdk*, bc-lts-jdk*, and bc-fips artifacts below the fixed versions using Software Composition Analysis (SCA) tools.
Instrument decryption call sites to log tag-check failures with source identifiers to spot oracle-style probing.
Search source repositories for callers of CCMBlockCipher.doFinal, KCCMBlockCipher.doFinal, and KGCMBlockCipher.doFinal that expose the output buffer on the exception path.

Monitoring Recommendations

Alert on abnormal rates of InvalidCipherTextException per client identity or IP address.
Correlate authentication failure spikes with buffer-pool reuse in downstream code paths.
Monitor JVM heap dumps and memory-inspection tooling access for services handling CCM-mode ciphertexts.

How to Mitigate CVE-2026-58061

Immediate Actions Required

Upgrade Bouncy Castle for Java to 1.85 or later.
Upgrade Bouncy Castle for Java LTS to 2.73.12 or later.
Upgrade BC-FJA (FIPS) to 1.0.2.7, 2.0.2, or 2.1.3 depending on the deployed series.
Rotate keys used with CCM, KCCM, or KGCM modes if the failure path was exposed to untrusted callers.

Patch Information

Upstream fixes are available in the Bouncy Castle repository. The CCM fix lands in commit cd4a5ab3, and the KCCM/KGCM fix lands in commit 08d67510. See the Bouncy Castle CVE wiki entry for release mapping.

Workarounds

Zero the caller-supplied output buffer explicitly in every catch (InvalidCipherTextException) block before the buffer can be returned, logged, or pooled.
Switch affected code paths to GCMBlockCipher or GCMSIVBlockCipher, which already verify the tag before releasing plaintext.
Disable buffer pooling for decryption output buffers until the library upgrade is complete.

bash

# Maven dependency upgrade example
mvn versions:use-dep-version -Dincludes=org.bouncycastle:bcprov-jdk18on -DdepVersion=1.85 -DforceVersion=true

# Gradle equivalent
./gradlew dependencies --refresh-dependencies