Search
Find a vulnerability
Search criteria
ⓘ
Use this form to refine search results.
Full-text search supports keyword queries with ranking and filtering.
You can combine vendor, product, and sources to narrow results.
Enable “Apply ordering” to sort by date instead of relevance.
104 vulnerabilities found for BC-JAVA by Legion of the Bouncy Castle Inc.
CVE-2026-97873 (GCVE-0-2026-97873)
Vulnerability from nvd – Published: 2026-10-03 08:04 – Updated: 2026-10-05 17:00
VLAI
EPSS
VEX
Title
Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider
Summary
In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 17:00 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/766a31026… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
Date Public
2026-10-03 08:14
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-97873",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T17:00:30.479924Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T17:00:58.750Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PBE",
"PBEPKCS12",
"PBEPBKDF1",
"PBESecretKeyFactory",
"BaseBlockCipher",
"BaseStreamCipher",
"BaseWrapCipher",
"BaseMac"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PBE",
"PBEPKCS12",
"PBEPBKDF1",
"PBESecretKeyFactory",
"BaseBlockCipher",
"BaseStreamCipher",
"BaseWrapCipher",
"BaseMac"
],
"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.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Arpan Sharma"
}
],
"datePublic": "2026-10-03T08:14:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the raw JCA provider\u0027s legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider\u0027s AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the raw JCA provider\u0027s legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider\u0027s AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:53:44.034Z",
"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%9097873"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/766a31026ac24ed3c6cad8662058ba450c338da1"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-97873",
"datePublished": "2026-10-03T08:04:43.322Z",
"dateReserved": "2026-09-25T08:41:02.479Z",
"dateUpdated": "2026-10-05T17:00:58.750Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85515 (GCVE-0-2026-85515)
Vulnerability from nvd – Published: 2026-10-03 08:05 – Updated: 2026-10-03 08:05
VLAI
EPSS
VEX
Title
OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check
Summary
In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.
Severity
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/ab7a235d1… | patch |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.74 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.7 , < 1.0.14
(maven)
Affected: 2.0.7 , < 2.0.14.1 (maven) Affected: 2.1.0 , < 2.1.14 (maven) |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"BcAEADUtil",
"JceAEADUtil",
"IntegrityProtectedInputStream",
"OpenPGPMessageInputStream"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.74",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"BcAEADUtil",
"JceAEADUtil"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpg-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.14",
"status": "affected",
"version": "1.0.7",
"versionType": "maven"
},
{
"lessThan": "2.0.14.1",
"status": "affected",
"version": "2.0.7",
"versionType": "maven"
},
{
"lessThan": "2.1.14",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Arpan Sharma"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer\u0027s integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer\u0027s integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API."
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-354",
"description": "CWE-354 Improper Validation of Integrity Check Value",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-345",
"description": "CWE-345 Insufficient Verification of Data Authenticity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:05:16.553Z",
"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%9085515"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/ab7a235d1c20e3da28ce77167a96b5c14025efa7"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-85515",
"datePublished": "2026-10-03T08:05:16.553Z",
"dateReserved": "2026-09-04T05:38:18.070Z",
"dateUpdated": "2026-10-03T08:05:16.553Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71892 (GCVE-0-2026-71892)
Vulnerability from nvd – Published: 2026-10-03 08:30 – Updated: 2026-10-05 16:58
VLAI
EPSS
VEX
Title
CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys
Summary
In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier's parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier's algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:58 UTC
CWE
- CWE-697 - Incorrect Comparison
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/be0a7d925… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.78 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
2.0.7 , < 2.0.13
(maven)
Affected: 2.1.0 , < 2.1.13 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71892",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:58:15.636238Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:58:40.411Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"JceKeyTransRecipient"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.78",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.7",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier\u0027s parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier\u0027s algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier\u0027s parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier\u0027s algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"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:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-697",
"description": "CWE-697 Incorrect Comparison",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:30:26.982Z",
"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%9071892"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/be0a7d925c818ef2f338bcec55178b9b6336dfc3"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71892",
"datePublished": "2026-10-03T08:30:26.982Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T16:58:40.411Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71891 (GCVE-0-2026-71891)
Vulnerability from nvd – Published: 2026-10-03 08:56 – Updated: 2026-10-05 15:59
VLAI
EPSS
VEX
Title
BLS12-381 key validation accepts a public key built on a foreign curve
Summary
In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381's field characteristic. The prime-order subgroup check trusts a point's own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve's cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC's pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point's curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 15:59 UTC
CWE
- CWE-347 - Improper Verification of Cryptographic Signature
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/c16bcfdce… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.85 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71891",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T15:59:14.270246Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T15:59:26.486Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"BLS12_381BasicScheme",
"BLS12_381G1"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.85",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Bhargava Shastry"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381\u0027s field characteristic. The prime-order subgroup check trusts a point\u0027s own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve\u0027s cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC\u0027s pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point\u0027s curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381\u0027s field characteristic. The prime-order subgroup check trusts a point\u0027s own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve\u0027s cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC\u0027s pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point\u0027s curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-347",
"description": "CWE-347 Improper Verification of Cryptographic Signature",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:56:01.050Z",
"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%9071891"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/c16bcfdce1f96230261b7c2c8c1e044bfc9d1deb"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "BLS12-381 key validation accepts a public key built on a foreign curve",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71891",
"datePublished": "2026-10-03T08:56:01.050Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T15:59:26.486Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71890 (GCVE-0-2026-71890)
Vulnerability from nvd – Published: 2026-10-03 08:57 – Updated: 2026-10-05 15:58
VLAI
EPSS
VEX
Title
MLS external commit can remove an arbitrary group member
Summary
In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit's proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit's path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator's self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group's public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member's LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf's credential is identical to the one in the joiner's own new leaf, on both the sending and the receiving side.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 15:57 UTC
CWE
- CWE-863 - Incorrect Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/7e8bb10eb… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71890",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T15:57:58.996250Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T15:58:20.685Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"mls"
],
"packageName": "bcmls",
"packageURL": "pkg:maven/org.bouncycastle/bcmls-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"Group"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit\u0027s proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit\u0027s path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator\u0027s self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group\u0027s public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member\u0027s LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf\u0027s credential is identical to the one in the joiner\u0027s own new leaf, on both the sending and the receiving side.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit\u0027s proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit\u0027s path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator\u0027s self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group\u0027s public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member\u0027s LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf\u0027s credential is identical to the one in the joiner\u0027s own new leaf, on both the sending and the receiving side."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:57:00.965Z",
"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%9071890"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/7e8bb10eb90baddf3f10b8679f627462b9522d24"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "MLS external commit can remove an arbitrary group member",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71890",
"datePublished": "2026-10-03T08:57:00.965Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T15:58:20.685Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71889 (GCVE-0-2026-71889)
Vulnerability from nvd – Published: 2026-10-03 08:31 – Updated: 2026-10-05 16:57
VLAI
EPSS
VEX
Title
PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate
Summary
In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:55 UTC
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/06dcff2f5… | patch |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.4 , < 1.0.13
(maven)
Affected: 2.0.0 , < 2.0.13 (maven) Affected: 2.1.0 , < 2.1.13 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71889",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:55:41.462500Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:57:32.912Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PKIXCertPathReviewer"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PKIXCertPathReviewer"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PKIXCertPathReviewer"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.13",
"status": "affected",
"version": "1.0.4",
"versionType": "maven"
},
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf\u0027s subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance(\"PKIX\", \"BC\"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf\u0027s subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance(\"PKIX\", \"BC\"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:31:01.178Z",
"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%9071889"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/06dcff2f51037095de126986285c998e3455ab85"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71889",
"datePublished": "2026-10-03T08:31:01.178Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T16:57:32.912Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71888 (GCVE-0-2026-71888)
Vulnerability from nvd – Published: 2026-10-03 08:36 – Updated: 2026-10-05 16:52
VLAI
EPSS
VEX
Title
CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent
Summary
In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:51 UTC
CWE
- CWE-354 - Improper Validation of Integrity Check Value
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/dcb683b32… | patch |
Impacted products
5 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.70 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.13
(maven)
Affected: 2.0.0 , < 2.0.13 (maven) Affected: 2.1.0 , < 2.1.13 (maven) |
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
2.0.0 , < 2.0.8
(maven)
Affected: 2.1.0 , < 2.1.8 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71888",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:51:49.725826Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:52:07.424Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"CMSAuthenticatedDataParser"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"util"
],
"packageName": "bcutil",
"packageURL": "pkg:maven/org.bouncycastle/bcutil-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"AuthenticatedData"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.70",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"CMSAuthenticatedDataParser"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"util"
],
"packageName": "bcutil-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcutil-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"AuthenticatedData"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.13",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
},
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcutil-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcutil-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.0.8",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.8",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Bhargava Shastry"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-354",
"description": "CWE-354 Improper Validation of Integrity Check Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:36:12.960Z",
"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%9071888"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/dcb683b32b440f1beb1d2276a34930164281fb95"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71888",
"datePublished": "2026-10-03T08:36:12.960Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T16:52:07.424Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71887 (GCVE-0-2026-71887)
Vulnerability from nvd – Published: 2026-10-03 08:39 – Updated: 2026-10-05 16:04
VLAI
EPSS
VEX
Title
OpenPGP data signature accepted from a signing subkey without cross-certification
Summary
In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:04 UTC
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/b51452fa4… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.81 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71887",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:04:02.766987Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:04:21.150Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"OpenPGPCertificate"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.81",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Arpan Sharma"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected."
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-347",
"description": "CWE-347 Improper Verification of Cryptographic Signature",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-345",
"description": "CWE-345 Insufficient Verification of Data Authenticity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:39:07.997Z",
"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%9071887"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "OpenPGP data signature accepted from a signing subkey without cross-certification",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71887",
"datePublished": "2026-10-03T08:39:07.997Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-05T16:04:21.150Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71886 (GCVE-0-2026-71886)
Vulnerability from nvd – Published: 2026-10-03 08:46 – Updated: 2026-10-05 16:03
VLAI
EPSS
VEX
Title
OpenPGP certification accepted from a subkey without certification authority
Summary
In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:02 UTC
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/f0d5c8535… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.81 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71886",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:02:59.243532Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:03:23.403Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"OpenPGPCertificate"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.81",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Bhargava Shastry"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component\u0027s binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker\u0027s assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key\u0027s signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key\u0027s identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component\u0027s binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker\u0027s assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key\u0027s signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key\u0027s identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it."
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-285",
"description": "CWE-285 Improper Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:46:33.868Z",
"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%9071886"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/f0d5c8535aeff3f34b7b6b6289ee78c2ea36a3fb"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "OpenPGP certification accepted from a subkey without certification authority",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71886",
"datePublished": "2026-10-03T08:46:33.868Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-05T16:03:23.403Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71885 (GCVE-0-2026-71885)
Vulnerability from nvd – Published: 2026-10-03 08:51 – Updated: 2026-10-05 16:01
VLAI
EPSS
VEX
Title
MLS X.509 credential not bound to the LeafNode signature key
Summary
In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:00 UTC
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/77632a57e… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71885",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:00:54.750454Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:01:11.470Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"mls"
],
"packageName": "bcmls",
"packageURL": "pkg:maven/org.bouncycastle/bcmls-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"LeafNode"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Joshua Rogers and Khaled Suliman of AISLE Research"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode\u0027s signature_key. LeafNode.verify() checked a leaf\u0027s signature against the signature_key carried in the leaf itself, while the credential\u0027s X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate\u0027s public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party\u0027s certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party\u0027s identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim\u0027s X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate\u0027s subject public key, in the cipher suite\u0027s signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application\u0027s responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode\u0027s signature_key. LeafNode.verify() checked a leaf\u0027s signature against the signature_key carried in the leaf itself, while the credential\u0027s X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate\u0027s public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party\u0027s certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party\u0027s identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim\u0027s X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate\u0027s subject public key, in the cipher suite\u0027s signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application\u0027s responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.2,
"baseSeverity": "CRITICAL",
"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:H/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-287",
"description": "CWE-287 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:51:53.292Z",
"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%9071885"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/77632a57edf350a7b5751fca1a5052daffa8dab2"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "MLS X.509 credential not bound to the LeafNode signature key",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71885",
"datePublished": "2026-10-03T08:51:53.292Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-05T16:01:11.470Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18040 (GCVE-0-2026-18040)
Vulnerability from nvd – Published: 2026-10-03 08:55 – Updated: 2026-10-05 16:00
VLAI
EPSS
VEX
Title
HQC leaks private key information through secret-indexed GF(2^8) tables and a secret-dependent fixed-weight sampler
Summary
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:00 UTC
CWE
- CWE-208 - Observable Timing Discrepancy
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/283acd810… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18040",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:00:03.782416Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:00:20.062Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"GF",
"HQCEngine",
"ReedSolomon",
"FastFourierTransform"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "The Robusta team: Deepak Bhargavan Pillai, Anirban Chakraborty, Chitchanok Chuengsatiansup, Matthew Roughan, Peter Schwabe, and Yuval Yarom"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:H/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-208",
"description": "CWE-208 Observable Timing Discrepancy",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:55:06.766Z",
"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%9018040"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/283acd81048ec9e951032525279d3b58aaf0bb03"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "HQC leaks private key information through secret-indexed GF(2^8) tables and a secret-dependent fixed-weight sampler",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-18040",
"datePublished": "2026-10-03T08:55:06.766Z",
"dateReserved": "2026-07-28T08:50:28.760Z",
"dateUpdated": "2026-10-05T16:00:20.062Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18036 (GCVE-0-2026-18036)
Vulnerability from nvd – Published: 2026-10-02 07:54 – Updated: 2026-10-02 17:42
VLAI
EPSS
VEX
Title
NTRU leaks private key information by reducing secret values with a non-constant-time integer division
Summary
In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation's division-free fold and select; the results are unchanged.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-02 17:42 UTC
CWE
- CWE-208 - Observable Timing Discrepancy
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/9c9ad88b6… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18036",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-02T17:42:43.345821Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T17:42:56.393Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"Polynomial",
"NTRUSampling"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "The Robusta team: Deepak Bhargavan Pillai, Anirban Chakraborty, Chitchanok Chuengsatiansup, Matthew Roughan, Peter Schwabe, and Yuval Yarom"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation\u0027s division-free fold and select; the results are unchanged.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation\u0027s division-free fold and select; the results are unchanged."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"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:H/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-208",
"description": "CWE-208 Observable Timing Discrepancy",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T07:54:16.063Z",
"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%9018036"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/9c9ad88b6003bb6230d2434bd892cc1e95b294e4"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "NTRU leaks private key information by reducing secret values with a non-constant-time integer division",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-18036",
"datePublished": "2026-10-02T07:54:16.063Z",
"dateReserved": "2026-07-28T08:28:40.900Z",
"dateUpdated": "2026-10-02T17:42:56.393Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17508 (GCVE-0-2026-17508)
Vulnerability from nvd – Published: 2026-10-02 07:27 – Updated: 2026-10-02 17:43
VLAI
EPSS
VEX
Title
Password-based KDF cost parameters honoured unbounded from untrusted input across the remaining PBE entry points
Summary
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-02 17:43 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
7 references
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.13
(maven)
Affected: 2.0.0 , < 2.0.13 (maven) Affected: 2.1.0 , < 2.1.13 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17508",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-02T17:43:15.561288Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T17:43:24.578Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"JcePBMac1CalculatorBuilder",
"PKCS12PBEUtils",
"JcePKCSPBEInputDecryptorProviderBuilder",
"JceOpenSSLPKCS8DecryptorProviderBuilder"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core",
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PBEPBKDF2",
"OpenSSHPrivateKeyUtil"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"JcePBMac1CalculatorBuilder",
"PKCS12PBEUtils",
"JcePKCSPBEInputDecryptorProviderBuilder",
"JceOpenSSLPKCS8DecryptorProviderBuilder"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"core",
"prov"
],
"packageName": "bcprov-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PBEPBKDF2",
"OpenSSHPrivateKeyUtil"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.13",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
},
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Mirko Swillus on behalf of Alpha-Omega (alpha-omega.dev), using Scrutineer with an Anthropic Claude model provided through Project Glasswing"
},
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key\u0027s own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key\u0027s own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T07:27:59.519Z",
"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%9017508"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/882fdab53f6c4c150a5d6a4e6ef1fc05d382385a"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/442393bf187c914b1e66fbed4fab532a1fe06c6a"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/20ed9e203caec91d25cd386ceb6d364e9b068f67"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/766a31026ac24ed3c6cad8662058ba450c338da1"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/e72bc0681ff4227fced912ef7394daf7b7d57bb3"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/480d878aa6f7dc8b20403064f304bbe0decbbb1a"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Password-based KDF cost parameters honoured unbounded from untrusted input across the remaining PBE entry points",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-17508",
"datePublished": "2026-10-02T07:27:59.519Z",
"dateReserved": "2026-07-26T22:44:21.286Z",
"dateUpdated": "2026-10-02T17:43:24.578Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17507 (GCVE-0-2026-17507)
Vulnerability from nvd – Published: 2026-10-02 07:26 – Updated: 2026-10-02 17:43
VLAI
EPSS
VEX
Title
MLS membership checks compare a uint32 leaf_index as signed, admitting an out-of-range sender
Summary
In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420's uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree's leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-02 17:43 UTC
CWE
- CWE-195 - Signed to Unsigned Conversion Error
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/1eb83471e… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17507",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-02T17:43:42.891835Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T17:43:56.738Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"mls"
],
"packageName": "bcmls",
"packageURL": "pkg:maven/org.bouncycastle/bcmls-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"GroupKeySet",
"Group"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Mirko Swillus on behalf of Alpha-Omega (alpha-omega.dev), using Scrutineer with an Anthropic Claude model provided through Project Glasswing"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420\u0027s uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree\u0027s leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420\u0027s uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree\u0027s leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-195",
"description": "CWE-195 Signed to Unsigned Conversion Error",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T07:26:34.739Z",
"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%9017507"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/1eb83471eb01727bfdb944a5a46355cc77d55f44"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "MLS membership checks compare a uint32 leaf_index as signed, admitting an out-of-range sender",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-17507",
"datePublished": "2026-10-02T07:26:34.739Z",
"dateReserved": "2026-07-26T22:40:20.567Z",
"dateUpdated": "2026-10-02T17:43:56.738Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-14682 (GCVE-0-2026-14682)
Vulnerability from nvd – Published: 2026-08-03 02:44 – Updated: 2026-08-04 09:24
VLAI
EPSS
VEX
Title
Possible OOM from unbounded up-front allocation on a definite-length read
Summary
In Bouncy Castle for Java before 1.85, Possible OOM from unbounded up-front allocation on a definite-length read. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), and before bctls-fips 1.0.24.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-03 15:31 UTC
CWE
- CWE-789 - Memory Allocation with Excessive Size Value
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/37094e504… | patch |
Impacted products
4 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.85
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.12
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.2.7
(maven)
Affected: 2.0.0 , < 2.0.2 (maven) Affected: 2.1.0 , < 2.1.3 (maven) |
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.24
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-14682",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-03T15:31:04.802553Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T15:31:31.854Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"DefiniteLengthInputStream"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.85",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"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": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"DefiniteLengthInputStream"
],
"repo": "https://github.com/bcgit/bc-lts-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.73.12",
"status": "affected",
"version": "2.73.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bc-fips",
"packageURL": "pkg:maven/org.bouncycastle/bc-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.2.7",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
},
{
"lessThan": "2.0.2",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.3",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bctls-fips",
"packageURL": "pkg:maven/org.bouncycastle/bctls-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.24",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Micha\u0142 Majchrowicz and Marcin Wyczechowski, members of the AFINE Team."
},
{
"lang": "en",
"type": "finder",
"value": "Yt"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.85, Possible OOM from unbounded up-front allocation on a definite-length read. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), and before bctls-fips 1.0.24.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.85, Possible OOM from unbounded up-front allocation on a definite-length read. This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), and before bctls-fips 1.0.24."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-789",
"description": "CWE-789 Memory Allocation with Excessive Size Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-04T09:24:50.033Z",
"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%9014682"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/37094e504ef50cf9ce4e0fb9e5105d495ff5c2d2"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Possible OOM from unbounded up-front allocation on a definite-length read",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-14682",
"datePublished": "2026-08-03T02:44:13.256Z",
"dateReserved": "2026-07-04T00:33:39.368Z",
"dateUpdated": "2026-08-04T09:24:50.033Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-13586 (GCVE-0-2026-13586)
Vulnerability from nvd – Published: 2026-08-03 02:58 – Updated: 2026-08-03 15:03
VLAI
EPSS
VEX
Title
PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS)
Summary
In Bouncy Castle for Java before 1.85, PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS). This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-03 15:03 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
3 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/fa59cc235… | patch |
| https://github.com/bcgit/bc-java/commit/75d60dfb4… | patch |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.85
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.12
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.2.7
(maven)
Affected: 2.0.0 , < 2.0.2 (maven) Affected: 2.1.0 , < 2.1.3 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-13586",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-08-03T15:03:33.340510Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T15:03:49.757Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PKCS12KeyStoreSpi",
"PKCS12PBMAC1KeyStoreSpi",
"PKCS12Util"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.85",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PKCS12KeyStoreSpi",
"PKCS12PBMAC1KeyStoreSpi",
"PKCS12Util"
],
"repo": "https://github.com/bcgit/bc-lts-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.73.12",
"status": "affected",
"version": "2.73.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bc-fips",
"packageURL": "pkg:maven/org.bouncycastle/bc-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.2.7",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
},
{
"lessThan": "2.0.2",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.3",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.85, PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS). This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.85, PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS). This issue also affects Bouncy Castle for Java LTS before 2.73.12, and Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-03T05:55:23.786Z",
"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%9013586"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/fa59cc23502f73def89d94374540cc92af647b96"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/75d60dfb4ca72bea6da96234138bc9b1556ef5b0"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "PKCS#12 MAC and bag-decryption KDF iteration-count bound (DoS)",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-13586",
"datePublished": "2026-08-03T02:58:00.982Z",
"dateReserved": "2026-06-29T04:09:24.833Z",
"dateUpdated": "2026-08-03T15:03:49.757Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71890 (GCVE-0-2026-71890)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:57 – Updated: 2026-10-05 15:58
VLAI
EPSS
VEX
Title
MLS external commit can remove an arbitrary group member
Summary
In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit's proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit's path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator's self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group's public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member's LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf's credential is identical to the one in the joiner's own new leaf, on both the sending and the receiving side.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 15:57 UTC
CWE
- CWE-863 - Incorrect Authorization
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/7e8bb10eb… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71890",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T15:57:58.996250Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T15:58:20.685Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"mls"
],
"packageName": "bcmls",
"packageURL": "pkg:maven/org.bouncycastle/bcmls-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"Group"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit\u0027s proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit\u0027s path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator\u0027s self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group\u0027s public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member\u0027s LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf\u0027s credential is identical to the one in the joiner\u0027s own new leaf, on both the sending and the receiving side.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit\u0027s proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit\u0027s path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator\u0027s self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group\u0027s public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member\u0027s LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf\u0027s credential is identical to the one in the joiner\u0027s own new leaf, on both the sending and the receiving side."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:57:00.965Z",
"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%9071890"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/7e8bb10eb90baddf3f10b8679f627462b9522d24"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "MLS external commit can remove an arbitrary group member",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71890",
"datePublished": "2026-10-03T08:57:00.965Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T15:58:20.685Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71891 (GCVE-0-2026-71891)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:56 – Updated: 2026-10-05 15:59
VLAI
EPSS
VEX
Title
BLS12-381 key validation accepts a public key built on a foreign curve
Summary
In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381's field characteristic. The prime-order subgroup check trusts a point's own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve's cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC's pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point's curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 15:59 UTC
CWE
- CWE-347 - Improper Verification of Cryptographic Signature
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/c16bcfdce… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.85 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71891",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T15:59:14.270246Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T15:59:26.486Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"BLS12_381BasicScheme",
"BLS12_381G1"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.85",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Bhargava Shastry"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381\u0027s field characteristic. The prime-order subgroup check trusts a point\u0027s own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve\u0027s cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC\u0027s pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point\u0027s curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381\u0027s field characteristic. The prime-order subgroup check trusts a point\u0027s own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve\u0027s cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC\u0027s pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point\u0027s curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 7.1,
"baseSeverity": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-347",
"description": "CWE-347 Improper Verification of Cryptographic Signature",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:56:01.050Z",
"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%9071891"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/c16bcfdce1f96230261b7c2c8c1e044bfc9d1deb"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "BLS12-381 key validation accepts a public key built on a foreign curve",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71891",
"datePublished": "2026-10-03T08:56:01.050Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T15:59:26.486Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18040 (GCVE-0-2026-18040)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:55 – Updated: 2026-10-05 16:00
VLAI
EPSS
VEX
Title
HQC leaks private key information through secret-indexed GF(2^8) tables and a secret-dependent fixed-weight sampler
Summary
In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:00 UTC
CWE
- CWE-208 - Observable Timing Discrepancy
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/283acd810… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18040",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:00:03.782416Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:00:20.062Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"GF",
"HQCEngine",
"ReedSolomon",
"FastFourierTransform"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "The Robusta team: Deepak Bhargavan Pillai, Anirban Chakraborty, Chitchanok Chuengsatiansup, Matthew Roughan, Peter Schwabe, and Yuval Yarom"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, HQC leaked secret-derived data through two side channels: its GF(2^8) arithmetic used lookup tables indexed by field elements, making the cache line touched a function of the operand, and its fixed-weight support sampler left its duplicate scan as soon as a collision was found and stored accepted positions at a secret index. Both run on secret inputs during encapsulation and decapsulation, and the sampler re-expands the secret key from its seed on every decapsulation, so an attacker able to observe cache behaviour or decapsulation timing can recover information about the HQC private key. The field arithmetic is now table-free and the sampler branch-free within a batch of candidates, with output and randomness consumption unchanged."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "LOCAL",
"baseScore": 5.9,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:L/AC:H/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-208",
"description": "CWE-208 Observable Timing Discrepancy",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:55:06.766Z",
"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%9018040"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/283acd81048ec9e951032525279d3b58aaf0bb03"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "HQC leaks private key information through secret-indexed GF(2^8) tables and a secret-dependent fixed-weight sampler",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-18040",
"datePublished": "2026-10-03T08:55:06.766Z",
"dateReserved": "2026-07-28T08:50:28.760Z",
"dateUpdated": "2026-10-05T16:00:20.062Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71885 (GCVE-0-2026-71885)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:51 – Updated: 2026-10-05 16:01
VLAI
EPSS
VEX
Title
MLS X.509 credential not bound to the LeafNode signature key
Summary
In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: total
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:00 UTC
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/77632a57e… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71885",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:00:54.750454Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:01:11.470Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"mls"
],
"packageName": "bcmls",
"packageURL": "pkg:maven/org.bouncycastle/bcmls-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"LeafNode"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Joshua Rogers and Khaled Suliman of AISLE Research"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode\u0027s signature_key. LeafNode.verify() checked a leaf\u0027s signature against the signature_key carried in the leaf itself, while the credential\u0027s X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate\u0027s public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party\u0027s certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party\u0027s identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim\u0027s X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate\u0027s subject public key, in the cipher suite\u0027s signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application\u0027s responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode\u0027s signature_key. LeafNode.verify() checked a leaf\u0027s signature against the signature_key carried in the leaf itself, while the credential\u0027s X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate\u0027s public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party\u0027s certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party\u0027s identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim\u0027s X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate\u0027s subject public key, in the cipher suite\u0027s signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application\u0027s responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.2,
"baseSeverity": "CRITICAL",
"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:H/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-287",
"description": "CWE-287 Improper Authentication",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:51:53.292Z",
"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%9071885"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/77632a57edf350a7b5751fca1a5052daffa8dab2"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "MLS X.509 credential not bound to the LeafNode signature key",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71885",
"datePublished": "2026-10-03T08:51:53.292Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-05T16:01:11.470Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71886 (GCVE-0-2026-71886)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:46 – Updated: 2026-10-05 16:03
VLAI
EPSS
VEX
Title
OpenPGP certification accepted from a subkey without certification authority
Summary
In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component's binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker's assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key's signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key's identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:02 UTC
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/f0d5c8535… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.81 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71886",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:02:59.243532Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:03:23.403Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"OpenPGPCertificate"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.81",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Bhargava Shastry"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component\u0027s binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker\u0027s assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key\u0027s signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key\u0027s identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the high-level OpenPGP certificate API accepted a third-party certification or trust delegation from any component key of the issuing certificate, without requiring that component to have been granted the authority to certify. OpenPGPCertificate.getCertificationBy() and getDelegationBy() resolve a third-party signature by matching its issuer key identifier against every key of the third-party certificate, then verify the issuing component\u0027s binding chain and the signature itself; nothing checked that the issuing component carried the RFC 9580 sec. 5.2.3.29 certification key flag (CERTIFY_OTHER) when the signature was created. A subkey bound only with SIGN_DATA - the online signing subkey of exactly the offline-primary arrangement those key flags exist to express - could therefore issue a positive User ID certification over an attacker-controlled identity, or a full-trust depth-one direct-key delegation of introducer trust, and the API returned it as a valid signature chain attributed to the third-party certificate. An application treating getCertificationBy(...).isValid() or getDelegationBy(...) as an identity or trusted-introducer decision would attribute the attacker\u0027s assertion to the offline primary key. The same held for a legacy RSA subkey bound only for encryption, whose algorithm is nonetheless able to sign. This does not forge the primary key\u0027s signature or recover any private key; it promotes an already-compromised restricted subkey to the primary key\u0027s identity-issuing authority, defeating the containment the key-flag separation provides. A third-party certification or delegation is now attributed to the issuing certificate only when the component key that made it is the primary key, or is a subkey holding CERTIFY_OTHER when the signature was created, so certification-capable subkeys continue to be accepted; primary keys are accepted whatever their key flags say, since a primary key is certification-capable by construction and certificates carrying no key flags subpacket at all are common. Third-party revocations are deliberately outside the rule, since declining to honour one would keep trust alive rather than withdraw it."
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-863",
"description": "CWE-863 Incorrect Authorization",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-285",
"description": "CWE-285 Improper Authorization",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:46:33.868Z",
"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%9071886"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/f0d5c8535aeff3f34b7b6b6289ee78c2ea36a3fb"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "OpenPGP certification accepted from a subkey without certification authority",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71886",
"datePublished": "2026-10-03T08:46:33.868Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-05T16:03:23.403Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71887 (GCVE-0-2026-71887)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:39 – Updated: 2026-10-05 16:04
VLAI
EPSS
VEX
Title
OpenPGP data signature accepted from a signing subkey without cross-certification
Summary
In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey's own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey's key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key's direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary's SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature's own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim's public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey's private key, and a relying party verifying one of the victim's genuinely signed messages against that certificate is told the signature is valid and given the attacker's certificate as its issuer. Because a certificate's User IDs are self-asserted, a verifier that pins on the subkey's fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary's, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:04 UTC
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/b51452fa4… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.81 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71887",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:04:02.766987Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:04:21.150Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"OpenPGPCertificate"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.81",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Arpan Sharma"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the high-level OpenPGP API accepted a data signature made by a signing subkey whose Subkey Binding signature carried no embedded Primary Key Binding (cross-certification) signature, in the case where that binding omits a Key Flags subpacket. RFC 9580 sec. 5.2.1.8 and sec. 10.1.3 require the embedded Primary Key Binding signature on any subkey that can issue signatures; it is the subkey\u0027s own statement that it belongs to the primary key it is bound under. OpenPGPCertificate resolved the subkey\u0027s key flags two different ways. isSigningKey() goes through getKeyFlags() and getApplyingSubpacket(), which falls back to the primary key\u0027s direct-key or primary User ID self-signature when the binding signature omits the subpacket, so the subkey inherited the primary\u0027s SIGN_DATA and counted as signing-capable; verifyEmbeddedPrimaryKeyBinding(), which enforces the requirement, reads the binding signature\u0027s own hashed subpackets, found no SIGN_DATA there, and returned early as a non-signing key without ever demanding the back signature. The same subkey was therefore signing-capable - so its signatures were attributed to the certificate and OpenPGPSignature.OpenPGPDocumentSignature.isValid() returned true - while being exempt from cross-certification, where GnuPG refuses the identical certificate and message. An attacker needs only the victim\u0027s public signing subkey, which is public material: they bind it to their own primary key with a Subkey Binding signature they are able to make, carrying no Key Flags and no embedded Primary Key Binding signature, which they cannot make without the subkey\u0027s private key, and a relying party verifying one of the victim\u0027s genuinely signed messages against that certificate is told the signature is valid and given the attacker\u0027s certificate as its issuer. Because a certificate\u0027s User IDs are self-asserted, a verifier that pins on the subkey\u0027s fingerprint or key ID while taking the identity from the enclosing certificate reports a real signature under an attacker-chosen identity. This is misattribution of a genuine signature rather than forgery of a new one: no private key is recovered, and the signature must be one the grafted subkey actually made. The low-level PGPSignature / PGPPublicKeyRing API performs no binding checks by design and is unaffected. Key Flags are a statement about the key the carrying signature refers to (RFC 9580 sec. 5.2.3.29), so a subkey no longer inherits them from the certificate-wide signatures of the primary key: a Subkey Binding signature that omits the subpacket now leaves the subkey with no capabilities rather than the primary\u0027s, which makes the flags the cross-certification check consults the same flags every other decision consults. Preferences and the other subpackets a direct-key signature carries are inherited as before, and the primary key itself, whose flags legitimately come from its own direct-key or User ID self-signature, is unaffected."
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-347",
"description": "CWE-347 Improper Verification of Cryptographic Signature",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-345",
"description": "CWE-345 Insufficient Verification of Data Authenticity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:39:07.997Z",
"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%9071887"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/b51452fa48ccb578fc16b8222fce9eedf92c94d6"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "OpenPGP data signature accepted from a signing subkey without cross-certification",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71887",
"datePublished": "2026-10-03T08:39:07.997Z",
"dateReserved": "2026-08-08T00:06:06.982Z",
"dateUpdated": "2026-10-05T16:04:21.150Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71888 (GCVE-0-2026-71888)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:36 – Updated: 2026-10-05 16:52
VLAI
EPSS
VEX
Title
CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent
Summary
In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:51 UTC
CWE
- CWE-354 - Improper Validation of Integrity Check Value
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/dcb683b32… | patch |
Impacted products
5 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.70 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.13
(maven)
Affected: 2.0.0 , < 2.0.13 (maven) Affected: 2.1.0 , < 2.1.13 (maven) |
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
2.0.0 , < 2.0.8
(maven)
Affected: 2.1.0 , < 2.1.8 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71888",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:51:49.725826Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:52:07.424Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"CMSAuthenticatedDataParser"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"util"
],
"packageName": "bcutil",
"packageURL": "pkg:maven/org.bouncycastle/bcutil-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"AuthenticatedData"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.70",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"CMSAuthenticatedDataParser"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"util"
],
"packageName": "bcutil-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcutil-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"AuthenticatedData"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.13",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
},
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcutil-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcutil-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.0.8",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.8",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Bhargava Shastry"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the streaming CMS AuthenticatedData parser accepted a message whose digestAlgorithm and authAttrs fields disagreed about whether authenticated attributes were present. RFC 5652 sec. 9.1 pairs the two, requiring that authAttrs be present whenever digestAlgorithm is, and sec. 9.2 makes the MAC cover the DER encoding of authAttrs when they are present and the eContent OCTET STRING directly when they are not. CMSAuthenticatedDataParser has to choose between those two in its constructor, before it can reach authAttrs, which comes later in the SEQUENCE, so it chose on digestAlgorithm alone: for a message with digestAlgorithm absent but authAttrs present it verified the content MAC and then returned the attributes through getAuthAttrs() as though they had been authenticated, when the MAC had never covered them. An attacker able to modify a message in transit could insert an authenticated attribute, such as an RFC 2634 ESSSecurityLabel, into an otherwise valid message while holding neither the key-encryption key nor the content-MAC key, and an application taking an authorization, routing or labelling decision from those attributes would act on attacker-chosen values. The content itself remained MAC-bound. asn1.cms.AuthenticatedData now rejects the mismatched pairing when parsing and CMSAuthenticatedDataParser cross-checks the two fields once authAttrs is read. This is a variant of CVE-2026-59642, which bound the content to the MAC for messages that legitimately carry authAttrs, and which does not address this case. This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series), and bcutil-fips 2.0.8 (2.0.X series) and 2.1.8 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-354",
"description": "CWE-354 Improper Validation of Integrity Check Value",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:36:12.960Z",
"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%9071888"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/dcb683b32b440f1beb1d2276a34930164281fb95"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "CMS AuthenticatedData exposes attacker-inserted authAttrs when digestAlgorithm is absent",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71888",
"datePublished": "2026-10-03T08:36:12.960Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T16:52:07.424Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71889 (GCVE-0-2026-71889)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:31 – Updated: 2026-10-05 16:57
VLAI
EPSS
VEX
Title
PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate
Summary
In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf's subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance("PKIX", "BC"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:55 UTC
CWE
- CWE-295 - Improper Certificate Validation
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/06dcff2f5… | patch |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.4 , < 1.0.13
(maven)
Affected: 2.0.0 , < 2.0.13 (maven) Affected: 2.1.0 , < 2.1.13 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71889",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:55:41.462500Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:57:32.912Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PKIXCertPathReviewer"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PKIXCertPathReviewer"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PKIXCertPathReviewer"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.13",
"status": "affected",
"version": "1.0.4",
"versionType": "maven"
},
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf\u0027s subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance(\"PKIX\", \"BC\"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, neither copy of PKIXCertPathReviewer - org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer nor the legacy org.bouncycastle.x509.PKIXCertPathReviewer - applied X.509 name constraints to the end-entity certificate. checkNameConstraints walked the path with a loop bound of index greater than zero, which is the bound the CA-only steps require, but index zero is the target certificate under the standard CertPath ordering, so the permitted and excluded subtree checks of RFC 5280 sec. 6.1.3 (b) and (c) never ran against the leaf\u0027s subject DN or its subjectAltName. A chain whose leaf violated a NameConstraints extension imposed by its own issuing CA therefore reported isValidCertPath() true with an empty error list, while CertPathValidator.getInstance(\"PKIX\", \"BC\"), which shares no code with the reviewer, rejected the identical chain against the identical trust anchor. An application using the reviewer to make the trust decision rather than for diagnostics alongside a real validation accepted a certificate the constrained CA was never authorised to issue. Both copies now check every certificate in the path including the target, waive the sec. 4.2.1.10 self-issued exemption for the final certificate as sec. 6.1.3 requires, and skip the sec. 6.1.4 (g) constraint-accumulation step for the target. This issue also affects Bouncy Castle for Java LTS before 2.73.13, which carries only the org.bouncycastle.pkix.jcajce copy of the reviewer. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-295",
"description": "CWE-295 Improper Certificate Validation",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:31:01.178Z",
"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%9071889"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/06dcff2f51037095de126986285c998e3455ab85"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "PKIXCertPathReviewer does not apply X.509 name constraints to the target certificate",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71889",
"datePublished": "2026-10-03T08:31:01.178Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T16:57:32.912Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-71892 (GCVE-0-2026-71892)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:30 – Updated: 2026-10-05 16:58
VLAI
EPSS
VEX
Title
CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys
Summary
In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier's parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier's algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 16:58 UTC
CWE
- CWE-697 - Incorrect Comparison
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/be0a7d925… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.78 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
2.0.7 , < 2.0.13
(maven)
Affected: 2.1.0 , < 2.1.13 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-71892",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T16:58:15.636238Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T16:58:40.411Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"JceKeyTransRecipient"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.78",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.7",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier\u0027s parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier\u0027s algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier\u0027s parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier\u0027s algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 6.9,
"baseSeverity": "MEDIUM",
"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:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "LOW",
"vulnIntegrityImpact": "LOW",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-697",
"description": "CWE-697 Incorrect Comparison",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:30:26.982Z",
"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%9071892"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/be0a7d925c818ef2f338bcec55178b9b6336dfc3"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-71892",
"datePublished": "2026-10-03T08:30:26.982Z",
"dateReserved": "2026-08-08T00:06:07.401Z",
"dateUpdated": "2026-10-05T16:58:40.411Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-85515 (GCVE-0-2026-85515)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:05 – Updated: 2026-10-03 08:05
VLAI
EPSS
VEX
Title
OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check
Summary
In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer's integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.
Severity
CWE
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/ab7a235d1… | patch |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.74 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.7 , < 1.0.14
(maven)
Affected: 2.0.7 , < 2.0.14.1 (maven) Affected: 2.1.0 , < 2.1.14 (maven) |
{
"containers": {
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"BcAEADUtil",
"JceAEADUtil",
"IntegrityProtectedInputStream",
"OpenPGPMessageInputStream"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.74",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pg"
],
"packageName": "bcpg-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"BcAEADUtil",
"JceAEADUtil"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpg-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpg-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.14",
"status": "affected",
"version": "1.0.7",
"versionType": "maven"
},
{
"lessThan": "2.0.14.1",
"status": "affected",
"version": "2.0.7",
"versionType": "maven"
},
{
"lessThan": "2.1.14",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Arpan Sharma"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer\u0027s integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, a truncated OpenPGP encrypted message was accepted with no error reported, and on the SEIPD version 1 path with no integrity check performed at all. RFC 9580 sec. 13.7 permits an implementation to release the cleartext of the fully authenticated chunks when streaming but requires it to indicate a clear error as soon as the truncation is detected, and to report suspect integrity when it discovers malleable ciphertext. The truncation was detected and then discarded: when a message is truncated but the length field of the enclosing packet is left unchanged, BCPGInputStream.PartialInputStream raises an EOFException for the missing ciphertext, and BCPGInputStream.nextPacketTag() reports an EOFException as a clean end of message, so the packet stream above it stopped as though no packets remained. On the AEAD path (SEIPD version 2 and the version 5 AEAD packet), when the literal data packet ended on an AEAD chunk boundary and the consumer read in increments smaller than one chunk, the look-ahead for the packet after the literal triggered the truncated chunk read, so BcAEADUtil and JceAEADUtil never reached the trailing message tag of sec. 5.13.2 that authenticates the total plaintext length; the caller received the plaintext of the fully authenticated chunks, every packet following the literal was silently dropped, and no exception was raised, so a signed and encrypted message read back as a well-formed unsigned one. Every byte released on that path remained individually authenticated, making this a missing truncation error rather than a forgery, and it is a residual of CVE-2026-12817, which closed the same outcome for an attacker who corrects the outer packet length. On the SEIPD version 1 path the consequence was more serious: IntegrityProtectedInputStream verifies the modification detection code from close(), and reached close() only by closing itself when a read of it returned -1, which a truncated message never produces, so PGPEncryptedData.verify() never ran and the recipient was handed CFB-decrypted plaintext on which no integrity check of any kind had been performed. Measured on a message truncated into that shape, 136 distinct single-byte modifications of the ciphertext produced accepted, altered plaintext with no exception raised. Reachability is a property of the message rather than of attacker-supplied input: the AEAD shape held for 3 of 131 consecutive payload lengths measured, and the SEIPD version 1 shape for one payload length in sixteen, at a truncation offset that did not move with the payload length. The low-level API is unaffected, a caller that invokes PGPEncryptedData.verify() directly getting the check regardless, as are consumers reading in increments of a whole AEAD chunk or more. The AEAD decryption streams now re-throw such an EOFException as a plain IOException, which nextPacketTag() does not launder; OpenPGPMessageInputStream.close() now closes its layer\u0027s integrity-protected stream itself rather than relying on that stream having seen the end of its data; and IntegrityProtectedInputStream.close() was made idempotent, as java.io.Closeable requires, which that depends on, since the stream is genuinely closed twice on the ordinary path and PGPEncryptedData.verify() consumes the digest state behind it and cannot be run a second time. This issue also affects Bouncy Castle for Java LTS before 2.73.13, on the AEAD route only, as that edition does not ship the high-level OpenPGP API the SEIPDv1 route runs through. It also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpg-fips 1.0.14 (1.0.X series), 2.0.14.1 (2.0.X series) and 2.1.14 (2.1.X series), on the AEAD route only, as those editions do not ship the high-level OpenPGP API."
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-354",
"description": "CWE-354 Improper Validation of Integrity Check Value",
"lang": "en",
"type": "CWE"
},
{
"cweId": "CWE-345",
"description": "CWE-345 Insufficient Verification of Data Authenticity",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:05:16.553Z",
"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%9085515"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/ab7a235d1c20e3da28ce77167a96b5c14025efa7"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "OpenPGP message truncation not reported, bypassing the SEIPDv1 integrity check",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-85515",
"datePublished": "2026-10-03T08:05:16.553Z",
"dateReserved": "2026-09-04T05:38:18.070Z",
"dateUpdated": "2026-10-03T08:05:16.553Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-97873 (GCVE-0-2026-97873)
Vulnerability from cvelistv5 – Published: 2026-10-03 08:04 – Updated: 2026-10-05 17:00
VLAI
EPSS
VEX
Title
Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider
Summary
In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-05 17:00 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/766a31026… | patch |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
Date Public
2026-10-03 08:14
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-97873",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-05T17:00:30.479924Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-05T17:00:58.750Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PBE",
"PBEPKCS12",
"PBEPBKDF1",
"PBESecretKeyFactory",
"BaseBlockCipher",
"BaseStreamCipher",
"BaseWrapCipher",
"BaseMac"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"prov"
],
"packageName": "bcprov-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PBE",
"PBEPKCS12",
"PBEPBKDF1",
"PBESecretKeyFactory",
"BaseBlockCipher",
"BaseStreamCipher",
"BaseWrapCipher",
"BaseMac"
],
"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.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Arpan Sharma"
}
],
"datePublic": "2026-10-03T08:14:00.000Z",
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the raw JCA provider\u0027s legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider\u0027s AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the raw JCA provider\u0027s legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider\u0027s AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-03T08:53:44.034Z",
"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%9097873"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/766a31026ac24ed3c6cad8662058ba450c338da1"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-97873",
"datePublished": "2026-10-03T08:04:43.322Z",
"dateReserved": "2026-09-25T08:41:02.479Z",
"dateUpdated": "2026-10-05T17:00:58.750Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-18036 (GCVE-0-2026-18036)
Vulnerability from cvelistv5 – Published: 2026-10-02 07:54 – Updated: 2026-10-02 17:42
VLAI
EPSS
VEX
Title
NTRU leaks private key information by reducing secret values with a non-constant-time integer division
Summary
In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation's division-free fold and select; the results are unchanged.
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-02 17:42 UTC
CWE
- CWE-208 - Observable Timing Discrepancy
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/9c9ad88b6… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-18036",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-02T17:42:43.345821Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T17:42:56.393Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"Polynomial",
"NTRUSampling"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "The Robusta team: Deepak Bhargavan Pillai, Anirban Chakraborty, Chitchanok Chuengsatiansup, Matthew Roughan, Peter Schwabe, and Yuval Yarom"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation\u0027s division-free fold and select; the results are unchanged.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, NTRU reduced secret values with the % operator in three helpers whose reference implementations are deliberately division-free, so each reduction was carried out by an integer division whose latency depends on the secret operand. Polynomial.modQ divided by a variable divisor, which a compiler cannot strength-reduce to a multiply the way it can a constant one, so it emitted a division on every call including on the decapsulation path where the dividend derives from the private key; Polynomial.mod3 and NTRUSampling.mod3 divided the secret key polynomials f and g during key generation, the message polynomials r and m during encapsulation, and coefficients recovered during decapsulation. An attacker able to measure that timing can recover information about the NTRU private key. modQ now masks, which is exact because q is always a power of two, and mod3 uses the reference implementation\u0027s division-free fold and select; the results are unchanged."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"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:H/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-208",
"description": "CWE-208 Observable Timing Discrepancy",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T07:54:16.063Z",
"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%9018036"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/9c9ad88b6003bb6230d2434bd892cc1e95b294e4"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "NTRU leaks private key information by reducing secret values with a non-constant-time integer division",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-18036",
"datePublished": "2026-10-02T07:54:16.063Z",
"dateReserved": "2026-07-28T08:28:40.900Z",
"dateUpdated": "2026-10-02T17:42:56.393Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17508 (GCVE-0-2026-17508)
Vulnerability from cvelistv5 – Published: 2026-10-02 07:27 – Updated: 2026-10-02 17:43
VLAI
EPSS
VEX
Title
Password-based KDF cost parameters honoured unbounded from untrusted input across the remaining PBE entry points
Summary
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Severity
SSVC
Exploitation: none
Automatable: no
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-02 17:43 UTC
CWE
- CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
References
7 references
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
0 , < 1.86
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-LTS-JAVA |
Affected:
2.73.0 , < 2.73.13
(maven)
|
|
| Legion of the Bouncy Castle Inc. | BC-FJA |
Affected:
1.0.0 , < 1.0.13
(maven)
Affected: 2.0.0 , < 2.0.13 (maven) Affected: 2.1.0 , < 2.1.13 (maven) |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17508",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-02T17:43:15.561288Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T17:43:24.578Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"JcePBMac1CalculatorBuilder",
"PKCS12PBEUtils",
"JcePKCSPBEInputDecryptorProviderBuilder",
"JceOpenSSLPKCS8DecryptorProviderBuilder"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"core",
"prov"
],
"packageName": "bcprov",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"PBEPBKDF2",
"OpenSSHPrivateKeyUtil"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"pkix"
],
"packageName": "bcpkix-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"JcePBMac1CalculatorBuilder",
"PKCS12PBEUtils",
"JcePKCSPBEInputDecryptorProviderBuilder",
"JceOpenSSLPKCS8DecryptorProviderBuilder"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-lts/",
"defaultStatus": "unaffected",
"modules": [
"core",
"prov"
],
"packageName": "bcprov-lts8on",
"packageURL": "pkg:maven/org.bouncycastle/bcprov-lts8on",
"platforms": [
"all"
],
"product": "BC-LTS-JAVA",
"programFiles": [
"PBEPBKDF2",
"OpenSSHPrivateKeyUtil"
],
"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.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java-fips/",
"defaultStatus": "unaffected",
"packageName": "bcpkix-fips",
"packageURL": "pkg:maven/org.bouncycastle/bcpkix-fips",
"platforms": [
"all"
],
"product": "BC-FJA",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.0.13",
"status": "affected",
"version": "1.0.0",
"versionType": "maven"
},
{
"lessThan": "2.0.13",
"status": "affected",
"version": "2.0.0",
"versionType": "maven"
},
{
"lessThan": "2.1.13",
"status": "affected",
"version": "2.1.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Mirko Swillus on behalf of Alpha-Omega (alpha-omega.dev), using Scrutineer with an Anthropic Claude model provided through Project Glasswing"
},
{
"lang": "en",
"type": "reporter",
"value": "Yu Bao from the PayPal Cyber Security Team"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key\u0027s own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key\u0027s own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series)."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "AMBER",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "NONE",
"subIntegrityImpact": "NONE",
"userInteraction": "PASSIVE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "LOW",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770 Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T07:27:59.519Z",
"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%9017508"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/882fdab53f6c4c150a5d6a4e6ef1fc05d382385a"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/442393bf187c914b1e66fbed4fab532a1fe06c6a"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/20ed9e203caec91d25cd386ceb6d364e9b068f67"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/766a31026ac24ed3c6cad8662058ba450c338da1"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/e72bc0681ff4227fced912ef7394daf7b7d57bb3"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/480d878aa6f7dc8b20403064f304bbe0decbbb1a"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "Password-based KDF cost parameters honoured unbounded from untrusted input across the remaining PBE entry points",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-17508",
"datePublished": "2026-10-02T07:27:59.519Z",
"dateReserved": "2026-07-26T22:44:21.286Z",
"dateUpdated": "2026-10-02T17:43:24.578Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-17507 (GCVE-0-2026-17507)
Vulnerability from cvelistv5 – Published: 2026-10-02 07:26 – Updated: 2026-10-02 17:43
VLAI
EPSS
VEX
Title
MLS membership checks compare a uint32 leaf_index as signed, admitting an out-of-range sender
Summary
In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420's uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree's leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected.
Severity
SSVC
Exploitation: none
Automatable: yes
Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-10-02 17:43 UTC
CWE
- CWE-195 - Signed to Unsigned Conversion Error
Assigner
References
2 references
| URL | Tags |
|---|---|
| https://github.com/bcgit/bc-java/wiki/CVE%E2%80%9… | vendor-advisory |
| https://github.com/bcgit/bc-java/commit/1eb83471e… | patch |
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Legion of the Bouncy Castle Inc. | BC-JAVA |
Affected:
1.73 , < 1.86
(maven)
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-17507",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-02T17:43:42.891835Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T17:43:56.738Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://www.bouncycastle.org/download/bouncy-castle-java/",
"defaultStatus": "unaffected",
"modules": [
"mls"
],
"packageName": "bcmls",
"packageURL": "pkg:maven/org.bouncycastle/bcmls-jdk18on",
"platforms": [
"all"
],
"product": "BC-JAVA",
"programFiles": [
"GroupKeySet",
"Group"
],
"repo": "https://github.com/bcgit/bc-java",
"vendor": "Legion of the Bouncy Castle Inc.",
"versions": [
{
"lessThan": "1.86",
"status": "affected",
"version": "1.73",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "reporter",
"value": "Mirko Swillus on behalf of Alpha-Omega (alpha-omega.dev), using Scrutineer with an Anthropic Claude model provided through Project Glasswing"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eIn Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420\u0027s uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree\u0027s leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected.\u003c/p\u003e"
}
],
"value": "In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420\u0027s uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree\u0027s leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected."
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"attackVector": "NETWORK",
"baseScore": 8.7,
"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:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/U:Amber",
"version": "4.0",
"vulnAvailabilityImpact": "HIGH",
"vulnConfidentialityImpact": "NONE",
"vulnIntegrityImpact": "NONE",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-195",
"description": "CWE-195 Signed to Unsigned Conversion Error",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-10-02T07:26:34.739Z",
"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%9017507"
},
{
"tags": [
"patch"
],
"url": "https://github.com/bcgit/bc-java/commit/1eb83471eb01727bfdb944a5a46355cc77d55f44"
}
],
"source": {
"discovery": "EXTERNAL"
},
"title": "MLS membership checks compare a uint32 leaf_index as signed, admitting an out-of-range sender",
"x_generator": {
"engine": "bc release-notes template"
}
}
},
"cveMetadata": {
"assignerOrgId": "91579145-5d7b-4cc5-b925-a0262ff19630",
"assignerShortName": "bcorg",
"cveId": "CVE-2026-17507",
"datePublished": "2026-10-02T07:26:34.739Z",
"dateReserved": "2026-07-26T22:40:20.567Z",
"dateUpdated": "2026-10-02T17:43:56.738Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}