Bouncy Castle Java EUVD-2026-52019

Exploitation requires that the target application uses a Bouncy Castle PKCS#8 or PBES2 decryptor (specifically JceOpenSSLPKCS8DecryptorProviderBuilder or JcePKCSPBEInputDecryptorProviderBuilder) to decrypt key material that originates from an attacker-controlled source. Concrete scenarios include: an API endpoint that accepts user-uploaded PEM private keys, a TLS mutual-authentication flow that parses externally provided client certificates, or an SSH/PKI key-management feature that imports key files from user input. The attacker does not need to know the encryption password - only to supply a PKCS#8 container with an inflated KDF cost in the metadata. Exploitation is limited by the requirement that an application code path actually invokes the Bouncy Castle decryptor on untrusted input without pre-validation; applications that only decrypt internally-generated keys (where KDF parameters are trusted) are not exploitable. The CVSS UI:P metric reflects that some triggering action by the application (or its user) is required to initiate decryption.

The CVSS 4.0 base score of 5.3 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L) reflects a moderate, network-reachable DoS with low availability impact. The UI:P metric is significant: passive user interaction is required, meaning the target application must actually attempt to decrypt attacker-supplied key material. This constrains exploitation to scenarios where an application loads external or user-supplied PEM/PKCS#8 private keys - TLS mutual-authentication endpoints that accept client certificates, certificate management APIs, SSH-key-import features, or similar flows. EPSS data is not provided in the input. There is no KEV listing and no POC has been identified, suggesting no confirmed opportunistic exploitation. The real-world priority is moderate: the impact ceiling is a process-level DoS (CPU/memory exhaustion on the thread that triggers decryption) rather than code execution or data exfiltration. However, any service that accepts key material from untrusted users and immediately decrypts it is directly exploitable with a trivially crafted PKCS#8 file, making the attack low-complexity once an applicable endpoint is found. The SUSE tag in the intelligence data suggests downstream Linux distribution tracking, which may broaden the effective patch surface.

An attacker submits a crafted PKCS#8-encoded private key - for example, through a mutual-TLS client-certificate upload endpoint or a key-import API - in which the scrypt cost parameter N is set to an astronomically large value (e.g., 2^30) within the unauthenticated ASN.1 container. When the application calls a Bouncy Castle PBES2 decryptor to decrypt the key, it allocates and processes gigabytes of scrypt working memory before returning an error, causing the handling thread to stall and potentially crashing the JVM with an OutOfMemoryError. No public POC has been identified, but the attack requires only knowledge of PKCS#8 ASN.1 structure and is trivially constructable with standard tooling.