Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-05-21 08:12
Modified
2026-05-20 13:34
Summary
Security fixes for CVE-2025-12383, CVE-2025-48924, CVE-2026-42583, ghsa-72hv-8253-57qq, ghsa-7p63-w6x9-6gr7, ghsa-j288-q9x7-2f5v applied in versions: 9.8.0-r0, 9.8.0-r1
Details
Multiple security vulnerabilities affect the solr package. These issues are resolved in later releases. See references for individual vulnerability details.
References
{
"affected": [
{
"package": {
"ecosystem": "CleanStart",
"name": "solr"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "9.8.0-r1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"credits": [],
"database_specific": {},
"details": "Multiple security vulnerabilities affect the solr package. These issues are resolved in later releases. See references for individual vulnerability details.",
"id": "CLEANSTART-2026-LZ76508",
"modified": "2026-05-20T13:34:02Z",
"published": "2026-05-21T08:12:41.404507Z",
"references": [
{
"type": "ADVISORY",
"url": "https://github.com/cleanstart-dev/cleanstart-security-advisories/tree/main/advisories/2026/CLEANSTART-2026-LZ76508.json"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2025-12383"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2025-48924"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/CVE-2026-42583"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-72hv-8253-57qq"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-7p63-w6x9-6gr7"
},
{
"type": "WEB",
"url": "https://osv.dev/vulnerability/ghsa-j288-q9x7-2f5v"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12383"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48924"
},
{
"type": "WEB",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42583"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes for CVE-2025-12383, CVE-2025-48924, CVE-2026-42583, ghsa-72hv-8253-57qq, ghsa-7p63-w6x9-6gr7, ghsa-j288-q9x7-2f5v applied in versions: 9.8.0-r0, 9.8.0-r1",
"upstream": [
"CVE-2025-12383",
"CVE-2025-48924",
"CVE-2026-42583",
"ghsa-72hv-8253-57qq",
"ghsa-7p63-w6x9-6gr7",
"ghsa-j288-q9x7-2f5v"
]
}
CVE-2025-12383 (GCVE-0-2025-12383)
Vulnerability from cvelistv5 – Published: 2025-11-18 15:14 – Updated: 2025-11-18 21:34
VLAI
EPSS
Title
Race Condition allows Bypass of Trust Restrictions
Summary
In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)
Severity
CWE
- CWE-362 - Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')
Assigner
References
1 reference
Impacted products
1 product
| Vendor | Product | Version | |
|---|---|---|---|
| Eclipse Foundation | Jersey |
Affected:
2.45
Affected: 3.0.16 Affected: 3.1.9 |
Credits
Dimitri Tenenbaum
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2025-12383",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-11-18T21:34:28.248675Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-11-18T21:34:35.027Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Jersey",
"repo": "https://github.com/eclipse-ee4j/jersey",
"vendor": "Eclipse Foundation",
"versions": [
{
"status": "affected",
"version": "2.45"
},
{
"status": "affected",
"version": "3.0.16"
},
{
"status": "affected",
"version": "3.1.9"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "Dimitri Tenenbaum"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)"
}
],
"value": "In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)"
}
],
"metrics": [
{
"cvssV4_0": {
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"attackComplexity": "HIGH",
"attackRequirements": "PRESENT",
"attackVector": "NETWORK",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"exploitMaturity": "NOT_DEFINED",
"privilegesRequired": "NONE",
"providerUrgency": "NOT_DEFINED",
"subAvailabilityImpact": "NONE",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"userInteraction": "NONE",
"valueDensity": "NOT_DEFINED",
"vectorString": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"version": "4.0",
"vulnAvailabilityImpact": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnerabilityResponseEffort": "NOT_DEFINED"
},
"format": "CVSS",
"scenarios": [
{
"lang": "en",
"value": "GENERAL"
}
]
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-362",
"description": "CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization (\u0027Race Condition\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-11-18T15:14:37.765Z",
"orgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"shortName": "eclipse"
},
"references": [
{
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/74"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Race Condition allows Bypass of Trust Restrictions",
"x_generator": {
"engine": "Vulnogram 0.5.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "e51fbebd-6053-4e49-959f-1b94eeb69a2c",
"assignerShortName": "eclipse",
"cveId": "CVE-2025-12383",
"datePublished": "2025-11-18T15:14:37.765Z",
"dateReserved": "2025-10-28T10:21:45.989Z",
"dateUpdated": "2025-11-18T21:34:35.027Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2025-48924 (GCVE-0-2025-48924)
Vulnerability from cvelistv5 – Published: 2025-07-11 14:56 – Updated: 2025-11-04 22:06
VLAI
EPSS
Title
Apache Commons Lang, Apache Commons Lang: ClassUtils.getClass(...) can throw a StackOverflowError on very long inputs
Summary
Uncontrolled Recursion vulnerability in Apache Commons Lang.
This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.
The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a
StackOverflowError could cause an application to stop.
Users are recommended to upgrade to version 3.18.0, which fixes the issue.
Severity
No CVSS data available.
CWE
- CWE-674 - Uncontrolled Recursion
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://lists.apache.org/thread/bgv0lpswokgol11tl… | vendor-advisory |
Impacted products
2 products
| Vendor | Product | Version | |
|---|---|---|---|
| Apache Software Foundation | Apache Commons Lang |
Affected:
2.0 , ≤ 2.6
(maven)
|
|
| Apache Software Foundation | Apache Commons Lang |
Affected:
3.0 , < 3.18.0
(maven)
|
Credits
OSS-Fuzz Issue 42522972
{
"containers": {
"adp": [
{
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "LOW",
"baseScore": 5.3,
"baseSeverity": "MEDIUM",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"version": "3.1"
}
},
{
"other": {
"content": {
"id": "CVE-2025-48924",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2025-07-14T16:36:59.432024Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2025-07-14T16:37:02.057Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
},
{
"providerMetadata": {
"dateUpdated": "2025-11-04T22:06:40.023Z",
"orgId": "af854a3a-2127-422b-91ae-364da2661108",
"shortName": "CVE"
},
"references": [
{
"url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00032.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00026.html"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00000.html"
},
{
"url": "http://www.openwall.com/lists/oss-security/2025/07/11/1"
},
{
"url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00036.html"
}
],
"title": "CVE Program Container"
}
],
"cna": {
"affected": [
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unknown",
"packageName": "commons-lang:commons-lang",
"product": "Apache Commons Lang",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThanOrEqual": "2.6",
"status": "affected",
"version": "2.0",
"versionType": "maven"
}
]
},
{
"collectionURL": "https://repo.maven.apache.org/maven2",
"defaultStatus": "unaffected",
"packageName": "org.apache.commons:commons-lang3",
"product": "Apache Commons Lang",
"vendor": "Apache Software Foundation",
"versions": [
{
"lessThan": "3.18.0",
"status": "affected",
"version": "3.0",
"versionType": "maven"
}
]
}
],
"credits": [
{
"lang": "en",
"type": "finder",
"value": "OSS-Fuzz Issue 42522972"
}
],
"descriptions": [
{
"lang": "en",
"supportingMedia": [
{
"base64": false,
"type": "text/html",
"value": "\u003cp\u003eUncontrolled Recursion vulnerability in Apache Commons Lang.\u003c/p\u003e\u003cp\u003eThis issue affects Apache Commons Lang: Starting with\u0026nbsp;\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003ecommons-lang:commons-lang\u0026nbsp;\u003c/span\u003e2.0 to 2.6, and, from org.apache.\u003cspan style=\"background-color: rgb(255, 255, 255);\"\u003ecommons:commons-lang3 3.0 before\u0026nbsp;\u003c/span\u003e3.18.0.\u003c/p\u003e\u003cp\u003eThe methods ClassUtils.getClass(...) can throw\u0026nbsp;StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a \nStackOverflowError could\u0026nbsp;cause an application to stop.\u003c/p\u003e\u003cp\u003eUsers are recommended to upgrade to version 3.18.0, which fixes the issue.\u003c/p\u003e"
}
],
"value": "Uncontrolled Recursion vulnerability in Apache Commons Lang.\n\nThis issue affects Apache Commons Lang: Starting with\u00a0commons-lang:commons-lang\u00a02.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before\u00a03.18.0.\n\nThe methods ClassUtils.getClass(...) can throw\u00a0StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a \nStackOverflowError could\u00a0cause an application to stop.\n\nUsers are recommended to upgrade to version 3.18.0, which fixes the issue."
}
],
"metrics": [
{
"other": {
"content": {
"text": "low"
},
"type": "Textual description of severity"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-674",
"description": "CWE-674 Uncontrolled Recursion",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2025-07-11T14:56:58.049Z",
"orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"shortName": "apache"
},
"references": [
{
"tags": [
"vendor-advisory"
],
"url": "https://lists.apache.org/thread/bgv0lpswokgol11tloxnjfzdl7yrc1g1"
}
],
"source": {
"discovery": "UNKNOWN"
},
"title": "Apache Commons Lang, Apache Commons Lang: ClassUtils.getClass(...) can throw a StackOverflowError on very long inputs",
"x_generator": {
"engine": "Vulnogram 0.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
"assignerShortName": "apache",
"cveId": "CVE-2025-48924",
"datePublished": "2025-07-11T14:56:58.049Z",
"dateReserved": "2025-05-28T15:06:51.476Z",
"dateUpdated": "2025-11-04T22:06:40.023Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
CVE-2026-42583 (GCVE-0-2026-42583)
Vulnerability from cvelistv5 – Published: 2026-05-13 18:09 – Updated: 2026-05-14 15:41
VLAI
EPSS
Title
Netty: Lz4FrameDecoder resource exhaustion
Summary
Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.
Severity
7.5 (High)
CWE
Assigner
References
1 reference
| URL | Tags |
|---|---|
| https://github.com/netty/netty/security/advisorie… | x_refsource_CONFIRM |
Impacted products
3 products
| Vendor | Product | Version | |
|---|---|---|---|
| netty | netty |
Affected:
>= 4.2.0.Alpha1, < 4.2.13.Final
Affected: < 4.1.133.Final |
|
| io.netty | netty-codec |
Affected:
< 4.1.133.Final
|
|
| io.netty | netty-codec-compression |
Affected:
< 4.2.13.Final
|
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42583",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "yes"
},
{
"Technical Impact": "partial"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-14T15:40:38.960180Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-14T15:41:07.253Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "netty",
"vendor": "netty",
"versions": [
{
"status": "affected",
"version": "\u003e= 4.2.0.Alpha1, \u003c 4.2.13.Final"
},
{
"status": "affected",
"version": "\u003c 4.1.133.Final"
}
]
},
{
"product": "netty-codec",
"vendor": "io.netty",
"versions": [
{
"status": "affected",
"version": "\u003c 4.1.133.Final"
}
]
},
{
"product": "netty-codec-compression",
"vendor": "io.netty",
"versions": [
{
"status": "affected",
"version": "\u003c 4.2.13.Final"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 7.5,
"baseSeverity": "HIGH",
"confidentialityImpact": "NONE",
"integrityImpact": "NONE",
"privilegesRequired": "NONE",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-400",
"description": "CWE-400: Uncontrolled Resource Consumption",
"lang": "en",
"type": "CWE"
}
]
},
{
"descriptions": [
{
"cweId": "CWE-770",
"description": "CWE-770: Allocation of Resources Without Limits or Throttling",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-13T18:09:19.817Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/netty/netty/security/advisories/GHSA-mj4r-2hfc-f8p6"
}
],
"source": {
"advisory": "GHSA-mj4r-2hfc-f8p6",
"discovery": "UNKNOWN"
},
"title": "Netty: Lz4FrameDecoder resource exhaustion"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-42583",
"datePublished": "2026-05-13T18:09:19.817Z",
"dateReserved": "2026-04-28T17:26:12.086Z",
"dateUpdated": "2026-05-14T15:41:07.253Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
GHSA-72HV-8253-57QQ
Vulnerability from github – Published: 2026-02-28 02:01 – Updated: 2026-04-07 16:30
VLAI
Summary
jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition
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 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);
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
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.18.5"
},
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.18.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-28T02:01:05Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nThe 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).\n\nThe standard synchronous parser correctly enforces this limit, but the async parser fails to do so, creating an inconsistent enforcement policy.\n\n### Details\nThe root cause is that the async parsing path in `NonBlockingUtf8JsonParserBase` (and related classes) does not call the methods responsible for number length validation.\n\n- The number parsing methods (e.g., `_finishNumberIntegralPart`) accumulate digits into the `TextBuffer` without any length checks.\n- After parsing, they call `_valueComplete()`, which finalizes the token but does **not** call `resetInt()` or `resetFloat()`.\n- The `resetInt()`/`resetFloat()` methods in `ParserBase` are where the `validateIntegerLength()` and `validateFPLength()` checks are performed.\n- Because this validation step is skipped, the `maxNumberLength` constraint is never enforced in the async code path.\n\n### PoC\nThe 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.\n\n```java\npackage tools.jackson.core.unittest.dos;\n\nimport java.nio.charset.StandardCharsets;\n\nimport org.junit.jupiter.api.Test;\n\nimport tools.jackson.core.*;\nimport tools.jackson.core.exc.StreamConstraintsException;\nimport tools.jackson.core.json.JsonFactory;\nimport tools.jackson.core.json.async.NonBlockingByteArrayJsonParser;\n\nimport static org.junit.jupiter.api.Assertions.*;\n\n/**\n * POC: Number Length Constraint Bypass in Non-Blocking (Async) JSON Parsers\n *\n * Authors: sprabhav7, rohan-repos\n * \n * maxNumberLength default = 1000 characters (digits).\n * A number with more than 1000 digits should be rejected by any parser.\n *\n * BUG: The async parser never calls resetInt()/resetFloat() which is where\n * validateIntegerLength()/validateFPLength() lives. Instead it calls\n * _valueComplete() which skips all number length validation.\n *\n * CWE-770: Allocation of Resources Without Limits or Throttling\n */\nclass AsyncParserNumberLengthBypassTest {\n\n private static final int MAX_NUMBER_LENGTH = 1000;\n private static final int TEST_NUMBER_LENGTH = 5000;\n\n private final JsonFactory factory = new JsonFactory();\n\n // CONTROL: Sync parser correctly rejects a number exceeding maxNumberLength\n @Test\n void syncParserRejectsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\t\t\n\t\t// Output to console\n System.out.println(\"[SYNC] Parsing \" + TEST_NUMBER_LENGTH + \"-digit number (limit: \" + MAX_NUMBER_LENGTH + \")\");\n try {\n try (JsonParser p = factory.createParser(ObjectReadContext.empty(), payload)) {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n System.out.println(\"[SYNC] Accepted number with \" + p.getText().length() + \" digits \u2014 UNEXPECTED\");\n }\n }\n }\n fail(\"Sync parser must reject a \" + TEST_NUMBER_LENGTH + \"-digit number\");\n } catch (StreamConstraintsException e) {\n System.out.println(\"[SYNC] Rejected with StreamConstraintsException: \" + e.getMessage());\n }\n }\n\n // VULNERABILITY: Async parser accepts the SAME number that sync rejects\n @Test\n void asyncParserAcceptsLongNumber() throws Exception {\n byte[] payload = buildPayloadWithLongInteger(TEST_NUMBER_LENGTH);\n\n NonBlockingByteArrayJsonParser p =\n (NonBlockingByteArrayJsonParser) factory.createNonBlockingByteArrayParser(ObjectReadContext.empty());\n p.feedInput(payload, 0, payload.length);\n p.endOfInput();\n\n boolean foundNumber = false;\n try {\n while (p.nextToken() != null) {\n if (p.currentToken() == JsonToken.VALUE_NUMBER_INT) {\n foundNumber = true;\n String numberText = p.getText();\n assertEquals(TEST_NUMBER_LENGTH, numberText.length(),\n \"Async parser silently accepted all \" + TEST_NUMBER_LENGTH + \" digits\");\n }\n }\n // Output to console\n System.out.println(\"[ASYNC INT] Accepted number with \" + TEST_NUMBER_LENGTH + \" digits \u2014 BUG CONFIRMED\");\n assertTrue(foundNumber, \"Parser should have produced a VALUE_NUMBER_INT token\");\n } catch (StreamConstraintsException e) {\n fail(\"Bug is fixed \u2014 async parser now correctly rejects long numbers: \" + e.getMessage());\n }\n p.close();\n }\n\n private byte[] buildPayloadWithLongInteger(int numDigits) {\n StringBuilder sb = new StringBuilder(numDigits + 10);\n sb.append(\"{\\\"v\\\":\");\n for (int i = 0; i \u003c numDigits; i++) {\n sb.append((char) (\u00271\u0027 + (i % 9)));\n }\n sb.append(\u0027}\u0027);\n return sb.toString().getBytes(StandardCharsets.UTF_8);\n }\n}\n\n```\n\n\n### Impact\nA 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:\n1. **Memory Exhaustion:** Unbounded allocation of memory in the `TextBuffer` to store the number\u0027s digits, leading to an `OutOfMemoryError`.\n2. **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.\n\n### Suggested Remediation\n\nThe 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.\n\n**NOTE:** This research was performed in collaboration with [rohan-repos](https://github.com/rohan-repos)",
"id": "GHSA-72hv-8253-57qq",
"modified": "2026-04-07T16:30:17Z",
"published": "2026-02-28T02:01:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-72hv-8253-57qq"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/1555"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/b0c428e6f993e1b5ece5c1c3cb2523e887cd52cf"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "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",
"type": "CVSS_V4"
}
],
"summary": "jackson-core: Number Length Constraint Bypass in Async Parser Leads to Potential DoS Condition"
}
GHSA-7P63-W6X9-6GR7
Vulnerability from github – Published: 2025-11-18 18:32 – Updated: 2026-02-05 15:43
VLAI
Summary
Eclipse Jersey has a Race Condition
Details
In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.glassfish.jersey.core:jersey-client"
},
"ranges": [
{
"events": [
{
"introduced": "2.45"
},
{
"fixed": "2.46"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.45"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.glassfish.jersey.core:jersey-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.16"
},
{
"fixed": "3.0.17"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.0.16"
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.glassfish.jersey.core:jersey-client"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.9"
},
{
"fixed": "3.1.10"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.1.9"
]
}
],
"aliases": [
"CVE-2025-12383"
],
"database_specific": {
"cwe_ids": [
"CWE-296",
"CWE-362"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-18T20:38:31Z",
"nvd_published_at": "2025-11-18T16:15:42Z",
"severity": "CRITICAL"
},
"details": "In Eclipse Jersey versions 2.45, 3.0.16, 3.1.9 a race condition can cause ignoring of critical SSL configurations - such as mutual authentication, custom key/trust stores, and other security settings. This issue may result in SSLHandshakeException under normal circumstances, but under certain conditions, it could lead to unauthorized trust in insecure servers (see PoC)",
"id": "GHSA-7p63-w6x9-6gr7",
"modified": "2026-02-05T15:43:36Z",
"published": "2025-11-18T18:32:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12383"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/pull/5749"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/pull/5794"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/commit/425bc883d8d623ef8d3c448fafd36729f7741bcb"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/commit/b2c7ba6d388cb9722f39073d7e82aa818fec49d5"
},
{
"type": "WEB",
"url": "https://github.com/dtbaum/jerseyCveCandidate"
},
{
"type": "PACKAGE",
"url": "https://github.com/eclipse-ee4j/jersey"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/2.46"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/3.0.17"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/3.1.10"
},
{
"type": "WEB",
"url": "https://github.com/eclipse-ee4j/jersey/releases/tag/4.0.0-M2"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/cve-assignment/-/issues/74"
},
{
"type": "WEB",
"url": "https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/253"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Eclipse Jersey has a Race Condition"
}
GHSA-J288-Q9X7-2F5V
Vulnerability from github – Published: 2025-07-11 15:31 – Updated: 2025-11-05 20:30
VLAI
Summary
Apache Commons Lang is vulnerable to Uncontrolled Recursion when processing long inputs
Details
Uncontrolled Recursion vulnerability in Apache Commons Lang.
This issue affects Apache Commons Lang: Starting with commons-lang:commons-lang 2.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before 3.18.0.
The methods ClassUtils.getClass(...) can throw StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could cause an application to stop.
Users are recommended to upgrade to version 3.18.0, which fixes the issue.
Severity
6.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.commons:commons-lang3"
},
"ranges": [
{
"events": [
{
"introduced": "3.0"
},
{
"fixed": "3.18.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "commons-lang:commons-lang"
},
"ranges": [
{
"events": [
{
"introduced": "2.0"
},
{
"last_affected": "2.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-48924"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2025-07-12T00:48:03Z",
"nvd_published_at": "2025-07-11T15:15:24Z",
"severity": "MODERATE"
},
"details": "Uncontrolled Recursion vulnerability in Apache Commons Lang.\n\nThis issue affects Apache Commons Lang: Starting with\u00a0commons-lang:commons-lang\u00a02.0 to 2.6, and, from org.apache.commons:commons-lang3 3.0 before\u00a03.18.0.\n\nThe methods ClassUtils.getClass(...) can throw\u00a0StackOverflowError on very long inputs. Because an Error is usually not handled by applications and libraries, a StackOverflowError could\u00a0cause an application to stop.\n\nUsers are recommended to upgrade to version 3.18.0, which fixes the issue.",
"id": "GHSA-j288-q9x7-2f5v",
"modified": "2025-11-05T20:30:31Z",
"published": "2025-07-11T15:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48924"
},
{
"type": "WEB",
"url": "https://github.com/apache/commons-lang/commit/b424803abdb2bec818e4fbcb251ce031c22aca53"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-lang"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/bgv0lpswokgol11tloxnjfzdl7yrc1g1"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00000.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/08/msg00026.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00032.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/09/msg00036.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2025/07/11/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Apache Commons Lang is vulnerable to Uncontrolled Recursion when processing long inputs"
}
Loading…
Trend slope:
-
(linear fit over daily sighting counts)
Show additional events:
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…