Bouncy Castle Java EUVD-2026-52026

The target application must use Bouncy Castle for Java to process OpenPGP passphrase-based encrypted (symmetric) messages - specifically, it must invoke PBEDataDecryptorFactory or equivalent Bouncy Castle PGP decryption APIs against attacker-supplied ciphertext. The vulnerability triggers during the S2K key derivation phase, which occurs before any message authentication, so no valid passphrase or credential is needed by the attacker. The application does not need any non-default configuration to be vulnerable: the previous default max_memory_exp of 30 (1 TiB) and the absence of any pass or parallelism cap were the library's out-of-the-box behaviour. Exploitation is bounded by: (a) the target application must accept and process PGP-encrypted input from untrusted sources - applications that only decrypt internally-generated PGP traffic are not exposed; and (b) affected versions of the specific Bouncy Castle artifact (bc-java, bc-lts-java, or bcpg-fips) must be on the classpath.

The CVSS 4.0 vector provided (AV:N/AC:L/AT:N/PR:N/UI:N/VA:L) scores 6.9, but the VA:L rating appears to understate the realistic worst-case impact. Prior to the fix, a single crafted OpenPGP packet could request up to 1 TiB of heap allocation, which would crash virtually any JVM in a typical deployment - behaviour consistent with VA:H rather than VA:L. The discrepancy is worth flagging to defenders: the vendor's scoring may reflect an average-case impact assumption (most JVMs would attempt the allocation, OOM, and the operation would fail), rather than an all-or-nothing availability collapse. No EPSS data was provided in the intelligence package, and no CISA KEV entry exists, indicating no confirmed mass exploitation. The absence of any special configuration requirement (default Bouncy Castle behaviour was vulnerable) and the fully network-accessible attack vector with no authentication or user interaction required elevate operational risk for any Java application that processes inbound OpenPGP passphrase-encrypted messages. The vulnerability is straightforwardly reproducible from the public commit diff, which provides full technical disclosure of the flaw, though no weaponized POC has been identified.

An attacker sends a crafted OpenPGP SKESK packet to any network-reachable service that uses Bouncy Castle to decrypt passphrase-protected PGP messages - such as a mail gateway, secure document upload endpoint, or PGP-decrypting microservice. The packet encodes Argon2 S2K cost parameters set to their maximum values (memory exponent 30, passes 255, parallelism 255), which the unpatched library reads from the unauthenticated packet header and unconditionally honours, causing the JVM to attempt allocation of approximately 1 TiB of heap and consume all available CPU lanes, crashing or hanging the service. No commit-level POC beyond the public fix diff exists, but reconstruction from the diff is straightforward.