org.bouncycastle:bcprov-debug-lts8on 2.73.9

Direct Vulnerabilities

Known vulnerabilities in the org.bouncycastle:bcprov-debug-lts8on package. This does not include vulnerabilities belonging to this package’s dependencies.

Fix vulnerabilities automatically

Snyk's AI Trust Platform automatically finds the best upgrade path and integrates with your development workflows. Secure your code at zero cost.

Fix for free

Vulnerability	Vulnerable Version
C Improper Certificate Validation Affected versions of this package are vulnerable to Improper Certificate Validation in the `check()` method of `ProvOcspRevocationChecker`, which verifies a stapled OCSP response's signature and then treats the certificate as unrevoked when no `SingleResponse` entry matches its CertID, without requiring a binding match. An attacker can present a revoked certificate that BC-based clients accept as valid by stapling any legitimately signed OCSP response from the same CA, such as a good response for a different serial number. This applies when the client uses BC revocation checking with the response supplied through the stapled `PKIXRevocationChecker.setOcspResponses()` path rather than fetched over the network, and the response must be validly signed by the same issuer. How to fix Improper Certificate Validation? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Memory Allocation with Excessive Size Value Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in `HSSPublicKeyParameters.getInstance()` and `HSSSignature.getInstance()`, which read the HSS level count L from an encoded public key without the RFC 8554 depth cap of 8 (enforced only during key generation) and then allocate arrays sized from that attacker-controlled value. An attacker can force an allocation of roughly 17 GB, driving the verifier to `OutOfMemoryError`, by supplying an HSS public key and signature that declare an oversized level count. This requires the verifier to process attacker-supplied HSS/LMS public keys and signatures, reachable via `SubjectPublicKeyInfo`, the JCA `LMSKeyFactorySpi`/`LMSSignatureSpi`, or CMS (RFC 9708) verification. How to fix Memory Allocation with Excessive Size Value? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Improper Validation of Integrity Check Value Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value enabling MAC forgery, in the `IESEngine` class when initialized through the 4-argument `init` without a block cipher, where the KDF is seeded only from the ECDH shared secret and split into a message-length K1 keystream and a K2 MAC key, so the MAC key's position depends on the message length. An attacker can forge arbitrary authenticated ciphertexts from a single known plaintext-ciphertext pair, since K1 is an XOR keystream that reveals the prefix-stable KDF output and lets the MAC keys for shorter messages be derived. This affects only stream-mode `IESEngine` initialized with no block cipher where the ephemeral value V is empty, and requires the attacker to hold one known plaintext-ciphertext pair. How to fix Improper Validation of Integrity Check Value? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Improper Validation of Integrity Check Value Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the `processPacket()` method of `KCCMBlockCipher`, which invokes `processAAD()` only when associated data is present, so with no AAD the G1 block (nonce, length, flag) is never mixed into the MAC and the tag reduces to a CBC-MAC over the ciphertext alone, independent of the nonce. An attacker with encryption-oracle access can assemble a valid ciphertext and tag for any never-queried plaintext and nonce pair by deriving the data and tag keystreams from two nonces. This affects only DSTU 7624 CCM encryption performed without any associated data, and requires chosen-plaintext access to an encryption oracle. How to fix Improper Validation of Integrity Check Value? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Improper Validation of Integrity Check Value Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value that leads to information exposure in the `processPacket()` method of `CCMBlockCipher`, with equivalent paths in `KCCMBlockCipher` and `KGCMBlockCipher`, which decrypt directly into the caller's output buffer and leave the unverified plaintext there when the authentication tag check fails. An attacker can recover `AES-CTR(key, nonce) XOR ciphertext`, effectively reducing CCM to unauthenticated CTR, by submitting forged ciphertexts and reading the output buffer on the failure path. This requires the attacker to submit ciphertexts and observe the caller's output buffer after a failed verification, for example through pooled-buffer reuse, logging, or memory inspection. How to fix Improper Validation of Integrity Check Value? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
M Allocation of Resources Without Limits or Throttling Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the `engineLoad()` method of `BcFKSKeyStoreSpi`, which reads HMAC PBKDF2 or scrypt cost parameters from a keystore's integrity structures and runs key derivation before MAC verification, with PBKDF2 rejecting only a zero iteration count and scrypt enforcing no cost limit. An attacker can consume CPU for minutes to hours or allocate gigabytes of memory by supplying a `.bcfks` file that declares a large iteration count, up to 2^31-1, or large scrypt N/r values. This requires the application to load an attacker-supplied or modifiable `.bcfks` keystore, and the cost is incurred before the MAC mismatch is detected. How to fix Allocation of Resources Without Limits or Throttling? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Uncontrolled Recursion Affected versions of this package are vulnerable to Uncontrolled Recursion in the `force()` method of `LazyEncodedSequence`, which parses the deferred SEQUENCE with a fresh `ASN1InputStream` whose nesting-depth counter is reset rather than inherited from the parent parse, and never calls `createSubStream()` or `decrementDepth()`. An attacker can crash the handling thread with a `StackOverflowError` by supplying a 40-50 KB DER-encoded CRL whose `revokedCertificates` field nests roughly 10,000 SEQUENCE structures. This requires the application to parse the CRL through `X509CRLHolder` or the BC `CertificateFactory` path, where `revokedCertificates` is held as an unevaluated lazy sequence until forced. How to fix Uncontrolled Recursion? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
M Allocation of Resources Without Limits or Throttling Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in `PKCS12KeyStoreSpi`, which feeds the attacker-controlled KDF iteration count from a PKCS#12 file's MAC data and encrypted bags into key derivation during `engineLoad()` without enforcing any upper bound. An attacker can pin a CPU core for an extended period and exhaust server resources by supplying a PKCS#12 keystore whose MAC or bag PBE parameters declare a very large iteration count, up to 2^31-1. This requires the application to load the attacker-supplied keystore, and the costly derivation runs during MAC verification and bag decryption regardless of whether the supplied password matches. How to fix Allocation of Resources Without Limits or Throttling? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Memory Allocation with Excessive Size Value Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the `toByteArray()` method of `DefiniteLengthInputStream`, which allocates `new byte[(int)_remaining]` up front from the declared ASN.1 definite-length value before reading any content. An attacker can drive the JVM to `OutOfMemoryError` with a small input by supplying an ASN.1 structure whose definite-length header declares a near-heap-sized length that the content never satisfies. This requires the application to parse attacker-supplied ASN.1 or DER input, such as certificates, CMS structures, or keys, through Bouncy Castle. How to fix Memory Allocation with Excessive Size Value? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Inefficient Algorithmic Complexity Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity in the `IETFUtils.valueToString()` method, reached through `X500Name.toString()`, `equals()`, and `hashCode()` via `AbstractX500NameStyle`, which escapes each special character with `vBuf.insert(index, "\\")` on the same buffer so a value of N escapable bytes costs roughly N²/2 character moves. An attacker can pin a CPU core for seconds to minutes, and saturate the server with a few parallel submissions, by supplying an X.509 certificate, CSR, CRL, or CMS structure containing a single ~60 KB RDN of commas or plus signs. Exploitation only requires a code path that logs, pretty-prints, compares, or hashes the resulting `X500Name`, including JCA `X509Certificate.getSubjectX500Principal().toString()` and BC certificate selectors and caches. How to fix Inefficient Algorithmic Complexity? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Improper Verification of Cryptographic Signature Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature in the `verifySignature()` method of `RSADigestSigner`, whose legacy NULL-omitted `DigestInfo` path computes comparison offsets as `length - hash.length - 2`, so its two comparison loops jointly cover only bytes `[0..sig.length-2)` and leave the final two hash bytes unverified. An attacker can forge an RSA PKCS#1 signature by producing a message whose digest matches the signed digest in every byte except the last two, reducing the second-preimage work factor by 2^16. The flawed path is reachable by default only for signatures using NULL-less `DigestInfo` encoding, across BC-lightweight TLS `rsa_pkcs1_*`, PKIX/CMS, and OpenPGP RSA verification, and only when `org.bouncycastle.pkcs1.strict_digestinfo` is not set. How to fix Improper Verification of Cryptographic Signature? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
C Improper Input Validation Affected versions of this package are vulnerable to Improper Input Validation in the `calculateAgreement(pub, message)` method of the `DHAgreement` class, which raises the peer-supplied `message` to the power of the local static private key `x` without any range or subgroup-membership check, while only the `pub` parameter is validated through `DHPublicKeyParameters`. A malicious peer can recover the full static private key by repeatedly sending small-order elements (`0`, `1`, `p-1`, or elements of small subgroups) as `message`, since each exchange leaks the key modulo a small prime and the values combine via the Chinese Remainder Theorem. This affects only the MTI/A0 two-pass `DHAgreement` variant and not `DHBasicAgreement`, and it requires the application to reuse a static Diffie-Hellman private key across exchanges. How to fix Improper Input Validation? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
C Improper Certificate Validation Affected versions of this package are vulnerable to Improper Certificate Validation in the `isEmailConstrained()` and `isURIConstrained()` methods of `PKIXNameConstraintValidator`, which compare `rfc822Name` and URI subjectAltName values with a bare `equalsIgnoreCase()` and do not strip a trailing dot the way the `dNSName` path does. An attacker who controls a name-constrained intermediate CA can issue certificates for email and URI hosts that an `excludedSubtrees` constraint was meant to block, for example `ceo@bank.com.` against an exclusion of `bank.com`, by appending a trailing dot so the value no longer matches the constraint. This affects only the email and URI constraint paths and not `dNSName`, and it requires a relying party to validate certificate paths through this validator with name constraints in force. How to fix Improper Certificate Validation? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Inadequate Encryption Strength Affected versions of this package are vulnerable to Inadequate Encryption Strength in the `BcKeyStoreSpi.engineLoad()` method, which for legacy BKS keystore versions 0 and 1 passes `hMac.getMacSize()` (20 bytes for SHA-1) to `generateDerivedMacParameters()`, where `PKCS12ParametersGenerator` divides it by 8 and yields a 16-bit MAC key. An attacker with access to a `.bks` file can brute-force the 2^16 possible keys offline and produce a valid MAC over a modified store, for example injecting a rogue trusted CA, by setting the file's version integer to a legacy value that reaches the weak-key branch. This requires the attacker to supply or modify a `.bks` keystore that the application loads, and the `org.bouncycastle.bks.enable_v1` property does not gate this path because the default BKS type reaches the weak derivation in `engineLoad()` regardless. How to fix Inadequate Encryption Strength? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)
H Memory Allocation with Excessive Size Value Affected versions of this package are vulnerable to Memory Allocation with Excessive Size Value in the `BcKeyStoreSpi.engineLoad()` method, which sizes buffers for the certificate chain array, encoded certificates, encoded key material, entry data, and PBE salts directly from `readInt()` length fields before the trailing HMAC integrity check runs. An attacker can exhaust memory and trigger an `OutOfMemoryError` in the process loading a keystore by supplying a BKS or UBER keystore file whose length fields are set to `0x7FFFFFFF`, forcing allocation attempts of roughly 2 GB each. This requires the application to load an attacker-supplied or attacker-modified keystore of the BKS or UBER type. How to fix Memory Allocation with Excessive Size Value? Upgrade `org.bouncycastle:bcprov-debug-lts8on` to version 2.73.12 or higher.	[,2.73.12)

Vulnerability

Vulnerable Version

Improper Certificate Validation

Affected versions of this package are vulnerable to Improper Certificate Validation in the check() method of ProvOcspRevocationChecker, which verifies a stapled OCSP response's signature and then treats the certificate as unrevoked when no SingleResponse entry matches its CertID, without requiring a binding match. An attacker can present a revoked certificate that BC-based clients accept as valid by stapling any legitimately signed OCSP response from the same CA, such as a good response for a different serial number. This applies when the client uses BC revocation checking with the response supplied through the stapled PKIXRevocationChecker.setOcspResponses() path rather than fetched over the network, and the response must be validly signed by the same issuer.

How to fix Improper Certificate Validation?