Bouncy Castle Java CVE-2026-58061

Exploitation requires both a library-level and an application-level condition to be satisfied simultaneously. Library condition: the application must invoke CCMBlockCipher (or a CCM-family derivative) from the affected Bouncy Castle release for decryption operations. Application-level condition: on an InvalidCipherTextException, the calling code's failure path must expose the contents of the output byte array - through buffer pool reuse (common in Java NIO, Netty, or custom allocation schemes), exception-path logging that captures raw byte data, heap inspection by APM agents or heap-dump tooling, or passing the buffer to another component before explicitly clearing it. There is no requirement for attacker authentication, privileged network position, or non-default configuration of the library itself; any network-reachable CCM decryption endpoint built on the affected library is in scope for the attack. The limiting factor is the application-level exposure: a correctly written Java application that zeros or discards the output buffer in the catch block will not exhibit the oracle behavior, substantially narrowing the exploitable population despite the library being widely deployed.

The CVSS 4.0 base score of 8.7 (AV:N/AC:L/AT:N/PR:N/UI:N/VI:H) is aggressive for a vulnerability whose most severe consequence - the CTR decryption oracle - requires the caller application to expose the output buffer on the authentication-failure path, a condition absent from the vector's AT:N rating. The VI:H signal reflects the integrity violation angle (forged unverified plaintext potentially reaching application logic), but the confidentiality oracle scenario depends on application-level behavior not guaranteed by default. No EPSS data was provided, no CISA KEV listing exists, and no public proof-of-concept has been identified, indicating no observed active exploitation. Real-world risk is materially elevated for Java services that reuse pooled byte buffers (common in high-throughput frameworks such as Netty, Vert.x, or custom NIO allocators), write raw exception context to log aggregation, or fail to zero buffers in catch blocks. For deployments where the caller's exception path never re-exposes the buffer, practical risk is considerably lower than the raw score implies. Bouncy Castle is used broadly across enterprise Java, PKI infrastructure, payment systems, and FIPS-regulated environments, which amplifies the potential blast radius if the application-level condition is met.

An attacker submits a message with a valid CCM ciphertext body but a deliberately corrupted authentication tag to a Java application using the affected Bouncy Castle CCM decryption path. The library CTR-decrypts the ciphertext body into the caller's byte array and then throws InvalidCipherTextException on the tag mismatch, but the decrypted - and unverified - bytes remain in the buffer. If the application reuses that buffer via a pooled allocator or logs the buffer contents on exception, the attacker can observe the recovered bytes and iteratively exploit the path as an unauthenticated CTR decryption oracle across successive crafted requests. No public proof-of-concept exists at time of analysis.