CVE-2026-71884 (GCVE-0-2026-71884)
Vulnerability from cvelistv5
Published
2026-10-09 09:30
Modified
2026-10-15 16:03
Severity ?
VLAI Severity ?
EPSS score ?
CWE
- CWE-323 - Reusing a Nonce, Key Pair in Encryption
Summary
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.
References
| URL | Tags | |
|---|---|---|
Impacted products
| Vendor | Product | Version | ||
|---|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Version: 2.73.4 |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71884",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T16:02:49.491863Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T16:03:50.989Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-lts8on",
"platforms": [
"x86",
"x86-64"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"ctr_pc.c"
],
"repo": "https://github.com/bcgit/bc-lts-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.73.13",
"status": "affected",
"version": "2.73.4",
"versionType": "maven"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn 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\u0027s responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.\u003c/p\u003e"
}
],
"value": "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\u0027s responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 8.2,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "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",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-323",
"description": "CWE-323 Reusing a Nonce, Key Pair in Encryption",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-09T09:30:50.624Z",
"orgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"shortName": "bcorg"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071884"
}
],
"source": {
"discovery": "INTERNAL"
},
"title": "Packet CTR reports a full success length after the counter is exhausted",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71884",
"datePublished": "2026-10-09T09:30:50.624Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-15T16:03:50.989Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-71884\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"yes\"}, {\"Technical Impact\": \"partial\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-15T16:02:49.491863Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-15T16:03:45.469Z\"}}], \"cna\": {\"title\": \"Packet CTR reports a full success length after the counter is exhausted\", \"source\": {\"discovery\": \"INTERNAL\"}, \"metrics\": [{\"format\": \"CVSS\", \"cvssV4_0\": {\"Safety\": \"NOT_DEFINED\", \"version\": \"4.0\", \"Recovery\": \"NOT_DEFINED\", \"baseScore\": 8.2, \"Automatable\": \"NOT_DEFINED\", \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"valueDensity\": \"NOT_DEFINED\", \"vectorString\": \"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\", \"exploitMaturity\": \"NOT_DEFINED\", \"providerUrgency\": \"AMBER\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"attackRequirements\": \"PRESENT\", \"privilegesRequired\": \"NONE\", \"subIntegrityImpact\": \"NONE\", \"vulnIntegrityImpact\": \"NONE\", \"subAvailabilityImpact\": \"NONE\", \"vulnAvailabilityImpact\": \"NONE\", \"subConfidentialityImpact\": \"NONE\", \"vulnConfidentialityImpact\": \"HIGH\", \"vulnerabilityResponseEffort\": \"NOT_DEFINED\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"GENERAL\"}]}], \"affected\": [{\"repo\": \"https://github.com/bcgit/bc-lts-java\", \"vendor\": \"Legion of the Bouncy Castle Inc.\", \"modules\": [\"core\"], \"product\": \"BC-LTS-JAVA\", \"versions\": [{\"status\": \"affected\", \"version\": \"2.73.4\", \"lessThan\": \"2.73.13\", \"versionType\": \"maven\"}], \"platforms\": [\"x86\", \"x86-64\"], \"packageURL\": \"pkg:maven/org.bouncycastle/bcprov-lts8on\", \"packageName\": \"bcprov-lts8on\", \"programFiles\": [\"ctr_pc.c\"], \"collectionURL\": \"https://www.bouncycastle.org/download/bouncy-castle-java-lts/\", \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071884\", \"tags\": [\"vendor-advisory\"]}], \"x_generator\": {\"engine\": \"bc release-notes template\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"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\u0027s responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.\", \"supportingMedia\": [{\"type\": \"text/html\", \"value\": \"\u003cp\u003eIn 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\u0027s responsibility. Bouncy Castle for Java (bcprov) is not affected, as it ships no native implementations.\u003c/p\u003e\", \"base64\": false}]}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-323\", \"description\": \"CWE-323 Reusing a Nonce, Key Pair in Encryption\"}]}], \"providerMetadata\": {\"orgId\": \"91579145-5d7b-4cc5-b925-a0262ff19630\", \"shortName\": \"bcorg\", \"dateUpdated\": \"2026-10-09T09:30:50.624Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2026-71884\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-15T16:03:50.989Z\", \"dateReserved\": \"2026-08-08T00:06:06.982Z\", \"assignerOrgId\": \"91579145-5d7b-4cc5-b925-a0262ff19630\", \"datePublished\": \"2026-10-09T09:30:50.624Z\", \"assignerShortName\": \"bcorg\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…