PatchSiren cyber security CVE debrief
CVE-2026-71883 Legion of the Bouncy Castle Inc. CVE debrief
A vulnerability in Bouncy Castle for Java LTS before 2.73.13 allows the release of sensitive data, including AES keys, IVs, and additional authenticated data, under specific conditions. This issue arises from the use of JNI's ReleaseByteArrayElements in mode 0, which can lead to the overwriting of ciphertext with unchanged key bytes when an application encrypts in place over its own key array. The pure-Java packet ciphers and streaming native modes are not affected.
- Vendor
- Legion of the Bouncy Castle Inc.
- Product
- BC-LTS-JAVA
- CVSS
- HIGH 8.2
- CISA KEV
- Not listed in stored evidence
- Original CVE published
- 2026-10-03
- Original CVE updated
- 2026-10-03
- Advisory published
- 2026-10-03
- Advisory updated
- 2026-10-03
Who should care
Defenders responsible for Java applications using Bouncy Castle for Java LTS, especially those using encryption in place over key arrays, should assess their exposure and prioritize verification and potential upgrades.
Why it matters
CVE-2026-71883 is a high-severity vulnerability in Bouncy Castle for Java LTS that can lead to the release of sensitive data, including encryption keys. Defenders should prioritize verifying the use of affected versions and assessing the need for upgrades.
- Potential exposure of sensitive data, including AES keys and IVs.
- Risk of ciphertext being overwritten with unchanged key bytes.
- Need for verification of Bouncy Castle for Java LTS usage and potential upgrades.
- Priority on reviewing encryption practices to prevent in-place encryption over key arrays.
Technical summary
The vulnerability in Bouncy Castle for Java LTS before 2.73.13 involves the one-shot native packet ciphers for AES-CBC, CCM, CFB, CTR, GCM, and GCM-SIV. These ciphers release the caller's key, IV, and additional authenticated data arrays with JNI's ReleaseByteArrayElements in mode 0. This can lead to the overwriting of ciphertext with unchanged key bytes when an application encrypts in place over its own key array.
Defensive priority
Defenders should prioritize verifying the use of Bouncy Castle for Java LTS in their environments, especially where encryption is used in place over key arrays, and assess the need for an upgrade to version 2.73.13 or later.
Recommended defensive actions
- Verify the use of Bouncy Castle for Java LTS in your environment.
- Assess the need for an upgrade to version 2.73.13 or later.
- Review encryption practices, especially where encryption is used in place over key arrays.
- Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up.
- Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance.
- Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed.
- Check relevant monitoring, detection, and logs for exposed assets that need extra review.
Evidence notes
The CVE record and NVD entry provide details on the vulnerability, including its description, CVSS score, and affected versions. However, the corpus does not establish versions, exploitation, impact, or remediation beyond the information provided.
Sources and references
Verified primary and authoritative sources
-
CVE-2026-71883 CVE Program record
Publisher, destination, and source semantics verified
URL: https://www.cve.org/CVERecord?id=CVE-2026-71883
CVE Program - Official CVE Program record with source-provided CVE metadata.
-
CVE-2026-71883 NVD vulnerability detail
Publisher, destination, and source semantics verified
URL: https://nvd.nist.gov/vuln/detail/CVE-2026-71883
NIST National Vulnerability Database - Official NIST NVD detail page and source-specific vulnerability assessment.
Supplemental references
-
Source reference
Unverified legacy reference
URL: https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071883
91579145-5d7b-4cc5-b925-a0262ff19630
Methodology and review provenance
AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.