IT SBIT Services
Schneeberger
DEEN
CVE tracker

Bouncy Castle BC-LTS: Keystream reuse in native CTR packet cipher

CVE-2026-71884High 8.2

← All vulnerabilities

Summary

The native one-shot CTR packet cipher in BC-LTS for Java does not check whether the input length fits the counter space left by IVs of 13 to 15 bytes. When the counter wraps, the keystream repeats within the same packet, yet the call reports full success. An attacker holding only the ciphertext can XOR two segments encrypted under the same keystream and recover the plaintext, without the key. The flaw does not affect the standard bcprov artifact.

Affected

  • BC-LTS for Java from 2.73.4 before 2.73.13
  • Java 8 and later on x86 / x86-64 with the native library in use
  • Not affected: bcprov (standard Bouncy Castle for Java), as it ships no native implementations
  • Not affected: counters of 4 bytes or more, and full 16-byte IVs

Fixed in

  • Upgrade to BC-LTS 2.73.13

Workaround

Unknown.

Exploitation

  • No public exploit or proof of concept found.
  • No evidence of exploitation in the wild; not listed in CISA KEV.
  • CISA SSVC: exploitation none, automatable yes, technical impact partial.

Our recommendation

  • Inventory Java applications and dependencies (SBOM, Maven/Gradle files) for BC-LTS before 2.73.13.
  • Prioritise internet-facing applications and upgrade to BC-LTS 2.73.13.
  • Until upgraded, review code that calls the one-shot CTR packet cipher with 13 to 15 byte IVs and long inputs.
  • Note that CVSS scores differ between sources; use the CNA vector (8.2) for planning.

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 16:46.

Original description (NVD)

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.

NVD references (1)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.

Get in touchRSS feed