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

org.apache.tomcat.embed:tomcat-embed-core is a Core Tomcat implementation.

Affected versions of this package are vulnerable to Improper Authentication in the EncryptionInterceptor process of the cluster component. An attacker can gain unauthorized access or perform unauthorized actions by replaying previously captured authentication data.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 9.0.119, 10.1.56, 11.0.23 or higher.

References

• Apache Mailing List
• Apache Tomcat Advisory
• Apache Tomcat Advisory
• GitHub Commit
• GitHub Commit
• GitHub Commit

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 Allocation of Resources Without Limits or Throttling via the W3CBaggagePropagator() function. An attacker can cause excessive memory allocation and CPU consumption by sending oversized baggage data, which is automatically re-injected into every outgoing request and can impact downstream services.

Remediation

Upgrade io.opentelemetry:opentelemetry-api to version 1.62.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR
• GitHub Release

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the W3CBaggagePropagator() function. An attacker can cause excessive memory allocation and CPU consumption by sending oversized baggage data, which is automatically re-injected into every outgoing request and can impact downstream services.

Remediation

Upgrade io.opentelemetry:opentelemetry-extension-trace-propagators to version 1.62.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR
• GitHub Release

Overview

org.apache.tomcat.embed:tomcat-embed-core is a Core Tomcat implementation.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the HTTP/2 backlog tracking when a stream is reset. An attacker can exhaust system resources by repeatedly resetting streams, leading to service disruption.

Note: This issue was fixed in Apache Tomcat 10.1.58 but the release vote for the 10.1.58 release candidate did not pass. Therefore, although users must download 10.1.59 to obtain a version that includes a fix for this issue, version 10.1.58 is not included in the list of affected versions.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 9.0.121, 10.1.59, 11.0.25 or higher.

References

• Apache Mailing List
• GitHub Commit

Overview

org.apache.tomcat.embed:tomcat-embed-core is a Core Tomcat implementation.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the AjpProcessor in the AJP connector. An unauthenticated attacker can pin an AJP processing thread and cause denial of service by triggering an error response for an AJP request that declares or expects a body but does not provide it; while finishing the response, the processor waits to consume the unread body.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 9.0.122, 10.1.59, 11.0.26 or higher.

References

• Apache Security Advisory
• GitHub Commit
• GitHub Commit 10.1.60
• GitHub Commit 11.0.26
• GitHub Commit 9.0.122

Overview

org.apache.tomcat.embed:tomcat-embed-core is a Core Tomcat implementation.

Affected versions of this package are vulnerable to Authentication Bypass by Primary Weakness in the authentication process when using certain authentication mechanisms such as CLIENT-CERT or SPNEGO. An attacker can gain unauthorized access by authenticating with credentials that do not correspond to a valid user in the DataSourceRealm.

Note: This issue was fixed in Apache Tomcat 10.1.58 but the release vote for the 10.1.58 release candidate did not pass. Therefore, although users must download 10.1.59 to obtain a version that includes a fix for this issue, version 10.1.58 is not included in the list of affected versions.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 9.0.121, 10.1.59, 11.0.25 or higher.

References

• Apache Mailing List
• GitHub Commit

Overview

org.apache.tomcat.embed:tomcat-embed-core is a Core Tomcat implementation.

Affected versions of this package are vulnerable to Detection of Error Condition Without Action due to improper handling of invalid certificate revocation list (CRL) configurations in the FFM connector. An attacker can bypass intended certificate validation by supplying an invalid CRL configuration.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 9.0.119, 10.1.56, 11.0.23 or higher.

References

• Apache Mailing List
• Apache Tomcat Advisory
• Apache Tomcat Advisory
• Apache Tomcat Advisory
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

org.apache.tomcat.embed:tomcat-embed-core is a Core Tomcat implementation.

Affected versions of this package are vulnerable to Off-by-one Error in chain-rule handling due to the rule-skipping logic in java/org/apache/catalina/valves/rewrite/RewriteValve.java. An attacker can cause rewrite processing to apply the wrong rule by supplying a request that triggers a failing [C] chain, which incorrectly skips the terminal rule and resumes at the second rule instead of the first. This can rewrite a request to an unintended target path, breaking expected URL routing and letting crafted requests bypass the intended rewrite sequence.

Notes

• The issue was fixed in Apache Tomcat 10.1.58, but the release vote for the 10.1.58 release candidate did not pass. Therefore, although users must download 10.1.59 to obtain a version that includes a fix for this issue, version 10.1.58 is not included in the list of affected versions.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-core to version 9.0.121, 10.1.59, 11.0.25 or higher.

References

• Apache Security Advisory
• GitHub Commit 10.1.58
• GitHub Commit 11.0.25
• GitHub Commit 9.0.121

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) via busy wait during WebSocket close.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-websocket to version 9.0.121, 10.1.59, 11.0.25 or higher.

References

• Apache Mailing List
• Apache Tomcat Advisory
• Apache Tomcat Advisory
• Apache Tomcat Advisory
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Missing Release of Resource after Effective Lifetime through the WebSocket write timeout handling in org.apache.tomcat.websocket.WsRemoteEndpointImplBase, WsRemoteEndpointImplClient, WsRemoteEndpointImplServer, and MessagePart. An attacker can keep asynchronous WebSocket sends from timing out by sending message fragments or consecutive writes that reuse the same timeout, causing the timeout state to be lost during write processing. When this happens, the server can keep waiting on stalled WebSocket writes instead of aborting them, tying up resources and eventually preventing the application from serving other requests.

Remediation

Upgrade org.apache.tomcat.embed:tomcat-embed-websocket to version 11.0.26, 10.1.60, 9.0.122 or higher.

References

• Apache Security Advisory
• GitHub Commit 10.1.60
• GitHub Commit 11.0.26
• GitHub Commit 9.0.122

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 Memory Allocation with Excessive Size Value through the Snappy.uncompressedLength and decompression paths in Snappy.java and SnappyFramedInputStream. An attacker can exhaust JVM memory by supplying a crafted compressed payload that advertises a huge uncompressed size, causing Snappy.uncompress, Snappy.uncompressString, array decompression helpers, or framed stream decompression to allocate an oversized output buffer before validating the length. This can trigger OutOfMemoryError or a NegativeArraySizeException from only a few bytes of attacker-controlled input. The result is denial of service for applications that accept untrusted Snappy-compressed data.

Workarounds

• Before decompressing untrusted data, call Snappy.uncompressedLength(input) and reject inputs whose declared uncompressed length exceeds an application-specific maximum; this prevents attacker-supplied payloads from forcing oversized JVM allocations during Snappy decompression.

Remediation

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

References

• GitHub Commit
• GitHub Issue
• GitHub Issue
• GitHub Issue
• Maintainer's Advisory

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 Allocation of Resources Without Limits or Throttling in which the non-blocking async JSON parser can be made to bypass the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. An attacker can cause excessive memory allocation and CPU exhaustion by submitting JSON documents containing extremely long numeric values through the asynchronous parser interface.

PoC

The following JUnit 5 test demonstrates the vulnerability. It shows that the async parser accepts a 5,000-digit number, whereas the limit should be 1,000.

package tools.jackson.core.unittest.dos;

import java.nio.charset.StandardCharsets;

import org.junit.jupiter.api.Test;

import tools.jackson.core.*;
import tools.jackson.core.exc.StreamConstraintsException;
import tools.jackson.core.json.JsonFactory;
import tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;

import static org.junit.jupiter.api.Assertions.*;

/**
 * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers
 *
 * Authors: sprabhav7, rohan-repos
 * 
 * maxNumberLength default = 1000 characters (digits).
 * A number with more than 1000 digits should be rejected by any parser.
 *
 * BUG: The async parser never calls resetInt()/resetFloat() which is where
 * validateIntegerLength()/validateFPLength() lives. Instead it calls
 * _valueComplete() which skips all number length validation.
 *
 * CWE-770: Allocation of Resources Without Limits or Throttling
 */
class AsyncParserNumberLengthBypassTest {

    private static final int MAX_NUMBER_LENGTH = 1000;
    private static final int TEST_NUMBER_LENGTH = 5000;

    private final JsonFactory factory = new JsonFactory();

    // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength
    @Test
    void syncParserRejectsLongNumber() throws Exception {
        byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);
        
        // Output to console
        System.out.println("[SYNC] Parsing " + TEST_NUMBER_LENGTH + "-digit number (limit: " + MAX_NUMBER_LENGTH + ")");
        try {
            try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {
                while (p.nextToken() != null) {
                    if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
                        System.out.println("[SYNC] Accepted number with " + p.getText().length() + " digits — UNEXPECTED");
                    }
                }
            }
            fail("Sync parser must reject a " + TEST_NUMBER_LENGTH + "-digit number");
        } catch (StreamConstraintsException e) {
            System.out.println("[SYNC] Rejected with StreamConstraintsException: " + e.getMessage());
        }
    }

    // VULNERABILITY: Async parser accepts the SAME number that sync rejects
    @Test
    void asyncParserAcceptsLongNumber() throws Exception {
        byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);

        NonBlockingByteArrayJsonParser p =
            (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());
        p.feedInput(payload, 0, payload.length);
        p.endOfInput();

        boolean foundNumber = false;
        try {
            while (p.nextToken() != null) {
                if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {
                    foundNumber = true;
                    String numberText = p.getText();
                    assertEquals(TEST_NUMBER_LENGTH, numberText.length(),
                        "Async parser silently accepted all " + TEST_NUMBER_LENGTH + " digits");
                }
            }
            // Output to console
            System.out.println("[ASYNC INT] Accepted number with " + TEST_NUMBER_LENGTH + " digits — BUG CONFIRMED");
            assertTrue(foundNumber, "Parser should have produced a VALUE_NUMBER_INT token");
        } catch (StreamConstraintsException e) {
            fail("Bug is fixed — async parser now correctly rejects long numbers: " + e.getMessage());
        }
        p.close();
    }

    private byte[] buildPayloadWithLongInteger(int numDigits) {
        StringBuilder sb = new StringBuilder(numDigits + 10);
        sb.append("{\"v\":");
        for (int i = 0; i < numDigits; i++) {
            sb.append((char) ('1' + (i % 9)));
        }
        sb.append('}');
        return sb.toString().getBytes(StandardCharsets.UTF_8);
    }
}

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade tools.jackson.core:jackson-core to version 3.1.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the enforcement of document length constraints in blocking, async, and DataInput parser processes. An attacker can cause excessive resource consumption by submitting oversized JSON documents that bypass configured size limits.

Remediation

Upgrade tools.jackson.core:jackson-core to version 3.1.1 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the NonBlockingUtf8JsonParserBase file. An attacker can exhaust system memory by streaming JSON input in small chunks to the asynchronous parser, causing unbounded accumulation of digit characters in memory due to missing validation of number length during chunked parsing. This can lead to denial of service by overwhelming the application's memory resources.

Remediation

Upgrade tools.jackson.core:jackson-core to version 3.1.4 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub PR

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the _reportInvalidToken(int, String, String) method of UTF8DataInputJsonParser, which accumulates invalid token characters into a StringBuilder with no check against ErrorReportConfiguration.getMaxErrorTokenLength(), unlike UTF8StreamJsonParser, ReaderBasedJsonParser, and NonBlockingUtf8JsonParserBase, which enforce the 256-character default. An attacker can exhaust the JVM heap by submitting a sufficiently long malformed token, since the whole token is copied into the exception message, where a 20-million-character token produces a 20,000,109-character message against 367 characters on the bounded path. This requires the application to create its parser through JsonFactory.createParser(DataInput), and no configuration constrains the path, since maxDocumentLength does not apply to DataInput sources and maxStringLength does not cover it.

Remediation

Upgrade tools.jackson.core:jackson-core to version 3.1.7, 3.2.3 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) due to delayed enforcement of maximum property name length in the ReaderBasedJsonParser process. An attacker can exhaust system memory and cause a crash by submitting a JSON object with an excessively long property name via character-based input sources such as String, Reader, or char[]. This is only exploitable if untrusted JSON is parsed from character-based sources rather than raw UTF-8 bytes.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade tools.jackson.core:jackson-core to version 3.1.6, 3.2.2 or higher.

References

• GitHub Advisory
• github.com
• github.com
• GitHub Commit
• GitHub PR

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the CoreXMLDeserializers.Std._deserialize path in src/main/java/com/fasterxml/jackson/databind/ext/CoreXMLDeserializers.java. An attacker can consume excessive CPU by supplying a JSON string bound to a javax.xml.datatype.Duration or XMLGregorianCalendar field, causing DatatypeFactory.newDuration(value) or newXMLGregorianCalendar(value) to parse arbitrarily long numeric components. This stalls the request-handling thread and can exhaust server CPU under default deserialization settings, denying service to other users.

Remediation

Upgrade tools.jackson.core:jackson-databind to version 3.1.6, 3.2.2 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the resolveForwardReference() method of CollectionDeserializer.CollectionReferringAccumulator, and in the corresponding map accumulators, which perform a linear search of the pending accumulator for every resolved object ID. An attacker can consume quadratic CPU and exhaust a request-time or worker-capacity budget by submitting JSON whose N unresolved object-ID references resolve in reverse order, costing roughly N*(N+1)/2 comparisons, measured at 2,003,000 for N=2,000. This requires the application to deserialize attacker-influenced JSON into an identity-enabled collection or map under @JsonIdentityInfo, though it needs no deep nesting or unusual JSON syntax.

Remediation

Upgrade tools.jackson.core:jackson-databind to version 3.1.7, 3.2.3 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Issue

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 in the createParserFactory and createDocumentBuilderFactory methods of the XmlFactory class, which set only XMLConstants.FEATURE_SECURE_PROCESSING on the factory and leave disallow-doctype-decl, external-general-entities, external-parameter-entities, and load-external-dtd at their defaults. An attacker can read local files out of band by submitting XML containing an external entity declaration to an application that unmarshals untrusted documents. Exploitation depends on the JAXP implementation in use, because secure processing alone does not block external entity resolution on every implementation.

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

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• GitHub Commit
• GitHub PR
• GitLab Work Item

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the SimpleEvaluationContext file when the SpEL expression compiler is enabled through specific configuration settings. An attacker can cause unbounded class-loading growth and bypass enforced safety checks by submitting specially crafted expressions for evaluation.

Note: This is only exploitable if the application evaluates SpEL expressions using SimpleEvaluationContext and the SpEL expression compiler is active via the spring.expression.compiler.mode property or a SpelParserConfiguration set to IMMEDIATE or MIXED.

Remediation

Upgrade org.springframework:spring-expression to version 7.0.9 or higher.

References

• Spring Security Advisory

Overview

org.springframework:spring-web is a package that provides a comprehensive programming and configuration model for modern Java-based enterprise applications - on any kind of deployment platform.

Affected versions of this package are vulnerable to Sensitive Cookie in HTTPS Session Without "Secure" Attribute in the JettyCoreServerHttpResponse file. An attacker can compromise user session integrity by exploiting the omission of the sameSite attribute in serialized response cookies, potentially enabling cross-site request forgery (CSRF) attacks when a user interacts with a malicious website.

Remediation

Upgrade org.springframework:spring-web to version 7.0.9 or higher.

References

• GitHub Commit
• Spring Security Advisory

Overview

com.google.guava:guava is a set of core libraries that includes new collection types (such as multimap and multiset,immutable collections, a graph library, functional types, an in-memory cache and more.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the readObject deserialization paths in CompactHashMap, CompactHashSet, and MapMakerInternalMap. An attacker can crash a Java process with an OutOfMemoryError by supplying a crafted serialized stream that declares an oversized element count or initial capacity. During deserialization, CompactHashMap and CompactHashSet use the attacker-controlled size to initialize their backing storage, and MapMakerInternalMap propagates the attacker-controlled size into segment table allocation, letting a tiny payload force a much larger heap allocation.

Remediation

Upgrade com.google.guava:guava to version 33.7.2, 33.7.2-jre or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Issue
• GitHub Issue
• Maintainer's Advisory

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in the Flux.windowTimeout function when fairBackpressure is enabled. An attacker can cause the stream to hang indefinitely and exhaust system resources by maintaining long-lived connections and manipulating downstream read speeds.

Remediation

Upgrade io.projectreactor:reactor-core to version 3.8.7 or higher.

References

• Spring Security Advisory

Overview

Affected versions of this package are vulnerable to Race Condition in the Flux.bufferTimeout process with fairBackpressure enabled when a race condition occurs between flushing buffered items and the arrival of new upstream items. An attacker can cause the stream to hang indefinitely and exhaust resources by manipulating the timing of upstream item delivery to trigger this race condition.

Remediation

Upgrade io.projectreactor:reactor-core to version 3.8.7 or higher.

References

• Spring Security Advisory

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.postgresql:postgresql is a Java JDBC 4.2 (JRE 8+) driver for PostgreSQL database.

Affected versions of this package are vulnerable to Incorrect Implementation of Authentication Algorithm in the ScramAuthenticator class, which fails open by confirming only that the server advertised a -PLUS mechanism while neither rejecting an empty channel binding nor verifying that the negotiated mechanism actually uses channel binding. An attacker intercepting the TLS connection can strip the MitM protection that channelBinding=require is meant to guarantee, downgrading authentication from SCRAM-SHA-256-PLUS to plain SCRAM-SHA-256, by presenting a certificate with a signature algorithm such as Ed25519, Ed448, or a post-quantum scheme that makes the bundled scram-client return an empty binding instead of failing. This affects only connections that explicitly set channelBinding=require, since the default prefer policy documents fallback as expected behavior.

Workaround

This vulnerability can be avoided by configuring the connection with sslmode=verify-full and a restrictive truststore, which provides equivalent MitM protection independent of channel binding.

Remediation

Upgrade org.postgresql:postgresql to version 42.7.12 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release

Overview

org.postgresql:postgresql is a Java JDBC 4.2 (JRE 8+) driver for PostgreSQL database.

Affected versions of this package are vulnerable to Not Failing Securely ('Failing Open') via the requireAuth property when it is configured to exclude all authentication methods or is left empty. An attacker can obtain database credentials by intercepting the authentication process and requesting cleartext password authentication. This is only exploitable if the requireAuth property is explicitly set to exclude all methods or is empty.

Remediation

Upgrade org.postgresql:postgresql to version 42.7.14 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release