Bouncy Castle Java CVE-2026-58060

Exploitation requires that the target application uses a vulnerable version of bc-java (before 1.85), bc-lts-java (before 2.73.12), or bc-fja (before 2.0.2 or 2.1.3), AND that the application parses or verifies HSS/LMS public keys sourced from attacker-controlled input - such as an API accepting PEM/DER-encoded post-quantum keys, a TLS stack validating HSS-based certificates, or any deserialization path that reaches HSSPublicKeyParameters.getInstance(). Applications using Bouncy Castle solely for RSA, ECDSA, AES, or other non-HSS algorithms are not affected. No authentication is required (PR:N per CVSS 4.0 vector), and no non-default server configuration is needed beyond the application having an HSS key-acceptance code path reachable from the network. Exploitation is limited in breadth by HSS/LMS not yet being a mainstream algorithm in production deployments.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, score 8.7) describes a remotely exploitable, low-complexity, unauthenticated denial-of-service with no confidentiality or integrity impact. The U:Amber urgency modifier signals a meaningful but not emergency-tier threat. No EPSS score was provided in the input data, so exploitation probability is unknown. No CISA KEV listing exists, confirming no observed active exploitation at time of analysis. Real-world risk is meaningfully constrained by one factor: the vulnerable code path is in the HSS/LMS post-quantum signature implementation, which - while increasingly adopted - is still far less prevalent in production workloads than RSA or ECDSA paths. Applications using Bouncy Castle exclusively for classical algorithms are unaffected. However, for services that do process external HSS/LMS public keys (e.g., post-quantum TLS experiments, PQC certificate validation, or research-grade PKI), the attack is trivially reproducible from the network without credentials, making it a genuine priority for those deployments.

An attacker submits a network request to a service that accepts HSS/LMS public keys for verification - such as a post-quantum certificate validation endpoint or a PQC-enabled signing API - embedding a crafted key with an L value far exceeding the RFC 8554 maximum of 8. When Bouncy Castle's parser ingests the key without bounds validation, it attempts to allocate memory proportional to the malicious L value, rapidly exhausting the JVM heap. The result is an OutOfMemoryError or severe garbage collection pressure, crashing or hanging the service. No public exploit code has been identified at time of analysis, but constructing the malicious byte sequence requires only basic knowledge of the HSS key encoding format.