Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCapture ciphertext from vulnerable native CTR packet
-
ExploitIdentify short-IV counter wrap and keystream reuse
-
ExecutionCombine repeated-keystream segments (two-time pad)
-
ImpactRecover plaintext without the key
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A04:2025 - Cryptographic Failures
ASVS 5.0
V11 - Cryptography Nonce/key pair uniqueness
|
| Exploitation Conditions | Exploitation requires that the application use the BC LTS Java native one-shot CTR packet cipher path specifically, configured with an IV of 13, 14, or 15 bytes (leaving only a 1-, 2-, or 3-byte block counter addressing 256 / 65536 / 16777216 blocks), AND that it pass a single input longer than that counter space so the counter wraps and the keystream repeats within the packet. The attacker must additionally obtain the produced ciphertext to mount the two-time-pad recovery. Exploitation is NOT possible against: full 16-byte IVs (counter range is the caller's responsibility), counters of 4 bytes or more (cannot be exhausted by a Java int length), the streaming implementation (validates at init and during processing), the portable AESCTRPacketCipher (rejects with 'Counter in CTR/SIC mode out of range'), or the bcprov distribution (ships no native code). These limiting factors mean only non-default short-IV native deployments are realistically affected. |
| Impact | The input CVSS 4.0 base score is 8.2 (High) with vector AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N - a pure confidentiality impact (VC:H) with no integrity or availability effect, consistent with CWE-323 (nonce/keystream reuse). The AT:P flag is the critical qualifier: exploitation carries a specific attack requirement, namely that the victim application invokes the native one-shot CTR packet cipher with a 13-15 byte IV AND supplies an input longer than the shrunken counter can address. No EPSS probability, CISA KEV listing, or public POC is present in the supplied data, so there is no public exploit identified at time of analysis and no evidence of active exploitation. These signals point to a genuine cryptographic flaw whose real-world risk is substantially lower than the 8.2 headline for the typical deployment, because it is gated by a non-default usage pattern (short IV + over-long single-shot input over the native path) rather than being broadly reachable; the description itself notes the streaming path, the portable AESCTRPacketCipher, full 16-byte IVs, and the entire bcprov distribution are all unaffected. Treat as a high-priority fix for environments confirmed to use the BC LTS native one-shot CTR path with short IVs, but as lower practical urgency elsewhere. Note: no EPSS was provided, so exploitation-probability cannot be weighed against the CVSS score. |
| Exploit ScenarioDerived | An application uses Bouncy Castle for Java LTS (native one-shot CTR packet cipher) with a 13-byte IV and encrypts a packet larger than the ~256-block counter space; the 1-byte counter wraps and the keystream repeats within the same packet, yet the call returns success and the full length. An attacker who obtains only the resulting ciphertext XORs the two segments encrypted under the identical keystream (a classic two-time pad) and recovers both plaintexts without ever possessing the key. No public POC was identified in the supplied data. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 09, 2026
Keystream reuse in the native one-shot CTR packet cipher of Bouncy Castle for Java LTS before 2.73.13 allows remote attackers to recover plaintext from ciphertext alone, without knowledge of the key. Exploitation is unauthenticated but conditional: the application must use the native one-shot CTR path with a 13-, 14-, or 15-byte IV, leaving only a 1-, 2-, or 3-byte block counter (256, 65,536, or 16,777,216 blocks), and must pass a single input longer than that counter space so the counter wraps and the keystream restarts within the packet. The call returns the full input length with no exception, so the caller receives no signal that some bytes were transformed under a repeated keystream; the resulting two-time-pad condition permits plaintext recovery. No public exploit code has been identified at time of analysis, and the non-default short-IV native deployment requirement keeps realistic exposure narrow, which is why this is assessed as AC:H rather than trivially exploitable.
RemediationAI
Vendor-released patch: upgrade Bouncy Castle for Java LTS (bc-lts-java) to 2.73.13 or later, which adds an IV-derived counter-range preflight in the native one-shot CTR packet cipher and rejects an over-long request before any output is written, so the operation is failure-atomic; details are in the vendor advisory at https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071884. If upgrading is not immediately possible, the most effective compensating control is to stop using the native one-shot CTR packet cipher and switch to the portable AESCTRPacketCipher or the streaming implementation, both of which validate the counter and reject unsafe requests; the trade-off is a performance loss from leaving the native path. Alternatively, ensure the CTR IV leaves at least four counter bytes (i.e., avoid 13-, 14-, and 15-byte IVs), which cannot be exhausted by a Java int length; note that this depends on application configuration and does not protect callers who cannot control IV length, and that using a full 16-byte IV only removes the library-side check because the counter range then becomes the caller's own responsibility. Because the only observable symptom is silent keystream reuse rather than an error, audit existing logs and ciphertext for any prior use of the native one-shot path with short IVs and over-long inputs, and treat ciphertext produced under those conditions as potentially recoverable by anyone who obtains it. The bcprov distribution requires no action, as it ships no native implementations and is unaffected.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
CTR mode turns a block cipher into a stream cipher by encrypting successive counter blocks; the IV and the block counter share a single 16-byte AES block, so an IV shorter than 16 bytes consumes part of the counterspace. With a 13-, 14-, or 15-byte IV, only 1, 2, or 3 bytes remain for the counter, addressing 256, 65,536, or 16,777,216 blocks respectively. This is an instance of CWE-323 (reuse of a nonce/key pair in encryption): when the native one-shot CTR packet cipher accepted an input longer than the residual counter range, the counter wrapped to its starting value and the keystream was regenerated from the beginning of the same packet, encrypting two segments of the message under an identical keystream. The affected code path is the native (JNI) one-shot variant of the packet cipher in the bc-lts-java distribution, which had a single entry point and performed no counter-range preflight. By contrast, the streaming implementation validates the counter at init and again during processing, and the portable AESCTRPacketCipher explicitly rejects the request with 'Counter in CTR/SIC mode out of range.' The upstream fix preflights the IV-derived counter range in the native one-shot path and rejects an over-long request before any output is written, making the operation failure-atomic and preventing a success return for bytes that were not correctly transformed. Deployments with a full 16-byte IV are unaffected (the counter range is then the caller's responsibility), as are counters of four bytes or more, which cannot be exhausted by a Java int length, and the bcprov artifact, which ships no native implementations. The impact is purely confidentiality (VC:H with no VI or VA), matching the CWE-323 keystream-reuse class.
Know when Java gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/U:Amber
AC:H because exploitation depends on a non-default short-IV native CTR usage and over-long input; PR:N/UI:N as recovering plaintext needs only captured ciphertext; C:H with I/A:N as impact is confidentiality only.
Primary rating from Vendor (bcorg).
CVSS VectorVendor: bcorg
Lifecycle Timeline
2DescriptionCVE.org
In Bouncy Castle for Java LTS before 2.73.13, the native one-shot CTR packet cipher did not check that the requested input length fitted the counter space the IV left. In CTR mode the IV and the block counter share one 16-byte block, so an IV of 13 to 15 bytes leaves a counter of only 1 to 3 bytes, addressing 256, 65536 or 16777216 blocks respectively. Given a longer input the counter wrapped and the keystream repeated from the start of the same packet, and the call then returned the full input length as though every byte had been correctly transformed. Two segments of the message were therefore encrypted under the same keystream, so their plaintexts can be recovered from the ciphertext alone, without the key, while the caller saw neither an exception nor a short length to indicate it. The streaming implementation validates at init and again while processing, and the portable AESCTRPacketCipher rejects such a request with "Counter in CTR/SIC mode out of range.", but the native one-shot path has a single entry point and performed no counter-range validation there. It now preflights the IV-derived counter range and rejects an over-long request before any output is written, so the operation is failure-atomic and never reports success for bytes it did not correctly transform. A counter of four bytes or more cannot be exhausted by a Java int length and is unaffected, as is a full 16-byte IV, where the counter range is the caller's responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.
Articles & Coverage 1
Executive ViewAI
Bouncy Castle for Java LTS versions prior to 2.73.13 contain a keystream reuse flaw in the native one-shot CTR packet cipher that can permit remote plaintext recovery without key knowledge. The vulnerability only manifests under non-default conditions-applications must use a 13-, 14-, or 15-byte IV and process a single input larger than the available block counter-so realistic exposure is narrow. Organizations relying on this cryptographic library for sensitive data protection should prioritize identifying affected deployments and applying interim mitigations while no vendor patch is available.
No vendor-released patch identified at time of analysis. Interim mitigations: enforce 16-byte IVs for CTR mode, avoid single inputs that exceed the block counter space for short IVs (13 bytes: 256 blocks; 14 bytes: 65,536 blocks; 15 bytes: 16,777,216 blocks), or replace the native one-shot CTR path with a non-vulnerable cipher implementation or library. Monitor vendor advisory for patch availability.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
EUVD-2026-95586
GHSA-qgfp-x9w9-pwj2
NVD
CVE.org
EPSS
VulDB
Exploit-DB