Description
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.
Published: 2026-10-09
Score: 8.2 High
EPSS: < 1% Very Low
KEV: No
Impact: Plaintext Recovery
Action: Patch Now
AI Analysis

Impact

The vulnerability exists in the native one‑shot CTR packet cipher of Bouncy Castle for Java LTS versions before 2.73.13. The implementation fails to verify that the requested input length fits within the counter space left by the initialization vector (IV). When the IV segment allows only a few bytes of counter space, a longer input causes the counter to wrap. The library then repeats the keystream, returning the full input length as if each byte had been properly encrypted. This flaw allows an attacker to reconstruct plaintexts from ciphertext alone without knowledge of the secret key, representing a high‑impact cryptographic key‑reuse exploit (CWE‑323).

Affected Systems

Legion of the Bouncy Castle Inc. – BC‑LTS‑JAVA. Versions prior to 2.73.13 are impacted. The pure Java provider (bcprov) is not affected because it does not ship native code.

Risk and Exploitability

The CVSS score of 8.2 indicates high severity, and the vulnerability is not yet listed in CISA’s KEV catalog. With no EPSS information available, the exploitation probability is unknown, though the vector likely involves supplying a crafted, long ciphertext to a vulnerable application that uses the native CTR mode. Because the flaw releases the same keystream twice, an attacker with access to both ciphertext segments can recover the underlying plaintexts. The issue has no runtime exception or length truncation, so detection is difficult; however, patched versions perform a pre‑flight counter‑range check that rejects over‑long requests, making the operation failure‑atomic.

Generated by OpenCVE AI on October 9, 2026 at 10:36 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Upgrade the Bouncy Castle library to version 2.73.13 or later, which implements a counter‑range check and rejects excessive input lengths before producing output.
  • If upgrading is not immediately possible, disable or remove use of the native one‑shot CTR packet cipher or replace it with a pure Java implementation that includes proper counter validation.
  • Validate every encryption request against the IV length by ensuring the input size does not exceed the counter space (e.g., restrict IVs to a full 16 bytes or otherwise enforce that the plaintext length is less than 2^ (8 * counter‑bytes).

Generated by OpenCVE AI on October 9, 2026 at 10:36 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 15 Oct 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Tue, 13 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

cvssV3_1

{'score': 5.9, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N'}

threat_severity

Moderate


Fri, 09 Oct 2026 11:00:00 +0000

Type Values Removed Values Added
First Time appeared Legion Of The Bouncy Castle Inc.
Legion Of The Bouncy Castle Inc. bc-lts-java
Vendors & Products Legion Of The Bouncy Castle Inc.
Legion Of The Bouncy Castle Inc. bc-lts-java

Fri, 09 Oct 2026 09:45:00 +0000

Type Values Removed Values Added
Description 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.
Title Packet CTR reports a full success length after the counter is exhausted
Weaknesses CWE-323
References
Metrics cvssV4_0

{'score': 8.2, 'vector': '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'}


Subscriptions

Legion Of The Bouncy Castle Inc. Bc-lts-java
cve-icon MITRE

Status: PUBLISHED

Assigner: bcorg

Published:

Updated: 2026-10-15T16:03:50.989Z

Reserved: 2026-08-08T00:06:06.982Z

Link: CVE-2026-71884

cve-icon Vulnrichment

Updated: 2026-10-15T16:03:45.469Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-09T10:16:38.260

Modified: 2026-10-15T17:17:27.127

Link: CVE-2026-71884

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-09T09:30:50Z

Links: CVE-2026-71884 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-09T10:45:05Z

Weaknesses
  • CWE-323

    Reusing a Nonce, Key Pair in Encryption