Find, fix and prevent vulnerabilities in your code.

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound in the findDirectByteBufferFrameCompressedSize, decompressedDirectByteBufferSize, and getDirectByteBufferFrameContentSize native handlers in src/main/native/jni_zstd.c. An attacker can crash the JVM or trigger an out-of-bounds read by supplying crafted src_offset and src_size values to these direct ByteBuffer frame-size queries, including values near Integer.MIN_VALUE that wrap the 32-bit arithmetic used in the capacity check.

Remediation

Upgrade com.github.luben:zstd-jni to version 1.5.7-14 or higher.

References

• GitHub Commit
• Maintainer's Advisory
• Vulnerable Code
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Out-of-bounds Read due to the ZstdDictCompress(byte[] dict, int offset, int length, int level) constructor in ZstdDictCompress.java. An attacker can trigger a native heap read, crash the JVM, or leak adjacent memory by supplying a negative offset or an oversized length when constructing a compression dictionary from untrusted input.

Remediation

Upgrade com.github.luben:zstd-jni to version 1.5.7-14 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to Out-of-bounds Read through the ZstdDictDecompress(byte[] dict, int offset, int length) constructor in src/main/java/com/github/luben/zstd/ZstdDictDecompress.java. An attacker can read past the end of the supplied dictionary array by providing arbitrary offset or length values when constructing a decompression dictionary. This can expose adjacent JVM memory contents and, in affected deployments, terminate the JVM when the native code consumes the invalid range.

Remediation

Upgrade com.github.luben:zstd-jni to version 1.5.7-14 or higher.

References

• GitHub Commit
• GitHub Issue
• Vulnerable Code
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Out-of-bounds Read through Zstd.trainFromBufferDirect0 in src/main/native/jni_zdict.c. An attacker can crash the JVM by supplying a direct samples buffer with an oversized sampleSizes array whose total length exceeds the buffer’s actual capacity. The native dictionary trainer passes the caller-provided lengths to ZDICT_trainFromBuffer without checking that they fit within the direct buffer, so it reads past the end of the sample data and can terminate applications that train dictionaries from untrusted input.

Remediation

Upgrade com.github.luben:zstd-jni to version 1.5.7-14 or higher.

References

• GitHub Commit
• Maintainer's Advisory
• Vulnerable Code
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Improper Certificate Validation. PKIXCertPathReviewer.checkNameConstraints() in org.bouncycastle.pkix.jcajce.PKIXCertPathReviewer and org.bouncycastle.x509.PKIXCertPathReviewer. An attacker can get a constrained certificate chain accepted by supplying a leaf certificate whose subject DN or subjectAltName violates the issuing CA’s NameConstraints extension. When an application relies on the reviewer’s isValidCertPath() result for trust decisions, it accepts an end-entity certificate that the CA was not authorized to issue, allowing unauthorized certificate acceptance.

Remediation

Upgrade org.bouncycastle:bcpkix-jdk18on to version 1.86 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the getContentStream() method of RecipientInformation, which, when authenticated attributes are present, authenticates only the DER-encoded authAttrs and never checks the computed content digest against the messageDigest attribute required by RFC 5652 section 9.3. An attacker who intercepts a CMS AuthenticatedData message can substitute arbitrary content that still passes verification by replacing encapContentInfo.eContent while leaving authAttrs and the MAC untouched. This applies when the message carries authenticated attributes and the application follows the documented pattern of comparing only ad.getMac() to recipient.getMac() without separately validating the content digest.

Remediation

Upgrade org.bouncycastle:bcpkix-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in CMS AuthEnvelopedData recipient processing, where AbstractRecipient and its recipient classes (such as JceKeyTransRecipient and BcKeyTransRecipient) take the AEAD tag length from the attacker-controlled GCM or CCM ICV length in the content AlgorithmIdentifier without a minimum-length check. An attacker can reduce the authentication tag to a length that makes forgery tractable by setting that MAC length to a small value such as 32 bits, so the recipient verifies against a short tag. The forged message must still verify against the shortened tag, so this enables a feasible brute-force forgery rather than an immediate bypass, and it affects applications decrypting AuthEnvelopedData with no configured minimum tag size.

Remediation

Upgrade org.bouncycastle:bcpkix-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Improper Validation of Integrity Check Value in the CMSAuthenticatedDataParser process. An attacker can cause unauthorized attribute injection by crafting a message where the digestAlgorithm field is absent but authAttrs is present, allowing the insertion of arbitrary authenticated attributes that are not covered by the MAC. This can lead to applications making authorization, routing, or labeling decisions based on attacker-controlled values.

Remediation

Upgrade org.bouncycastle:bcpkix-jdk18on to version 1.86 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Improper Verification of Cryptographic Signature in the CMSSignedData.verifySignatures(SignerInformationVerifierProvider, boolean) method, which iterates the signer set and returns true on loop completion without checking that any signer is present. An attacker can have completely unsigned content accepted as authentic by submitting a degenerate CMS or PKCS#7 SignedData that carries arbitrary content with an empty signerInfos set, which RFC 5652 permits. This affects applications that treat the true return value as proof of authenticity without separately asserting that an expected signer is present.

Remediation

Upgrade org.bouncycastle:bcpkix-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

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.

Workaround

This vulnerability can be avoided by setting the system property org.bouncycastle.pkcs1.strict_digestinfo, which enforces strict DigestInfo parsing and rejects the NULL-omitted encoding that reaches the flawed path.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Use of a Broken or Risky Cryptographic Algorithm due to the generateCTR process in G3413CTRBlockCipher. An attacker can recover relationships between encrypted plaintext blocks by driving the cipher past its counter range and causing the counter to wrap, which makes the stream repeat and produces identical ciphertext for different blocks. This breaks the confidentiality of data protected with G3413CTRBlockCipher and can expose plaintext patterns or allow plaintext recovery when the same key and IV are reused across enough blocks.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.84 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Uncontrolled Recursion in the OERInputStream.parse(Element) method, which processes the SEQ, CHOICE, and Supplier children of an IEEE 1609.2 structure recursively without enforcing a depth limit. An attacker can crash the parsing thread or the JVM with a StackOverflowError by supplying a roughly 2 to 4 KB IEEE 1609.2 message containing hundreds of nested signedData payloads to the ETSISignedData(byte[]) or ETSIEncryptedData(byte[]) entry points, which parse untrusted input before signature verification. Exploitation reaches the recursion pre-verification because the schema's self-referential mayRecurse cycle (Ieee1609Dot2Data back to itself) is only validated in test tooling, not at runtime, so it requires only that the application pass untrusted IEEE 1609.2 data to those entry points.

Remediation

Upgrade org.bouncycastle:bcutil-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Out-of-bounds Write via the Snappy.uncompress(ByteBuffer, ByteBuffer) method in org/xerial/snappy/Snappy.java. An attacker can trigger JVM termination by supplying valid compressed input that expands beyond the destination ByteBuffer capacity. The vulnerable code does not validate the output buffer size against the decompressed size, so writes past the buffer boundary occur during decompression, crashing applications that process attacker-controlled Snappy data.

Remediation

Upgrade org.xerial.snappy:snappy-java to version 1.1.10.10 or higher.

References

• GitHub Issue
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Out-of-bounds Write via the Snappy.compress function. An attacker can cause memory corruption and force the Java Virtual Machine to terminate by providing incompressible data that exceeds the remaining capacity of the destination buffer.

Remediation

Upgrade org.xerial.snappy:snappy-java to version 1.1.10.9 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub PR
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to NULL Pointer Dereference and out-of-bounds read in the native XXHash implementations reached through XXHashFactory.nativeInstance(), where SafeUtils.checkRange() skips all array validation when len == 0 and lets invalid references or ranges reach the JNI code. An attacker can crash the JVM, and expose in-process memory before the crash, by passing a null array with zero length or an oversized length to the native hash32(), hash64(), or streaming update() methods, which then read outside the array bounds in native code. Exploitation requires the application to let the attacker influence the array reference or the offset and length arguments to a native XXHash call, not merely the contents of a valid array, and only the native JNI instances are affected.

Workaround

This vulnerability can be avoided by using XXHashFactory.safeInstance() instead of nativeInstance(), which computes the hash in pure Java and never crosses the JNI boundary where the flaw occurs.

Remediation

Upgrade at.yawk.lz4:lz4-java to version 1.11.1 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release

Overview

Affected versions of this package are vulnerable to XML External Entity (XXE) Injection via the toXmlDocument function of XmlStringPrettyFormatter. An attacker can read arbitrary local files, perform server-side request forgery, or cause denial of service by providing crafted XML input containing external entities.

Note: This formatter is used by isXmlEqualTo(CharSequence) and xmlPrettyFormat(String) and could be exploited if untrusted XML input is processed by the methods.

Workaround

Replace use of isXmlEqualTo(CharSequence) with XMLUnit.

Details

XXE Injection is a type of attack against an application that parses XML input. XML is a markup language that defines a set of rules for encoding documents in a format that is both human-readable and machine-readable. By default, many XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing. When an XML document is being parsed, the parser can make a request and include the content at the specified URI inside of the XML document.

Attacks can include disclosing local files, which may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier.

For example, below is a sample XML document, containing an XML element- username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
   <username>John</username>
</xml>

An external XML entity - xxe, is defined using a system identifier and present within a DOCTYPE header. These entities can access local or remote content. For example the below code contains an external XML entity that would fetch the content of /etc/passwd and display it to the user rendered by username.

<xml>
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
   <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
   <username>&xxe;</username>
</xml>

Other XXE Injection attacks can access local resources that may not stop returning data, possibly impacting application availability and leading to Denial of Service.

Remediation

Upgrade org.assertj:assertj-core to version 3.27.7 or higher.

References

• GitHub Commit
• GitHub Release

Overview

Affected versions of this package are vulnerable to Timing Attack through the sample and sample_matrix functions in FrodoEngine.java. An attacker can recover information about the sampled noise values by observing how long Frodo key generation or encapsulation takes when it processes attacker-influenced inputs. The variable-time comparison and sign handling in the error sampler leak the distribution of the generated samples, weakening the secrecy of the private Frodo noise and enabling key-recovery attacks against affected deployments.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.84 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Timing Attack through the mod3 and modQ reduction helpers in org.bouncycastle.pqc.math.ntru.Polynomial and org.bouncycastle.pqc.crypto.ntru.NTRUSampling. An attacker can recover information about NTRU private key material by measuring the latency of secret-dependent modular reductions during key generation, encapsulation, and decapsulation.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.86 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

org.apache.commons:commons-compress is an API for working with compression and archive formats.

Affected versions of this package are vulnerable to Infinite loop due to the improper handling of certain inputs during the parsing of dump files. An attacker can cause the application to enter an infinite loop by supplying crafted inputs.

Remediation

Upgrade org.apache.commons:commons-compress to version 1.26.0 or higher.

References

• Apache Lists
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Insecure Temporary File in the process that extracts and loads the native library via net.jpountz.util.Native.load. An attacker can execute arbitrary code by pre-creating a malicious file in a shared temporary directory, causing the victim process to load attacker-controlled code. This is only exploitable if the temporary directory is shared and writable by multiple users, and system protections such as fs.protected_regular or fs.protected_symlinks are not enabled, or if the temporary directory lacks the sticky bit or is shared across users in containers.

Remediation

Upgrade at.yawk.lz4:lz4-java to version 1.11.4 or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through repeated allocation of large buffers in the LZ4FrameInputStream.readHeader process. An attacker can cause excessive CPU and garbage collection usage by providing specially crafted input consisting of many minimal empty frames, leading to significant resource consumption relative to the input size.

Remediation

Upgrade at.yawk.lz4:lz4-java to version 1.11.4 or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

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.

Remediation

Upgrade org.bouncycastle:bcprov-jdk18on to version 1.85 or higher.

References

• GitHub Commit
• GitHub Wiki

Overview

Affected versions of this package are vulnerable to Use After Free through the dictionary handling in ZstdInputStreamNoFinalizer, ZstdOutputStreamNoFinalizer, ZstdCompressCtx, and ZstdDecompressCtx. An attacker can trigger native memory corruption or a JVM crash by closing a compression or decompression dictionary after it has been attached to a stream or context and then continuing to call read() or write() on that object. The vulnerable code releases the dictionary’s shared lock immediately after the native load call, while the stream or context still keeps a raw reference to the freed native dictionary. This leaves later compression or decompression operations using dangling dictionary state, which can produce silent data corruption or abort the Java process.

Remediation

Upgrade com.github.luben:zstd-jni to version 1.5.7-14 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• Vulnerable Code
• Vulnerable Code

Overview

Affected versions of this package are vulnerable to Use After Free in the setDict, setLongMax, setLevel, and setRefMultipleDDicts methods of its streaming classes. An attacker can corrupt native heap state or crash the JVM by calling these setters on a stream after close(), causing them to write through a freed native context handle. The vulnerable code lives in BaseZstdBufferDecompressingStreamNoFinalizer, ZstdInputStreamNoFinalizer, and ZstdOutputStreamNoFinalizer, where these post-close setters still pass the stale native pointer into zstd's dictionary and parameter-loading routines. In applications that reuse or retain stream objects across lifecycle boundaries, the resulting write can alter an unrelated live native object or trigger a JVM crash.

Remediation

Upgrade com.github.luben:zstd-jni to version 1.5.7-14 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• Maintainer's Advisory
• Vulnerable Code
• Vulnerable Code