Skip to content

fix(deps): update vulnerability alerts [security] - autoclosed#60

Closed
renovate[bot] wants to merge 1 commit intomainfrom
renovate/vulnerability-alerts
Closed

fix(deps): update vulnerability alerts [security] - autoclosed#60
renovate[bot] wants to merge 1 commit intomainfrom
renovate/vulnerability-alerts

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate bot commented Dec 11, 2025 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
com.fasterxml.jackson.core:jackson-core 2.10.1 → 2.18.6 age confidence
com.fasterxml.jackson.core:jackson-databind (source) 2.10.1 → 2.12.7.1 age confidence
com.squareup.okio:okio 1.17.2 → 1.17.6 age confidence

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

Jackson-core Vulnerable to Memory Disclosure via Source Snippet in JsonLocation

CVE-2025-49128 / GHSA-wf8f-6423-gfxg

More information

Details

Overview

A flaw in Jackson-core's JsonLocation._appendSourceDesc method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible information disclosure in systems using pooled or reused buffers, like Netty or Vert.x.

Details

The vulnerability affects the creation of exception messages like:

JsonParseException: Unexpected character ... at [Source: (byte[])...]

When JsonFactory.createParser(byte[] data, int offset, int len) is used, and an error occurs while parsing, the exception message should include a snippet from the specified logical payload. However, the method _appendSourceDesc ignores the offset, and always starts reading from index 0.

If the buffer contains residual sensitive data from a previous request, such as credentials or document contents, that data may be exposed if the exception is propagated to the client.

The issue particularly impacts server applications using:

  • Pooled byte buffers (e.g., Netty)
  • Frameworks that surface parse errors in HTTP responses
  • Default Jackson settings (i.e., INCLUDE_SOURCE_IN_LOCATION is enabled)

A documented real-world example is CVE-2021-22145 in Elasticsearch, which stemmed from the same root cause.

Attack Scenario

An attacker sends malformed JSON to a service using Jackson and pooled byte buffers (e.g., Netty-based HTTP servers). If the server reuses a buffer and includes the parser’s exception in its HTTP 400 response, the attacker may receive residual data from previous requests.

Proof of Concept
byte[] buffer = new byte[1000];
System.arraycopy("SECRET".getBytes(), 0, buffer, 0, 6);
System.arraycopy("{ \"bad\": }".getBytes(), 0, buffer, 700, 10);

JsonFactory factory = new JsonFactory();
JsonParser parser = factory.createParser(buffer, 700, 20);
parser.nextToken(); // throws exception

// Exception message will include "SECRET"
Patches

This issue was silently fixed in jackson-core version 2.13.0, released on September 30, 2021, via PR #​652.

All users should upgrade to version 2.13.0 or later.

Workarounds

If upgrading is not immediately possible, applications can mitigate the issue by:

  1. Disabling exception message exposure to clients — avoid returning parsing exception messages in HTTP responses.

  2. Disabling source inclusion in exceptions by setting:

    jsonFactory.disable(JsonFactory.Feature.INCLUDE_SOURCE_IN_LOCATION);

    This prevents Jackson from embedding any source content in exception messages, avoiding leakage.

References

Severity

  • CVSS Score: 4.0 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

jackson-core can throw a StackoverflowError when processing deeply nested data

CVE-2025-52999 / GHSA-h46c-h94j-95f3

More information

Details

Impact

With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large.

Patches

jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached.
jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs.

Workarounds

Users should avoid parsing input files from untrusted sources.

Severity

  • CVSS Score: 8.7 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition

GHSA-72hv-8253-57qq

More information

Details

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
    @​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);
    }
}
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:

  1. Memory Exhaustion: Unbounded allocation of memory in the TextBuffer to store the number's digits, leading to an OutOfMemoryError.
  2. 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

Severity

  • CVSS Score: 6.9 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

XML External Entity (XXE) Injection in Jackson Databind

CVE-2020-25649 / GHSA-288c-cq4h-88gq

More information

Details

A flaw was found in FasterXML Jackson Databind, where it did not have entity expansion secured properly. This flaw allows vulnerability to XML external entity (XXE) attacks. The highest threat from this vulnerability is data integrity.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

jackson-databind possible Denial of Service if using JDK serialization to serialize JsonNode

CVE-2021-46877 / GHSA-3x8x-79m2-3w2w

More information

Details

jackson-databind 2.10.x through 2.12.x before 2.12.6 and 2.13.x before 2.13.1 allows attackers to cause a denial of service (2 GB transient heap usage per read) in uncommon situations involving JsonNode JDK serialization.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Deeply nested json in jackson-databind

CVE-2020-36518 / GHSA-57j2-w4cx-62h2

More information

Details

jackson-databind is a data-binding package for the Jackson Data Processor. jackson-databind allows a Java stack overflow exception and denial of service via a large depth of nested objects.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Uncontrolled Resource Consumption in Jackson-databind

CVE-2022-42003 / GHSA-jjjh-jjxp-wpff

More information

Details

In FasterXML jackson-databind 2.4.0-rc1 until 2.12.7.1 and in 2.13.x before 2.13.4.2 resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. This was patched in 2.12.7.1, 2.13.4.2, and 2.14.0.

Commits that introduced vulnerable code are
FasterXML/jackson-databind@d499f2e, FasterXML/jackson-databind@0e37a39, and FasterXML/jackson-databind@7ba9ac5.

Fix commits are FasterXML/jackson-databind@cd09097 and FasterXML/jackson-databind@d78d00e.

The 2.13.4.1 release does fix this issue, however it also references a non-existent jackson-bom which causes build failures for gradle users. See https://github.com/FasterXML/jackson-databind/issues/3627#issuecomment-1277957548 for details. This is fixed in 2.13.4.2 which is listed in the advisory metadata so that users are not subjected to unnecessary build failures

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Uncontrolled Resource Consumption in FasterXML jackson-databind

CVE-2022-42004 / GHSA-rgv9-q543-rqg4

More information

Details

In FasterXML jackson-databind before 2.12.7.1 and in 2.13.x before 2.13.4, resource exhaustion can occur because of a lack of a check in BeanDeserializer._deserializeFromArray to prevent use of deeply nested arrays. This issue can only happen when the UNWRAP_SINGLE_VALUE_ARRAYS feature is explicitly enabled.

Severity

  • CVSS Score: 8.2 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Okio Signed to Unsigned Conversion Error vulnerability

CVE-2023-3635 / GHSA-w33c-445m-f8w7

More information

Details

GzipSource does not handle an exception that might be raised when parsing a malformed gzip buffer. This may lead to denial of service of the Okio client when handling a crafted GZIP archive, by using the GzipSource class.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

square/okio (com.squareup.okio:okio)

v1.17.6

2023-10-01

  • Fix: Don't crash decoding GZIP files when the optional extra data (XLEN) is 32 KiB or larger.

v1.17.5

2019-12-11

  • Fix: Don't crash when an InputStream source is exhausted exactly at a buffer segment boundary.
    We had a bug where a sequence of reads could violate a buffer's invariants, and this could result
    in a crash when subsequent reads encountered an unexpected empty segment.

v1.17.4

2019-04-29

  • Fix: Don't block unless strictly necessary in BufferedSource.peek().

v1.17.3

2019-01-28

  • Fix: Make Pipe.fold() close the underlying sink when necessary.

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the security label Dec 11, 2025
@renovate renovate bot changed the title fix(deps): update vulnerability alerts [security] fix(deps): update vulnerability alerts [security] - autoclosed Jan 28, 2026
@renovate renovate bot closed this Jan 28, 2026
@renovate renovate bot deleted the renovate/vulnerability-alerts branch January 28, 2026 09:03
@renovate renovate bot changed the title fix(deps): update vulnerability alerts [security] - autoclosed fix(deps): update vulnerability alerts [security] Feb 2, 2026
@renovate renovate bot reopened this Feb 2, 2026
@renovate renovate bot force-pushed the renovate/vulnerability-alerts branch 2 times, most recently from d0d76e9 to 616d718 Compare February 2, 2026 17:40
@renovate
fix(deps): update vulnerability alerts [security]
1f4450c 
Signed-off-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
@renovate renovate bot force-pushed the renovate/vulnerability-alerts branch from 616d718 to 1f4450c Compare February 28, 2026 21:52
@renovate renovate bot changed the title fix(deps): update vulnerability alerts [security] fix(deps): update vulnerability alerts [security] - autoclosed Apr 6, 2026
@renovate renovate bot closed this Apr 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@SerenModz21 SerenModz21

Labels

security

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@SerenModz21