Bouncy Castle LTS EUVD-2026-91992

Requires all of the following: the application uses the native (not pure-Java) one-shot packet cipher implementations in Bouncy Castle for Java LTS before 2.73.13 for AES-CBC, CCM, CFB, CTR, GCM or GCM-SIV; it performs in-place encryption passing the same Java array as both input and destination buffer, specifically over a secret array such as KeyParameter.getKey(); and it runs on a JVM that returns a copy rather than a pin for JNI GetByteArrayElements. Limiting factors that reduce real-world risk: this in-place-over-the-key pattern is non-default application behavior; bcprov (the standard non-LTS provider) is entirely unaffected as it ships no native code; native streaming modes and all pure-Java packet ciphers are unaffected; and there is no attacker-controlled input or privilege path - the flaw manifests only through the victim application's own usage.

This is a genuine high-severity confidentiality flaw, but one with an unusually narrow and specific trigger that makes it far less broadly exploitable than the 8.2 base score suggests. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:H) scores VC:H because the leaked secret is the raw AES key, and AT:P (Attack Requirements: Present) correctly signals that exploitation is not universal - it depends on a specific coding pattern and JVM behavior. No EPSS score, CISA KEV listing, or POC was provided in the intelligence, so this is not confirmed to be actively exploited and there is no public exploit identified at time of analysis. Importantly, this is not a classic attacker-driven network exploit: there is no remote adversary sending a payload. Rather, a vulnerable application silently self-leaks its own symmetric key into output it believes is ciphertext; the 'attacker' is any party who later receives or can read that output. The CVSS AV:N reflects that the leaked key is typically transmitted over a network, not that an attacker reaches in remotely. Net priority: real and serious for the specific affected deployments (native BC-LTS-Java packet ciphers used for in-place encryption over the key array), but low likelihood of mass exploitation because the triggering pattern is non-default and application-specific.

An application using Bouncy Castle for Java LTS native one-shot packet ciphers (e.g. AES-GCM) encrypts a message in place, reusing the same Java byte array as both input and output - for example encrypting over the array returned by KeyParameter.getKey(). Because the native code releases the read-only key array with JNI mode 0, the unchanged key bytes are written back over the freshly produced ciphertext, and the correct output length is still returned with no error. A passive network observer, or anyone able to read the stored/transmitted output, recovers the raw AES key and can decrypt all data protected by it. No public POC was identified in the provided intelligence.