Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-58060

CVE-2026-58060: Bouncy Castle for Java DoS Vulnerability

CVE-2026-58060 is a denial of service flaw in Bouncy Castle for Java caused by unbounded HSS public-key level count during verification. This post covers technical details, affected versions, impact, and mitigation.

Updated:

CVE-2026-58060 Overview

CVE-2026-58060 is a resource-exhaustion vulnerability in Bouncy Castle for Java affecting the Hierarchical Signature System (HSS) public-key parser. The HSS public-key level count (L) is unbounded, allowing an attacker to trigger a huge memory allocation during signature verification. The flaw is tracked under CWE-789: Memory Allocation with Excessive Size Value. It affects Bouncy Castle for Java before 1.85, Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before 2.0.2 (2.0.X) and 2.1.3 (2.1.X).

Critical Impact

Remote attackers can submit crafted HSS public keys to force excessive memory allocation, causing denial of service in any Java application that verifies attacker-controlled HSS/LMS signatures.

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 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series)

Discovery Timeline

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

Technical Details for CVE-2026-58060

Vulnerability Analysis

The vulnerability resides in the HSS (Hierarchical Signature System) public-key parser in Bouncy Castle's post-quantum cryptography module. HSS is a stateful hash-based signature scheme defined in RFC 8554, which builds a hierarchy of Leighton-Micali Signature (LMS) trees. The public key encodes an integer L representing the number of levels in the HSS tree.

Before the patch, HSSPublicKeyParameters.getInstance() read L directly from the input stream without validating it against the RFC 8554 permitted range of 1 to 8. A caller processing an attacker-supplied public key could pass an arbitrarily large L, driving downstream code paths into large allocations during verification. The parser also failed to reject unknown LMS/HSS typecodes and permitted trailing data after a valid signature, expanding the input surface an attacker can abuse.

Root Cause

The root cause is missing bounds validation on a length-like field read from untrusted input. The L value governs subsequent structural parsing and allocation but was accepted without range checks. The signature parser (HSSSignature) similarly did not enforce that the input stream be fully consumed, so appended data was silently ignored rather than rejected.

Attack Vector

An attacker delivers a crafted HSS public key or signature to any application that parses or verifies it through Bouncy Castle. The attack requires no authentication or user interaction and is reachable over the network in any protocol that accepts HSS/LMS material — for example, PKI-based signature verification pipelines, code-signing verifiers, or firmware update validators.

java
// Patch: core/src/main/java/org/bouncycastle/pqc/crypto/lms/HSSPublicKeyParameters.java
// Reject out-of-range HSS level counts on public-key parse.
else if (src instanceof DataInputStream)
{
    int L = ((DataInputStream)src).readInt();
    if (L < 1 || L > 8)    // RFC 8554, Section 6.
    {
        throw new IOException("L value of HSS public key out of range: " + L);
    }
    LMSPublicKeyParameters lmsPublicKey = LMSPublicKeyParameters.getInstance(src);
    return new HSSPublicKeyParameters(L, lmsPublicKey);
}

Source: bc-java commit 311cabb

java
// Patch: core/src/main/java/org/bouncycastle/pqc/crypto/lms/HSSSignature.java
// Disallow trailing data after a parsed HSS signature.
in = new DataInputStream(new ByteArrayInputStream((byte[])src));
HSSSignature hssSignature = getInstance(in, L);
if (in.available() != 0)
{
    throw new IOException("unexpected data found after HSS signature");
}
return hssSignature;

Source: bc-java commit 6c9f30b

Detection Methods for CVE-2026-58060

Indicators of Compromise

  • Java process memory spikes or OutOfMemoryError events tied to HSS/LMS signature verification code paths.
  • Repeated inbound requests carrying HSS public keys or signatures from a single source, especially against PKI, code-signing, or update-validation endpoints.
  • Application logs showing exceptions originating from org.bouncycastle.pqc.crypto.lms.HSSPublicKeyParameters or HSSSignature.

Detection Strategies

  • Inventory Java applications and dependencies for vulnerable Bouncy Castle versions using a Software Composition Analysis (SCA) tool or mvn dependency:tree / gradle dependencies.
  • Instrument verification endpoints to log the parsed L value and reject inputs where L < 1 || L > 8 before invoking Bouncy Castle.
  • Monitor JVM garbage collection and heap metrics for sudden allocation surges correlated with cryptographic operations.

Monitoring Recommendations

  • Alert on unhandled IOException or OutOfMemoryError originating from org.bouncycastle.pqc.crypto.lms packages.
  • Track version drift in the Bouncy Castle bcprov, bcprov-lts, and bc-fips artifacts across build pipelines.
  • Baseline normal request sizes for endpoints that accept signed content and alert on outlier payloads.

How to Mitigate CVE-2026-58060

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 Bouncy Castle for Java FIPS (BC-FJA) to 2.0.2 (2.0.X series) or 2.1.3 (2.1.X series).
  • Restart all Java services after replacing the library to ensure the patched classes are loaded.

Patch Information

The upstream fixes land in two commits on the bc-java repository. Commit 311cabb adds the L range check in HSSPublicKeyParameters and hardens SubjectPublicKeyInfoFactory against unknown LMS/HSS typecodes. Commit 6c9f30b rejects trailing data in HSSSignature. Full advisory details are published on the Bouncy Castle CVE wiki.

Workarounds

  • If upgrade is not immediately possible, validate the HSS L field at the application layer before passing bytes to Bouncy Castle, rejecting values outside 1–8 per RFC 8554.
  • Restrict which network peers can submit HSS/LMS public keys or signatures using authentication, mTLS, or allow-lists.
  • Enforce strict maximum payload sizes on endpoints that accept cryptographic material to bound worst-case allocations.
bash
# Verify installed Bouncy Castle versions across a build
mvn dependency:tree | grep -E "bcprov|bc-fips"

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

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.