Bouncy Castle Java EUVD-2026-52140

The application must process a PKCS#12 file sourced from an attacker-controlled or untrusted input - for example, user-uploaded keystores, TLS client certificates in PKCS#12 format, or PKCS#12 files fetched from external systems. The vulnerable code path is triggered during MAC verification (engineLoad) or bag decryption (unwrapKey, wrapKey, cryptData, createCipher). The prior mitigation - setting the JVM system property org.bouncycastle.pkcs12.max_it_count - was NOT enforced by default, meaning the vulnerable behavior occurs in all default deployments without that property. Exploitation is limited to availability impact only (no data exfiltration or integrity compromise); the CVSS UI:P metric confirms a passive interaction is required, meaning the attacker cannot trigger the computation without the target application loading the file. Applications that never accept externally supplied PKCS#12 files are not exposed.

The CVSS 4.0 base score of 5.3 (Medium) reflects a realistic, measured assessment: AV:N confirms network delivery, AC:L means no special conditions, PR:N means no authentication required, but UI:P (passive user interaction - i.e., an application must process the malicious PKCS#12 file) and VA:L (limited availability impact) constrain the severity. The practical risk depends on context: applications that accept PKCS#12 uploads from untrusted users or fetch them from external sources face meaningful exposure, because a single crafted file with a maximally large iteration count can peg a CPU thread for an extended period. The impact is bounded - no confidentiality or integrity loss - but repeated submissions could exhaust thread pools in keystore-processing services. No EPSS data was provided in the input, and this CVE is not listed in CISA KEV, indicating no confirmed active exploitation as of analysis. The U:Amber urgency label in the CVSS 4.0 vector signals the reporter considers this a real but not emergency-level risk. The missing EPSS score is noted; risk teams should treat this as a medium-priority patch given the wide Java ecosystem footprint.

An attacker submits a crafted PKCS#12 file - for example, through a certificate upload endpoint or a client TLS mutual-auth flow - where the MAC or bag-decryption KDF parameters encode an extremely large iteration count such as 2^31-1. When the server-side Java application calls KeyStore.load() or equivalent Bouncy Castle APIs on this file, the KDF executes that many hash iterations synchronously, consuming CPU for seconds to minutes per request. No public exploit code has been identified at time of analysis, but the attack is trivially constructible by any party who can craft ASN.1 DER structures.