CVE-2026-18401
jackson-core: Number length constraint bypass in non-blocking (async) JSON parser leads to potential denial of service
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- None
- Availability
- Low
Exploit likelihood
What each source reports
CVE List Score used
jackson-core: Number length constraint bypass in non-blocking (async) JSON parser leads to potential denial of service
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
CVE-2026-18401- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-770
- Updated
- 2026-11-02
EUVDEUVD-2026-52699
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
EUVD-2026-52699- CVSS 4.0
- 6.9 Medium
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 - Updated
- 2026-11-02
GitHub AdvisoriesGHSA-6qm2-mcq7-53qp
Duplicate Advisory: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-72hv-8253-57qq. This link is maintained to preserve external references.
Original Description
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
GHSA-6qm2-mcq7-53qp- CVSS 4.0
- 6.9 Medium
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Weakness
- CWE-770
- Updated
- 2026-11-02
GitHub AdvisoriesGHSA-72hv-8253-57qq
jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
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 theTextBufferwithout any length checks. - After parsing, they call
_valueComplete(), which finalizes the token but does not callresetInt()orresetFloat(). - The
resetInt()/resetFloat()methods inParserBaseare where thevalidateIntegerLength()andvalidateFPLength()checks are performed. - Because this validation step is skipped, the
maxNumberLengthconstraint 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);
…
- Record
GHSA-72hv-8253-57qq- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-770
- Updated
- 2026-11-02
NVD
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
CVE-2026-18401- CVSS 4.0
- 6.9 Medium
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Weakness
- CWE-770
- Updated
- 2026-11-02
OSV
jackson-core: Number length constraint bypass in non-blocking (async) JSON parser leads to potential denial of service
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
CVE-2026-18401- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-770
- Updated
- 2026-11-02
Show 26 moreShow less
OSVDEBIAN-CVE-2026-18401
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
DEBIAN-CVE-2026-18401- CVSS 4.0
- 6.9 Medium
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Updated
- 2026-11-02
OSVGHSA-6qm2-mcq7-53qp
Duplicate Advisory: jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-72hv-8253-57qq. This link is maintained to preserve external references.
Original Description
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service.
The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses.
Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path.
Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service.
No privileges or user interaction beyond the ability to submit data for parsing are required.
This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x.
Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
GHSA-6qm2-mcq7-53qp- CVSS 4.0
- 6.9 Medium
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X - Weakness
- CWE-770
- Updated
- 2026-11-02
OSVGHSA-72hv-8253-57qq
jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
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 theTextBufferwithout any length checks. - After parsing, they call
_valueComplete(), which finalizes the token but does not callresetInt()orresetFloat(). - The
resetInt()/resetFloat()methods inParserBaseare where thevalidateIntegerLength()andvalidateFPLength()checks are performed. - Because this validation step is skipped, the
maxNumberLengthconstraint 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);
…
- Record
GHSA-72hv-8253-57qq- CVSS 4.0
- 6.9 Medium
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 - Weakness
- CWE-770
- Updated
- 2026-11-02
OSVUBUNTU-CVE-2026-18401
The non-blocking (asynchronous) JSON parser in jackson-core does not enforce the maxNumberLength constraint defined in StreamReadConstraints (default: 1000 characters). An attacker able to submit JSON to an application that uses the async parser API can supply a number token of arbitrary length, leading to excessive memory allocation and potential CPU exhaustion, resulting in a denial of service. The synchronous parser enforces this limit correctly, so the constraint is applied inconsistently depending on which parsing API the application uses. Root cause: the async parsing path in NonBlockingUtf8JsonParserBase and related classes never invokes the number length validation methods. Number parsing methods such as _finishNumberIntegralPart() accumulate digits into the TextBuffer without any length check, then call _valueComplete() to finalize the token. _valueComplete() does not call resetInt() or resetFloat(), which are the methods in ParserBase where validateIntegerLength() and validateFPLength() are performed. Because that validation step is skipped, maxNumberLength is never enforced on the async code path. Impact: an attacker sending a JSON document containing an arbitrarily long number to an application using the async parser (for example a Spring WebFlux or other reactive application) can cause unbounded allocation in the TextBuffer and an OutOfMemoryError. If the application subsequently calls getBigIntegerValue() or getDecimalValue(), the JVM may additionally be tied up in O(n^2) BigInteger parsing, causing CPU-based denial of service. No privileges or user interaction beyond the ability to submit data for parsing are required. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.5 and from 2.19.0 through 2.21.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.0.x. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-72hv-8253-57qq records the lower bound of the affected 2.x range as 2.0.0.
- Record
UBUNTU-CVE-2026-18401- CVSS 4.0
- 6.9 Medium
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 - Updated
- 2026-11-02
OSVCLSA-2026-1776386157 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (3 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 3 CVEs. Fixed in 2.12.1-tuxcare.1.
- Record
CLSA-2026-1776386157- Updated
- 2026-11-02
OSVCLSA-2026-1789484097 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (4 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 4 CVEs. Fixed in 2.17.2-tuxcare.1.
- Record
CLSA-2026-1789484097- Updated
- 2026-11-02
OSVCLSA-2026-1791447404 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (2 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 2 CVEs. Fixed in 2.17.3-tuxcare.1.
- Record
CLSA-2026-1791447404- Updated
- 2026-11-02
OSVCLSA-2026-1791485698 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (6 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.17.1-tuxcare.1.
- Record
CLSA-2026-1791485698- Updated
- 2026-11-02
OSVCLSA-2026-1791493683 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (5 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 5 CVEs. Fixed in 2.14.2-tuxcare.3.
- Record
CLSA-2026-1791493683- Updated
- 2026-11-02
OSVCLSA-2026-1791495450 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (5 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 5 CVEs. Fixed in 2.14.1-tuxcare.2.
- Record
CLSA-2026-1791495450- Updated
- 2026-11-02
OSVCLSA-2026-1792399384 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (3 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 3 CVEs. Fixed in 2.15.4-tuxcare.1.
- Record
CLSA-2026-1792399384- Updated
- 2026-11-02
OSVCLSA-2026-1792399460 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (6 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.13.2-tuxcare.1.
- Record
CLSA-2026-1792399460- Updated
- 2026-11-02
OSVCLSA-2026-1792399472 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (6 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.13.4-tuxcare.1.
- Record
CLSA-2026-1792399472- Updated
- 2026-11-02
OSVCLSA-2026-1792428564 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (1 CVE)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 1 CVE. Fixed in 2.18.5-tuxcare.1.
- Record
CLSA-2026-1792428564- Updated
- 2026-11-02
OSVCLSA-2026-1792431620 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (3 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 3 CVEs. Fixed in 2.16.1-tuxcare.1.
- Record
CLSA-2026-1792431620- Updated
- 2026-11-02
OSVCLSA-2026-1792431627 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (5 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 5 CVEs. Fixed in 2.15.0-tuxcare.1.
- Record
CLSA-2026-1792431627- Updated
- 2026-11-02
OSVCLSA-2026-1792434304 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (4 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 4 CVEs. Fixed in 2.13.3-tuxcare.1.
- Record
CLSA-2026-1792434304- Updated
- 2026-11-02
OSVCLSA-2026-1793085045 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (3 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 3 CVEs. Fixed in 2.18.4.1-tuxcare.2.
- Record
CLSA-2026-1793085045- Updated
- 2026-11-02
OSVCLSA-2026-1793085177 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (6 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 6 CVEs. Fixed in 2.20.1-tuxcare.1.
- Record
CLSA-2026-1793085177- Updated
- 2026-11-02
OSVCLSA-2026-1793196863 No score
TuxCare security update for com.fasterxml.jackson.core:jackson-core (2 CVEs)
TuxCare rebuilt com.fasterxml.jackson.core:jackson-core to address 2 CVEs. Fixed in 2.19.4-tuxcare.1.
- Record
CLSA-2026-1793196863- Updated
- 2026-11-02
OSVopenSUSE-SU-2026:11638-1 No score
jackson-core-2.18.9-2.1 on GA media
These are all security issues fixed in the jackson-core-2.18.9-2.1 package on the GA media of openSUSE Tumbleweed.
- Record
openSUSE-SU-2026:11638-1- Updated
- 2026-11-02
OSVopenSUSE-SU-2026:22034-1 No score
Security update for jackson-annotations, jackson-core, jackson-databind
This update for jackson-annotations, jackson-core, jackson-databind fixes the following issues:
- CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time Issues (bsc#1273856).
- CVE-2026-19032: deserializer for
java.nio.file.Pathresolves attacker-supplied URIs without restricting the URI scheme (bsc#1277883). - CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
- CVE-2026-68497: An unauthenticated attacker can therefore submit a single request of a few megabytes (bsc#1280125).
- CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
- CVE-2026-83557: incomplete
PolymorphicTypeValidatordenylist allows for arbitraryComparabledeserialization (bsc#1278008). - CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
- CVE-2026-89425:
UTF8DataInputJsonParser._reportInvalidToken()lacksmaxErrorTokenLengthlimit, which allows for unboundedStringBuildergrowth and can lead to a DoS when malformed tokens are processed (bsc#1282505). - CVE-2026-91776:
TypeDeserializerBase._findDeserializer()caches the resolved deserializer under the raw, attacker- supplied type ID, which can lead to unbounded cache growth under certain configurations (bsc#1282491). - CVE-2026-91777: forward-reference completion for
@JsonIdentityInfoobject IDs performs a linear scan of the pending- reference accumulator for every resolved ID, which can lead to quadratic CPU work during deserialization (bsc#1282492).
Changes for jackson-annotations:
- Update to 2.18.11
Changes for jackson-core:
- Update to 2.18.11
- #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645, CVE-2026-89407)
- #1698: UTF8DataInputJsonParser does not honor maxErrorTokenLength when reporting an unrecognized token (bsc#1282505, CVE-2026-89425)
- #1642: Fix maxDocumentLength bypass in async parser single-feedInput() case [GHSA-2c4j-63jj-9fqr]
- #1643: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498) of async parser (bsc#1273857, CVE-2026-68494) non-blocking (async) parser (bsc#1273856, CVE-2026-18401)
Changes for jackson-databind:
- Update to 2.18.11
- #6185: Bracket unresolved IPv6 host name in InetSocketAddress serialization
- #6203: Prevent unbounded growth of type id cache in TypeDeserializer (bsc#1282491, CVE-2026-91776)
- #6204: Avoid quadratic forward-reference resolution in Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
- #6099: Resolve classes without initialization in TypeFactory.findClass()
- #6116: Reject non-ASCII digits in InetAddress literal validation
- #6127: Add StreamReadConstraints number len constraint to javax.xml.datatype.XMLGregorianCalendar and javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
- #6129: Limit the supported URL schemes for java.nio.file.Path deserialization (bsc#1277883, CVE-2026-19032)
- #6156: Add java.lang.Comparable in set of unsafe polymorphic base types (bsc#1278008, CVE-2026-83557)
- #6165: Apply number length limits to BigDecimal/BigInteger/ /Double/Float Map keys
- Record
openSUSE-SU-2026:22034-1- Updated
- 2026-11-02
OSVROOT-APP-MAVEN-CVE-2026-18401 No score
CVE-2026-18401 in tools.jackson.core:jackson-core - Patched by Root
Root has patched CVE-2026-18401 in the tools.jackson.core:jackson-core package for Root:Maven. Multiple fixed versions available.
- Record
ROOT-APP-MAVEN-CVE-2026-18401- Updated
- 2026-11-02
OSVROOT-APP-MAVEN-GHSA-72hv-8253-57qq No score
GHSA-72hv-8253-57qq in com.fasterxml.jackson.core:jackson-core - Patched by Root
Root has patched GHSA-72hv-8253-57qq in the com.fasterxml.jackson.core:jackson-core package for Root:Maven. Multiple fixed versions available.
- Record
ROOT-APP-MAVEN-GHSA-72hv-8253-57qq- Updated
- 2026-11-05
OSVSUSE-SU-2026:24149-1 No score
Security update for jackson-annotations, jackson-core, jackson-databind
This update for jackson-annotations, jackson-core, jackson-databind fixes the following issues:
- CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time Issues (bsc#1273856).
- CVE-2026-19032: deserializer for
java.nio.file.Pathresolves attacker-supplied URIs without restricting the URI scheme (bsc#1277883). - CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
- CVE-2026-68497: An unauthenticated attacker can therefore submit a single request of a few megabytes (bsc#1280125).
- CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
- CVE-2026-83557: incomplete
PolymorphicTypeValidatordenylist allows for arbitraryComparabledeserialization (bsc#1278008). - CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
- CVE-2026-89425:
UTF8DataInputJsonParser._reportInvalidToken()lacksmaxErrorTokenLengthlimit, which allows for unboundedStringBuildergrowth and can lead to a DoS when malformed tokens are processed (bsc#1282505). - CVE-2026-91776:
TypeDeserializerBase._findDeserializer()caches the resolved deserializer under the raw, attacker- supplied type ID, which can lead to unbounded cache growth under certain configurations (bsc#1282491). - CVE-2026-91777: forward-reference completion for
@JsonIdentityInfoobject IDs performs a linear scan of the pending- reference accumulator for every resolved ID, which can lead to quadratic CPU work during deserialization (bsc#1282492).
Changes for jackson-annotations:
- Update to 2.18.11
Changes for jackson-core:
- Update to 2.18.11
- #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645, CVE-2026-89407)
- #1698: UTF8DataInputJsonParser does not honor maxErrorTokenLength when reporting an unrecognized token (bsc#1282505, CVE-2026-89425)
- #1642: Fix maxDocumentLength bypass in async parser single-feedInput() case [GHSA-2c4j-63jj-9fqr]
- #1643: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498) of async parser (bsc#1273857, CVE-2026-68494) non-blocking (async) parser (bsc#1273856, CVE-2026-18401)
Changes for jackson-databind:
- Update to 2.18.11
- #6185: Bracket unresolved IPv6 host name in InetSocketAddress serialization
- #6203: Prevent unbounded growth of type id cache in TypeDeserializer (bsc#1282491, CVE-2026-91776)
- #6204: Avoid quadratic forward-reference resolution in Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
- #6099: Resolve classes without initialization in TypeFactory.findClass()
- #6116: Reject non-ASCII digits in InetAddress literal validation
- #6127: Add StreamReadConstraints number len constraint to javax.xml.datatype.XMLGregorianCalendar and javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
- #6129: Limit the supported URL schemes for java.nio.file.Path deserialization (bsc#1277883, CVE-2026-19032)
- #6156: Add java.lang.Comparable in set of unsafe polymorphic base types (bsc#1278008, CVE-2026-83557)
- #6165: Apply number length limits to BigDecimal/BigInteger/ /Double/Float Map keys
- Record
SUSE-SU-2026:24149-1- Updated
- 2026-11-02
OSVSUSE-SU-2026:4394-1 No score
Security update for jackson-annotations, jackson-bom, jackson-core, jackson-databind, jackson-dataformat-xml, jackson-dataformats-binary, jackson-modules-base
This update for jackson-annotations, jackson-bom, jackson-core, jackson-databind, jackson-dataformat-xml, jackson-dataformats-binary, jackson-modules-base fixes the following issues:
- CVE-2026-18401: Number Length Constraint Bypass in Async Parser Can Lead to Potential Processing Time Issues (bsc#1273856).
- CVE-2026-68494: Async parser maxNumberLength bypass via chunked digit accumulation (bsc#1273857).
- CVE-2026-68495: Ensure maxNameLength limit enforced for CBOR parser (bsc#1282639).
- CVE-2026-68496: Ensure maxNameLength limit enforced for Smile parser (bsc#1282640).
- CVE-2026-68498: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641).
- CVE-2026-89407: Optimize NumberInput.looksLikeValidNumber (bsc#1282645).
- CVE-2026-89425:
UTF8DataInputJsonParser._reportInvalidToken()lacksmaxErrorTokenLengthlimit, which allows for unboundedStringBuildergrowth and can lead to a DoS when malformed tokens are processed (bsc#1282505).
Changes for jackson-annotations:
- Update to 2.18.11
Changes for jackson-bom:
- Update to 2.18.11
Changes for jackson-core:
- Update to 2.18.11
- #1649: Optimize NumberInput.looksLikeValidNumber (bsc#1282645, CVE-2026-89407)
- #1698: UTF8DataInputJsonParser does not honor maxErrorTokenLength when reporting an unrecognized token (bsc#1282505, CVE-2026-89425)
- #1642: Fix maxDocumentLength bypass in async parser single-feedInput() case [GHSA-2c4j-63jj-9fqr]
- #1643: Enforce maxNameLength incrementally in ReaderBasedJsonParser (bsc#1282641, CVE-2026-68498) of async parser (bsc#1273857, CVE-2026-68494) non-blocking (async) parser (bsc#1273856, CVE-2026-18401)
Changes for jackson-databind:
- Update to 2.18.11
- #6185: Bracket unresolved IPv6 host name in InetSocketAddress serialization
- #6203: Prevent unbounded growth of type id cache in TypeDeserializer (bsc#1282491, CVE-2026-91776)
- #6204: Avoid quadratic forward-reference resolution in Collection/Map deserializers (bsc#1282492, CVE-2026-91777)
- #6099: Resolve classes without initialization in TypeFactory.findClass()
- #6116: Reject non-ASCII digits in InetAddress literal validation
- #6127: Add StreamReadConstraints number len constraint to javax.xml.datatype.XMLGregorianCalendar and javax.xml.datatype.Duration (bsc#1280125, CVE-2026-68497)
- #6129: Limit the supported URL schemes for java.nio.file.Path deserialization (bsc#1277883, CVE-2026-19032)
- #6156: Add java.lang.Comparable in set of unsafe polymorphic base types (bsc#1278008, CVE-2026-83557)
- #6165: Apply number length limits to BigDecimal/BigInteger/ /Double/Float Map keys
Changes for jackson-dataformat-xml:
- Update to 2.18.11
- Fix build to avoid past-JDK-8 bytecode generation
- #891: Enforce StreamReadConstraints.maxNestingDepth in FromXmlParser
Changes for jackson-dataformats-binary:
- Update to 2.18.11
- #783: (protobuf) Support StreamReadConstraints.maxDocumentLength in ProtobufParser
- #785: (avro) Support StreamReadConstraints.maxDocumentLength and maxTokenCount in Avro parser
- #803: (ion) Support StreamReadConstraints.maxNestingDepth in Ion parser (partial fix for #358)
- #805: (ion) Support StreamReadConstraints.maxDocumentLength in Ion parser (partial fix for #358)
- #725: (cbor) Ensure maxNameLength limit enforced for CBOR parser (bsc#1282639, CVE-2026-68495)
- #726: (smile) Ensure maxNameLength limit enforced for Smile parser (bsc#1282640, CVE-2026-68496)
- #727: (cbor) CBORParser.nextFieldName(SerializableString) confuses 5-bit length marker 23 with 24 ('1-byte length suffix follows')
- #728: (cbor) CBORParser.nextFieldName(SerializableString) consumes Object entry slot twice on fast-path miss, truncating definite-length Objects
- #733: (cbor) Long
Strings not added to 'stringref' reference table, breaking following references - #735: (cbor) 'stringref' property-name paths pass 5-bit length marker instead of actual length to shouldReferenceString()
- #736: (cbor) Long…
- Record
SUSE-SU-2026:4394-1- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
tools.jackson.core:jackson-coreMaven |
3.0.0 up to 3.1.0 | 3.1.0 |
com.fasterxml.jackson.core:jackson-coreMaven |
2.19.0 up to 2.21.1 | 2.21.1 |
com.fasterxml.jackson.core:jackson-coreMaven |
2.15.0 to 2.18.5 | 2.18.6 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.12.1 up to 2.12.1-tuxcare.1 | 2.12.1-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.17.2 up to 2.17.2-tuxcare.1 | 2.17.2-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven |
2.17.3 up to 2.17.3-tuxcare.1 | 2.17.3-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 4 CVEs |
2.17.1 up to 2.17.1-tuxcare.1 | 2.17.1-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.14.2 up to 2.14.2-tuxcare.3, plus listed versions 2.14.2-tuxcare.12.14.2-tuxcare.2 |
2.14.2-tuxcare.3 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.14.1 up to 2.14.1-tuxcare.2, plus listed versions 2.14.1-tuxcare.1 |
2.14.1-tuxcare.2 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.15.4 up to 2.15.4-tuxcare.1 | 2.15.4-tuxcare.1 |
Show 90 moreShow less
| Package | Affected | Fixed |
|---|---|---|
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 3 CVEs |
2.13.2 up to 2.13.2-tuxcare.1 | 2.13.2-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 3 CVEs |
2.13.4 up to 2.13.4-tuxcare.1 | 2.13.4-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven |
2.18.5 up to 2.18.5-tuxcare.1 | 2.18.5-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.16.1 up to 2.16.1-tuxcare.1 | 2.16.1-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 3 CVEs |
2.15.0 up to 2.15.0-tuxcare.1 | 2.15.0-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.13.3 up to 2.13.3-tuxcare.1 | 2.13.3-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.18.4.1 up to 2.18.4.1-tuxcare.2, plus listed versions 2.18.4.1-tuxcare.1 |
2.18.4.1-tuxcare.2 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 4 CVEs |
2.20.1 up to 2.20.1-tuxcare.1 | 2.20.1-tuxcare.1 |
com.fasterxml.jackson.core:jackson-coreTuxCare:Maven From an advisory covering 2 CVEs |
2.19.4 up to 2.19.4-tuxcare.1 | 2.19.4-tuxcare.1 |
tools.jackson.core:jackson-coreMaven |
3.0.0 up to 3.1.0, plus listed versions 3.0.13.0.23.0.33.0.43.1.0-rc1 |
3.1.0 |
com.fasterxml.jackson.core:jackson-coreMaven |
2.19.0 up to 2.21.1, plus listed versions 2.19.12.19.22.19.32.19.42.20.0 Show 4 moreShow less2.20.0-rc12.20.12.20.22.21.0 |
2.21.1 |
com.fasterxml.jackson.core:jackson-coreMaven |
2.15.0 up to 2.18.6, plus listed versions 2.15.12.15.22.15.32.15.42.16.0 Show 16 moreShow less2.16.0-rc12.16.12.16.22.17.02.17.0-rc12.17.12.17.22.17.32.18.02.18.0-rc12.18.12.18.22.18.32.18.42.18.4.12.18.5 |
2.18.6 |
tools.jackson.core:jackson-coreRoot:Maven |
before 3.1.0-aikido.2 | 3.1.0-aikido.23.1.0-aikido.3 |
com.fasterxml.jackson.core:jackson-coreRoot:Maven |
before 2.21.1-aikido.1 | 2.21.1-aikido.1 |
io.root.tools.jackson.core:jackson-coreRoot:Maven |
before 3.1.0-root.io.1 | 3.1.0-root.io.13.1.0-root.io.23.1.0-root.io.3 |
io.root.com.fasterxml.jackson.core:jackson-coreRoot:Maven |
before 2.21.1-root.io.1 | 2.21.1-root.io.1 |
com.fasterxml.jackson.core:jackson-coreRoot:Maven |
before 2.13.3-aikido.2 | 2.13.3-aikido.22.15.3-aikido.22.16.1-aikido.22.16.2-aikido.22.18.2-aikido.22.20.0-aikido.22.18.3-aikido.22.17.2-aikido.12.14.1-aikido.12.14.1-aikido.22.17.1-aikido.12.15.2-aikido.12.14.3-aikido.22.13.2-aikido.32.19.4-aikido.12.12.4-aikido.22.12.5-aikido.22.10.1-aikido.22.12.3-aikido.22.13.4-aikido.22.14.2-aikido.22.17.0-aikido.12.14.2-aikido.32.15.2-aikido.22.14.3-aikido.32.12.3-aikido.32.12.4-aikido.32.13.2-aikido.42.12.5-aikido.32.13.4-aikido.32.14.1-aikido.32.10.1-aikido.32.17.2-aikido.22.19.4-aikido.22.17.0-aikido.22.17.1-aikido.22.15.3-aikido.32.15.0-aikido.12.17.2-aikido.32.17.2-aikido.42.14.2-aikido.42.15.2-aikido.32.17.1-aikido.32.19.0-aikido.12.17.2-aikido.52.18.3-aikido.3 |
io.root.com.fasterxml.jackson.core:jackson-coreRoot:Maven |
before 2.18.2-root.io.1 | 2.18.2-root.io.12.16.2-root.io.12.16.1-root.io.12.18.3-root.io.12.13.3-root.io.12.20.0-root.io.12.15.3-root.io.12.13.3-root.io.22.15.3-root.io.22.16.1-root.io.22.16.2-root.io.22.18.2-root.io.22.20.0-root.io.22.18.3-root.io.22.17.2-root.io.12.14.1-root.io.12.14.1-root.io.22.17.1-root.io.12.15.2-root.io.12.14.3-root.io.22.13.2-root.io.32.19.4-root.io.12.12.4-root.io.22.12.5-root.io.22.14.2-root.io.22.10.1-root.io.22.12.3-root.io.22.13.4-root.io.22.17.0-root.io.12.14.2-root.io.32.15.2-root.io.22.14.3-root.io.32.12.3-root.io.32.12.4-root.io.32.13.2-root.io.42.12.5-root.io.32.13.4-root.io.32.14.1-root.io.32.10.1-root.io.32.17.2-root.io.22.19.4-root.io.22.17.0-root.io.22.17.1-root.io.22.15.3-root.io.32.15.0-root.io.12.17.2-root.io.32.17.2-root.io.42.14.2-root.io.42.15.2-root.io.32.17.1-root.io.32.19.0-root.io.12.17.2-root.io.52.18.3-root.io.3 |
jackson-annotationsSUSE:Linux Enterprise Server 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-coreSUSE:Linux Enterprise Server 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-databindSUSE:Linux Enterprise Server 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-annotationsSUSE:Linux Enterprise Server for SAP applications 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-coreSUSE:Linux Enterprise Server for SAP applications 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-databindSUSE:Linux Enterprise Server for SAP applications 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-annotationsSUSE:Linux Enterprise Module for Basesystem 15 SP7 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Module for Basesystem 15 SP7 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Module for Basesystem 15 SP7 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Module for Basesystem 15 SP7 From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Module for Development Tools 15 SP7 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise High Performance Computing 15 SP4-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise High Performance Computing 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise High Performance Computing 15 SP5-ESPOS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise High Performance Computing 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise Server 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Server 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Server 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Server 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Server 15 SP4-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise Server 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Server 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Server 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Server 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Server 15 SP5-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise Server 15 SP6-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Server 15 SP6-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Server 15 SP6-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Server 15 SP6-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Server 15 SP6-LTSS From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise Server for SAP Applications 15 SP4 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Server for SAP Applications 15 SP4 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Server for SAP Applications 15 SP4 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Server for SAP Applications 15 SP4 From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Server for SAP Applications 15 SP4 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise Server for SAP Applications 15 SP5 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Server for SAP Applications 15 SP5 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Server for SAP Applications 15 SP5 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Server for SAP Applications 15 SP5 From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Server for SAP Applications 15 SP5 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-annotationsSUSE:Linux Enterprise Server for SAP Applications 15 SP6 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.28.1 | 2.18.11-150200.3.28.1 |
jackson-coreSUSE:Linux Enterprise Server for SAP Applications 15 SP6 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.30.1 | 2.18.11-150200.3.30.1 |
jackson-databindSUSE:Linux Enterprise Server for SAP Applications 15 SP6 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.36.1 | 2.18.11-150200.3.36.1 |
jackson-dataformat-xmlSUSE:Linux Enterprise Server for SAP Applications 15 SP6 From an advisory covering 12 CVEs |
before 2.18.11-150200.5.8.1 | 2.18.11-150200.5.8.1 |
jackson-dataformats-binarySUSE:Linux Enterprise Server for SAP Applications 15 SP6 From an advisory covering 12 CVEs |
before 2.18.11-150200.3.29.1 | 2.18.11-150200.3.29.1 |
jackson-coreUbuntu:16.04:LTS |
All versions, plus listed versions 2.4.2-2 |
None known |
jackson-coreUbuntu:18.04:LTS |
All versions, plus listed versions 2.8.6-12.9.1-12.9.4-12.9.8-3~18.04 |
None known |
jackson-coreUbuntu:20.04:LTS |
All versions, plus listed versions 2.9.8-32.10.0-12.10.1-1 |
None known |
jackson-coreUbuntu:22.04:LTS |
All versions, plus listed versions 2.12.1-12.13.0-12.13.0-2 |
None known |
jackson-coreUbuntu:24.04:LTS |
All versions, plus listed versions 2.14.1-1 |
None known |
jackson-coreUbuntu:26.10 |
All versions, plus listed versions 2.14.1-1build12.14.1-2 |
None known |
jackson-coreUbuntu:26.04:LTS |
All versions, plus listed versions 2.14.1-12.14.1-1build1 |
None known |
jackson-coreopenSUSE:Tumbleweed From an advisory covering 2 CVEs |
before 2.18.9-2.1 | 2.18.9-2.1 |
jackson-annotationsopenSUSE:Leap 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-coreopenSUSE:Leap 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
jackson-databindopenSUSE:Leap 16.0 From an advisory covering 10 CVEs |
before 2.18.11-160000.1.1 | 2.18.11-160000.1.1 |
History
| Recorded | Changed | Sources |
|---|---|---|
| affected | ||
| affected, facts | OSV | |
| affected | ||
| first indexed | CVE List, EUVD, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2026-18401 is a medium vulnerability (CVSS 6.9) in Fasterxml Jackson-core, published February 28, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.41%, the 35th percentile. Fixed in tools.jackson.core:jackson-core 3.1.0.
References
github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq
nvd.nist.gov/vuln/detail/CVE-2026-18401
Show 32 moreShow less
repo.maven.apache.org/maven2
security-tracker.debian.org/tracker/CVE-2026-18401
suse.com/support/update/announcement/2026/suse-su-202624149-1
bugzilla.suse.com/1273856
ubuntu.com/security/CVE-2026-18401
cve.org/CVERecord?id=CVE-2026-18401
Left out here: the rest of 3 source descriptions. The JSON record has them.