Find, fix and prevent vulnerabilities in your code.

Overview

Affected versions of this package are vulnerable to Uncontrolled Recursion via the ClassUtils.getClass function. An attacker can cause the application to terminate unexpectedly by providing excessively long input values.

Remediation

Upgrade org.apache.commons:commons-lang3 to version 3.18.0 or higher.

References

• Apache Pony Mail
• GitHub Commit

Overview

com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation

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 com.fasterxml.jackson.core:jackson-core to version 2.18.6, 2.21.1 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub PR

Overview

com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation

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 com.fasterxml.jackson.core:jackson-core to version 2.18.7, 2.21.2 or higher.

References

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

Overview

com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation

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 com.fasterxml.jackson.core:jackson-core to version 2.18.8, 2.21.4 or higher.

References

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

Overview

com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation

Affected versions of this package are vulnerable to Denial of Service (DoS) due to missing input size validation when performing numeric type conversions. A remote attacker can exploit this vulnerability by causing the application to deserialize data containing certain numeric types with large values, causing the application to exhaust all available resources.

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 com.fasterxml.jackson.core:jackson-core to version 2.15.0-rc1 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub PR

Overview

com.fasterxml.jackson.core:jackson-core is a Core Jackson abstractions, basic JSON streaming API implementation

Affected versions of this package are vulnerable to Stack-based Buffer Overflow due to the parse process, which accepts an unlimited input file with deeply nested data. An attacker can cause a stack overflow and crash the application by providing input files with excessively deep nesting.

Remediation

Upgrade com.fasterxml.jackson.core:jackson-core to version 2.15.0-rc1 or higher.

References

• GitHub Commit
• GitHub PR

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

org.springframework:spring-core is a core package within the spring-framework that contains multiple classes and utilities.

Affected versions of this package are vulnerable to Incorrect Authorization via the AnnotationsScanner and AnnotatedMethod class. An attacker can gain unauthorized access to sensitive information by exploiting improper resolution of annotations on methods within type hierarchies that use parameterized supertypes with unbounded generics.

Note: This is only exploitable if security annotations are used on methods in generic superclasses or generic interfaces and the @EnableMethodSecurity feature is enabled.

Remediation

Upgrade org.springframework:spring-core to version 6.2.11 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Release
• Vendor Advisory

Overview

Affected versions of this package are vulnerable to Inefficient Algorithmic Complexity via evaluation of user-controlled Spring Expression Language (SpEL) expressions. An attacker can cause denial of service by supplying specially crafted SpEL expressions that trigger excessive CPU or memory consumption during expression evaluation, leading to application degradation or unavailability.

Remediation

Upgrade org.springframework:spring-expression to version 6.0.0, 6.2.19, 7.0.8 or higher.

References

• GitHub Commit
• GitHub Release
• GitHub Release
• Spring Security Advisory

Overview

Affected versions of this package are vulnerable to Integer Overflow or Wraparound via integer overflow during Spring Expression Language (SpEL) evaluation. An attacker can cause denial of service by supplying a specially crafted SpEL expression that triggers an integer overflow condition, leading to excessive resource consumption during expression processing and potentially rendering the application unavailable.

Remediation

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

References

• Spring Security Advisory

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

org.springframework:spring-expression is a

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling. via caching of parsed Spring Expression Language (SpEL) expressions. An attacker can cause denial of service by supplying crafted user-controlled SpEL expressions that trigger unbounded growth of the expression cache. Over time, repeated evaluations can consume excessive memory, eventually leading to memory exhaustion and application unavailability.

Note: Exploitation typically requires a large number of expression evaluations, potentially millions of requests, even when reusing a single expression with dynamic inputs.

Remediation

Upgrade org.springframework:spring-expression to version 6.0.0, 6.2.19, 7.0.8 or higher.

References

• GitHub Commit

• GitHub Release

• GitHub Release

• Spring Security Advisory

Overview

Affected versions of this package are vulnerable to Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) for the property source for ${random.value} (as well as ${random.int} and ${random.long}). Standard PRNGs (like java.util.Random) use deterministic mathematical algorithms starting from a seed value. Because the state space is relatively small and lacks ongoing entropy (true randomness), an attacker who observes a sequence of generated values can mathematically reverse-engineer the seed. Once the seed is known, the attacker can predict all past and future values generated by that PRNG. If these values are used to generate security-sensitive assets like API keys, session tokens, or passwords, the system becomes compromised.

Remediation

Upgrade org.springframework.boot:spring-boot to version 3.5.14, 4.0.6 or higher.

References

• GitHub Commit
• Spring Security Advisory

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling. An attacker can cause indefinite amounts of memory to be used by inputting a string of modest size. This can lead to a Denial of Service.

PoC

package orgjsonbug;

import org.json.JSONObject;

/**
 * Illustrates a bug in JSON-Java.
 */
public class Bug {
  private static String makeNested(int depth) {
    if (depth == 0) {
      return "{\"a\":1}";
    }
    return "{\"a\":1;\t\0" + makeNested(depth - 1) + ":1}";
  }

  public static void main(String[] args) {
    String input = makeNested(30);
    System.out.printf("Input string has length %d: %s\n", input.length(), input);
    JSONObject output = new JSONObject(input);
    System.out.printf("Output JSONObject has length %d: %s\n", output.toString().length(), output);
  }
}

Remediation

Upgrade org.json:json to version 20231013 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Issue

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) in the XML.toJSONObject component via crafted JSON or XML data.

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.json:json to version 20230227 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• GitHub Issue

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) if Spring MVC is used together with a reverse proxy cache.

Specifically, an application is vulnerable if all of the conditions are true:

• The application has Spring MVC auto-configuration enabled. This is the case by default if Spring MVC is on the classpath.
• The application uses Spring Boot's welcome page support, either static or templated.
• The application is deployed behind a proxy which caches 404 responses.

The application is NOT vulnerable if any of the following are true:

• Spring MVC auto-configuration is disabled. This is true if WebMvcAutoConfiguration is explicitly excluded, if Spring MVC is not on the classpath, or if spring.main.web-application-type is set to a value other than SERVLET.
• The application does not use Spring Boot's welcome page support.
• There is no proxy which caches 404 responses.

Workaround

Users who are unable to upgrade should configure the reverse proxy not to cache 404 responses and/or not to cache responses to requests to the root (/) of the application.

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.springframework.boot:spring-boot-autoconfigure to version 2.5.15, 2.6.15, 2.7.12, 3.0.7 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Release

Overview

org.yaml:snakeyaml is a YAML 1.1 parser and emitter for Java.

Affected versions of this package are vulnerable to Denial of Service (DoS) due to missing nested depth limitation for collections.

NOTE: This vulnerability has also been identified as: CVE-2022-38749

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.yaml:snakeyaml to version 1.31 or higher.

References

• Bitbucket Commit
• BitBucket Issues
• GitHub Commit

Overview

org.yaml:snakeyaml is a YAML 1.1 parser and emitter for Java.

Affected versions of this package are vulnerable to Denial of Service (DoS) due to missing nested depth limitation for collections.

NOTE: This vulnerability has also been identified as: CVE-2022-25857

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.yaml:snakeyaml to version 1.31 or higher.

References

• Bitbucket Commit
• BitBucket Issues
• GitHub Commit

Overview

Affected versions of this package are vulnerable to Insecure Temporary File due to the ApplicationTemp mechanism creating a temporary directory using a predictable name. Because the name can be easily guessed, a local attacker on the same server can maliciously pre-create this directory before the Spring Boot application starts. When the application launches, it would blindly use the existing directory without verifying if it is actually owned by the application's user or the attacker.

Remediation

Upgrade org.springframework.boot:spring-boot to version 3.5.14, 4.0.6 or higher.

References

• GitHub Commit
• Spring Security Advisory

Overview

ch.qos.logback:logback-classic is a reliable, generic, fast and flexible logging library for Java.

Affected versions of this package are vulnerable to Denial of Service (DoS). An attacker can mount a denial-of-service attack by sending poisoned data. This is only exploitable if logback receiver component is deployed.

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 ch.qos.logback:logback-classic to version 1.2.13, 1.3.12, 1.4.12 or higher.

References

• Changelog
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

ch.qos.logback:logback-classic is a reliable, generic, fast and flexible logging library for Java.

Affected versions of this package are vulnerable to Uncontrolled Resource Consumption ('Resource Exhaustion') via the logback receiver component. An attacker can mount a denial-of-service attack by sending poisoned data.

Note:

Successful exploitation requires the logback-receiver component being enabled and also reachable by the attacker.

Remediation

Upgrade ch.qos.logback:logback-classic to version 1.2.13, 1.3.14, 1.4.14 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• Release Notes
• Release Notes

Overview

ch.qos.logback:logback-core is a logback-core module.

Affected versions of this package are vulnerable to Denial of Service (DoS). An attacker can mount a denial-of-service attack by sending poisoned data. This is only exploitable if logback receiver component is deployed.

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 ch.qos.logback:logback-core to version 1.2.13, 1.3.12, 1.4.12 or higher.

References

• Changelog
• GitHub Commit
• GitHub Commit
• GitHub Commit

Overview

ch.qos.logback:logback-core is a logback-core module.

Affected versions of this package are vulnerable to Uncontrolled Resource Consumption ('Resource Exhaustion') via the logback receiver component. An attacker can mount a denial-of-service attack by sending poisoned data.

Note:

Successful exploitation requires the logback-receiver component being enabled and also reachable by the attacker.

Remediation

Upgrade ch.qos.logback:logback-core to version 1.2.13, 1.3.14, 1.4.14 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Commit
• Release Notes
• Release Notes

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

ch.qos.logback:logback-core is a logback-core module.

Affected versions of this package are vulnerable to Expression Injection in the Janino-evaluated condition attribute of <if> configuration elements, handled by IfModelHandler, whose denylist blocked only the literal new operator. A user who can modify the logback configuration can execute arbitrary code by writing an <if> condition that evades that denylist, either through references it did not cover such as Runtime or springframework, or through Unicode escape sequences like \u that reconstruct the blocked new operator. Exploitation requires write access to the logback configuration and the use of conditional <if> processing with Janino present on the classpath.

Remediation

Upgrade ch.qos.logback:logback-core to version 1.5.36 or higher.

References

• GitHub Commit
• GitHub Commit
• Release Notes