Action not permitted
Modal body text goes here.
Modal Title
Modal Body
Vulnerability from cleanstart
Published
2026-07-30 07:10
Modified
2026-07-30 09:36
Summary
Security fixes in orientdb 3.2.38-r0
Details
Package orientdb version 3.2.38-r0 fixes 10 vulnerabilities: ghsa-78wr-2p64-hpwj, ghsa-8xfc-gm6g-vgpv, ghsa-4h8f-2wvx-gg5w, ghsa-v435-xc8x-wvr9, ghsa-m44j-cfrm-g8qc...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "orientdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.2.38-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.2.38-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package orientdb version 3.2.38-r0 fixes 10 vulnerabilities: ghsa-78wr-2p64-hpwj, ghsa-8xfc-gm6g-vgpv, ghsa-4h8f-2wvx-gg5w, ghsa-v435-xc8x-wvr9, ghsa-m44j-cfrm-g8qc...",
"id": "CLEANSTART-2026-ZL33696",
"modified": "2026-07-30T09:36:13Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/orientechnologies/orientdb"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in orientdb 3.2.38-r0",
"upstream": [
"ghsa-78wr-2p64-hpwj",
"ghsa-8xfc-gm6g-vgpv",
"ghsa-4h8f-2wvx-gg5w",
"ghsa-v435-xc8x-wvr9",
"ghsa-m44j-cfrm-g8qc",
"ghsa-67mf-3cr5-8w23",
"ghsa-4cx2-fc23-5wg6",
"ghsa-h46c-h94j-95f3",
"ghsa-wf8f-6423-gfxg",
"ghsa-72hv-8253-57qq"
]
}
GHSA-4CX2-FC23-5WG6
Vulnerability from github – Published: 2025-08-13 12:31 – Updated: 2026-05-13 16:23
VLAI
Summary
Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation
Details
Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java .
This issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.44"
},
{
"fixed": "1.79"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-fips"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.8"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.0.7"
},
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcpkix-fips"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.8"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-8916"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-13T22:52:42Z",
"nvd_published_at": "2025-08-13T10:15:27Z",
"severity": "MODERATE"
},
"details": "Allocation of Resources Without Limits or Throttling vulnerability in Legion of the Bouncy Castle Inc. Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation. This vulnerability is associated with program files https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertP... https://github.Com/bcgit/bc-java/blob/main/pkix/src/main/java/org/bouncycastle/pkix/jcajce/PKIXCertPathReviewer.java , https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathRevi... https://github.Com/bcgit/bc-java/blob/main/prov/src/main/java/org/bouncycastle/x509/PKIXCertPathReviewer.java .\n\nThis issue affects Bouncy Castle for Java: from BC 1.44 through 1.78, from BCPKIX FIPS 1.0.0 through 1.0.7, from BCPKIX FIPS 2.0.0 through 2.0.7.",
"id": "GHSA-4cx2-fc23-5wg6",
"modified": "2026-05-13T16:23:20Z",
"published": "2025-08-13T12:31:30Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8916"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/310b30a4fbf36d13f6cc201ffa7771715641e67e"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/ff444a479942d88de64004dc82c3ee32a9e9075a"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-032379.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%908916"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/S:P/R:U/RE:M/U:Amber",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle for Java bcpkix, bcprov, bcpkix-fips on All (API modules) allows Excessive Allocation"
}
GHSA-4H8F-2WVX-GG5W
Vulnerability from github – Published: 2024-05-03 18:30 – Updated: 2026-04-17 13:22
VLAI
Summary
Bouncy Castle Java Cryptography API vulnerable to DNS poisoning
Details
An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.
Severity
5.9 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.61"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.61"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.61"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk12"
},
"ranges": [
{
"events": [
{
"introduced": "1.61"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-lts8on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.73.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "1.61"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-34447"
],
"database_specific": {
"cwe_ids": [
"CWE-297"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-03T20:34:32Z",
"nvd_published_at": "2024-05-03T16:15:11Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the Bouncy Castle Crypto Package For Java before BC TLS Java 1.0.19 (ships with BC Java 1.78, BC Java (LTS) 2.73.6) and before BC FIPS TLS Java 1.0.19. When endpoint identification is enabled in the BCJSSE and an SSL socket is created without an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address in some situations, opening up a possibility of DNS poisoning.",
"id": "GHSA-4h8f-2wvx-gg5w",
"modified": "2026-04-17T13:22:45Z",
"published": "2024-05-03T18:30:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-34447"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/issues/1656"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902024%E2%80%9034447"
},
{
"type": "WEB",
"url": "https://www.bouncycastle.org/latest_releases.html"
},
{
"type": "WEB",
"url": "http://security.netapp.com/advisory/ntap-20240614-0007"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Bouncy Castle Java Cryptography API vulnerable to DNS poisoning"
}
GHSA-67MF-3CR5-8W23
Vulnerability from github – Published: 2025-08-12 12:30 – Updated: 2025-09-03 13:04
VLAI
Summary
Bouncy Castle for Java on All (API modules) allows Excessive Allocation
Details
A resource allocation vulnerability exists in Bouncy Castle for Java (by Legion of the Bouncy Castle Inc.) that affects all API modules. The vulnerability allows attackers to cause excessive memory allocation through unbounded resource consumption, potentially leading to denial of service. The issue is located in the ASN1ObjectIdentifier.java file in the core module.
This issue affects Bouncy Castle for Java: from BC 1.0 through 1.77, from BC-FJA 1.0.0 through 2.0.0.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bc-fips"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.0.2.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bc-fips"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.0.1"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"2.0.0"
]
}
],
"aliases": [
"CVE-2025-8885"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2025-08-12T19:36:18Z",
"nvd_published_at": "2025-08-12T10:15:26Z",
"severity": "MODERATE"
},
"details": "A resource allocation vulnerability exists in Bouncy Castle for Java (by Legion of the Bouncy Castle Inc.) that affects all API modules. The vulnerability allows attackers to cause excessive memory allocation through unbounded resource consumption, potentially leading to denial of service. The issue is located in the ASN1ObjectIdentifier.java file in the core module.\n\nThis issue affects Bouncy Castle for Java: from BC 1.0 through 1.77, from BC-FJA 1.0.0 through 2.0.0.",
"id": "GHSA-67mf-3cr5-8w23",
"modified": "2025-09-03T13:04:19Z",
"published": "2025-08-12T12:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8885"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/3790993df5d28f661a64439a8664343437ed3865"
},
{
"type": "PACKAGE",
"url": "https://github.com/bcgit/bc-java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/blob/main/core/src/main/java/org/bouncycastle/asn1/ASN1ObjectIdentifier.java"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902025%E2%80%908885"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/S:P/R:U/RE:M/U:Amber",
"type": "CVSS_V4"
}
],
"summary": "Bouncy Castle for Java on All (API modules) allows Excessive Allocation"
}
GHSA-72HV-8253-57QQ
Vulnerability from github – Published: 2026-02-28 02:01 – Updated: 2026-08-03 20:32
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.15.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-08-03T20:32:01Z",
"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-78WR-2P64-HPWJ
Vulnerability from github – Published: 2024-10-03 12:30 – Updated: 2025-01-31 15:30
VLAI
Summary
Apache Commons IO: Possible denial of service attack on untrusted input to XmlStreamReader
Details
Uncontrolled Resource Consumption vulnerability in Apache Commons IO.
The org.apache.commons.io.input.XmlStreamReader class may excessively consume CPU resources when processing maliciously crafted input.
This issue affects Apache Commons IO: from 2.0 before 2.14.0.
Users are recommended to upgrade to version 2.14.0 or later, which fixes the issue.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "commons-io:commons-io"
},
"ranges": [
{
"events": [
{
"introduced": "2.0"
},
{
"fixed": "2.14.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-47554"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-10-03T16:52:23Z",
"nvd_published_at": "2024-10-03T12:15:02Z",
"severity": "HIGH"
},
"details": "Uncontrolled Resource Consumption vulnerability in Apache Commons IO.\n\nThe `org.apache.commons.io.input.XmlStreamReader` class may excessively consume CPU resources when processing maliciously crafted input.\n\n\nThis issue affects Apache Commons IO: from 2.0 before 2.14.0.\n\nUsers are recommended to upgrade to version 2.14.0 or later, which fixes the issue.",
"id": "GHSA-78wr-2p64-hpwj",
"modified": "2025-01-31T15:30:42Z",
"published": "2024-10-03T12:30:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-47554"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-io"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/6ozr91rr9cj5lm0zyhv30bsp317hk5z1"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250131-0010"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/10/03/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Apache Commons IO: Possible denial of service attack on untrusted input to XmlStreamReader"
}
GHSA-8XFC-GM6G-VGPV
Vulnerability from github – Published: 2024-05-14 15:32 – Updated: 2024-12-06 15:31
VLAI
Summary
Bouncy Castle certificate parsing issues cause high CPU usage during parameter evaluation.
Details
An issue was discovered in ECCurve.java and ECCurve.cs in Bouncy Castle Java (BC Java) before 1.78, BC Java LTS before 2.73.6, BC-FJA before 1.0.2.5, and BC C# .Net before 2.3.1. Importing an EC certificate with crafted F2m parameters can lead to excessive CPU consumption during the evaluation of the curve parameters.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bc-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.2.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2.3.1"
},
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle.Cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-29857"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-14T20:22:01Z",
"nvd_published_at": "2024-05-14T15:17:02Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in ECCurve.java and ECCurve.cs in Bouncy Castle Java (BC Java) before 1.78, BC Java LTS before 2.73.6, BC-FJA before 1.0.2.5, and BC C# .Net before 2.3.1. Importing an EC certificate with crafted F2m parameters can lead to excessive CPU consumption during the evaluation of the curve parameters.",
"id": "GHSA-8xfc-gm6g-vgpv",
"modified": "2024-12-06T15:31:20Z",
"published": "2024-05-14T15:32:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-29857"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/commit/56daa6eac526f165416d17f661422d60de0dfd63"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/efc498ca4caa340ac2fe11f2efee06c1a294501f"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/fee80dd230e7fba132d03a34f1dd1d6aae0d0281"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/wiki/CVE%E2%80%902024%E2%80%9029857"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902024%E2%80%9029857"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241206-0008"
},
{
"type": "WEB",
"url": "https://www.bouncycastle.org/latest_releases.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
],
"summary": "Bouncy Castle certificate parsing issues cause high CPU usage during parameter evaluation."
}
GHSA-H46C-H94J-95F3
Vulnerability from github – Published: 2025-06-27 15:22 – Updated: 2025-06-27 15:22
VLAI
Summary
jackson-core can throw a StackoverflowError when processing deeply nested data
Details
Impact
With older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large.
Patches
jackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached. jackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs.
Workarounds
Users should avoid parsing input files from untrusted sources.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.15.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-52999"
],
"database_specific": {
"cwe_ids": [
"CWE-121"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-27T15:22:22Z",
"nvd_published_at": "2025-06-25T17:15:39Z",
"severity": "HIGH"
},
"details": "### Impact\nWith older versions of jackson-core, if you parse an input file and it has deeply nested data, Jackson could end up throwing a StackoverflowError if the depth is particularly large.\n\n### Patches\njackson-core 2.15.0 contains a configurable limit for how deep Jackson will traverse in an input document, defaulting to an allowable depth of 1000. Change is in https://github.com/FasterXML/jackson-core/pull/943. jackson-core will throw a StreamConstraintsException if the limit is reached.\njackson-databind also benefits from this change because it uses jackson-core to parse JSON inputs.\n\n### Workarounds\nUsers should avoid parsing input files from untrusted sources.",
"id": "GHSA-h46c-h94j-95f3",
"modified": "2025-06-27T15:22:22Z",
"published": "2025-06-27T15:22:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-h46c-h94j-95f3"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-52999"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/943"
},
{
"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:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "jackson-core can throw a StackoverflowError when processing deeply nested data"
}
GHSA-M44J-CFRM-G8QC
Vulnerability from github – Published: 2024-05-14 15:32 – Updated: 2024-12-02 16:27
VLAI
Summary
Bouncy Castle crafted signature and public key can be used to trigger an infinite loop
Details
An issue was discovered in Bouncy Castle Java Cryptography APIs starting in 1.73 and before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.73"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.73"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.73"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "1.73"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "1.73"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "1.73"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2.3.1"
},
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle.Cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-30172"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-14T20:22:06Z",
"nvd_published_at": "2024-05-14T15:21:53Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Bouncy Castle Java Cryptography APIs starting in 1.73 and before 1.78. An Ed25519 verification code infinite loop can occur via a crafted signature and public key.",
"id": "GHSA-m44j-cfrm-g8qc",
"modified": "2024-12-02T16:27:23Z",
"published": "2024-05-14T15:32:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30172"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/1b9fd9b545e691bfb3941a9f6a797660c8860f02"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/9c165791b68a204678b48ec11e4e579754c2ea49"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/ebe1c75579170072dc59b8dee2b55ce31663178f"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/wiki/CVE%E2%80%902024%E2%80%9030172"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902024%E2%80%9030172"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240614-0007"
},
{
"type": "WEB",
"url": "https://www.bouncycastle.org/latest_releases.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
},
{
"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": "Bouncy Castle crafted signature and public key can be used to trigger an infinite loop"
}
GHSA-V435-XC8X-WVR9
Vulnerability from github – Published: 2024-05-14 15:32 – Updated: 2024-09-09 21:27
VLAI
Summary
Bouncy Castle affected by timing side-channel for RSA key exchange ("The Marvin Attack")
Details
An issue was discovered in Bouncy Castle Java TLS API and JSSE Provider before 1.78. Timing-based leakage may occur in RSA based handshakes because of exception processing.
Severity
5.9 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-fips"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.19"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bcprov-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk18on"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk14"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.bouncycastle:bctls-jdk15to18"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.78"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2.3.1"
},
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "NuGet",
"name": "BouncyCastle.Cryptography"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-30171"
],
"database_specific": {
"cwe_ids": [
"CWE-203"
],
"github_reviewed": true,
"github_reviewed_at": "2024-05-14T20:22:03Z",
"nvd_published_at": "2024-05-14T15:21:52Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Bouncy Castle Java TLS API and JSSE Provider before 1.78. Timing-based leakage may occur in RSA based handshakes because of exception processing.",
"id": "GHSA-v435-xc8x-wvr9",
"modified": "2024-09-09T21:27:50Z",
"published": "2024-05-14T15:32:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30171"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/commit/c984b8bfd8544dfc55dba91a02cbbbb9c580c217"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/d7d5e735abd64bf0f413f54fd9e495fc02400fb0"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/commit/e0569dcb1dea9d421d84fc4c5c5688fe101afa2d"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-csharp/wiki/CVE%E2%80%902024%E2%80%9030171"
},
{
"type": "WEB",
"url": "https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902024%E2%80%9030171"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240614-0008"
},
{
"type": "WEB",
"url": "https://www.bouncycastle.org/latest_releases.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Bouncy Castle affected by timing side-channel for RSA key exchange (\"The Marvin Attack\")"
}
GHSA-WF8F-6423-GFXG
Vulnerability from github – Published: 2025-06-07 00:10 – Updated: 2025-06-07 00:33
VLAI
Summary
Jackson-core Vulnerable to Memory Disclosure via Source Snippet in JsonLocation
Details
Overview
A flaw in Jackson-core's JsonLocation._appendSourceDesc method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible information disclosure in systems using pooled or reused buffers, like Netty or Vert.x.
Details
The vulnerability affects the creation of exception messages like:
JsonParseException: Unexpected character ... at [Source: (byte[])...]
When JsonFactory.createParser(byte[] data, int offset, int len) is used, and an error occurs while parsing, the exception message should include a snippet from the specified logical payload. However, the method _appendSourceDesc ignores the offset, and always starts reading from index 0.
If the buffer contains residual sensitive data from a previous request, such as credentials or document contents, that data may be exposed if the exception is propagated to the client.
The issue particularly impacts server applications using:
- Pooled byte buffers (e.g., Netty)
- Frameworks that surface parse errors in HTTP responses
- Default Jackson settings (i.e.,
INCLUDE_SOURCE_IN_LOCATIONis enabled)
A documented real-world example is CVE-2021-22145 in Elasticsearch, which stemmed from the same root cause.
Attack Scenario
An attacker sends malformed JSON to a service using Jackson and pooled byte buffers (e.g., Netty-based HTTP servers). If the server reuses a buffer and includes the parser’s exception in its HTTP 400 response, the attacker may receive residual data from previous requests.
Proof of Concept
byte[] buffer = new byte[1000];
System.arraycopy("SECRET".getBytes(), 0, buffer, 0, 6);
System.arraycopy("{ \"bad\": }".getBytes(), 0, buffer, 700, 10);
JsonFactory factory = new JsonFactory();
JsonParser parser = factory.createParser(buffer, 700, 20);
parser.nextToken(); // throws exception
// Exception message will include "SECRET"
Patches
This issue was silently fixed in jackson-core version 2.13.0, released on September 30, 2021, via PR #652.
All users should upgrade to version 2.13.0 or later.
Workarounds
If upgrading is not immediately possible, applications can mitigate the issue by:
- Disabling exception message exposure to clients — avoid returning parsing exception messages in HTTP responses.
- Disabling source inclusion in exceptions by setting:
java
jsonFactory.disable(JsonFactory.Feature.INCLUDE_SOURCE_IN_LOCATION);
This prevents Jackson from embedding any source content in exception messages, avoiding leakage.
References
Severity
4.0 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-core"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.13.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-49128"
],
"database_specific": {
"cwe_ids": [
"CWE-209"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-07T00:10:42Z",
"nvd_published_at": "2025-06-06T22:15:23Z",
"severity": "MODERATE"
},
"details": "### Overview\n\nA flaw in Jackson-core\u0027s `JsonLocation._appendSourceDesc` method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible **information disclosure** in systems using **pooled or reused buffers**, like Netty or Vert.x.\n\n### Details\n\nThe vulnerability affects the creation of exception messages like:\n\n```\nJsonParseException: Unexpected character ... at [Source: (byte[])...]\n```\n\nWhen `JsonFactory.createParser(byte[] data, int offset, int len)` is used, and an error occurs while parsing, the exception message should include a snippet from the specified logical payload. However, the method `_appendSourceDesc` ignores the `offset`, and always starts reading from index `0`.\n\nIf the buffer contains residual sensitive data from a previous request, such as credentials or document contents, that data may be exposed if the exception is propagated to the client.\n\nThe issue particularly impacts server applications using:\n\n* Pooled byte buffers (e.g., Netty)\n* Frameworks that surface parse errors in HTTP responses\n* Default Jackson settings (i.e., `INCLUDE_SOURCE_IN_LOCATION` is enabled)\n\nA documented real-world example is [CVE-2021-22145](https://nvd.nist.gov/vuln/detail/CVE-2021-22145) in Elasticsearch, which stemmed from the same root cause.\n\n### Attack Scenario\n\nAn attacker sends malformed JSON to a service using Jackson and pooled byte buffers (e.g., Netty-based HTTP servers). If the server reuses a buffer and includes the parser\u2019s exception in its HTTP 400 response, the attacker may receive residual data from previous requests.\n\n### Proof of Concept\n\n```java\nbyte[] buffer = new byte[1000];\nSystem.arraycopy(\"SECRET\".getBytes(), 0, buffer, 0, 6);\nSystem.arraycopy(\"{ \\\"bad\\\": }\".getBytes(), 0, buffer, 700, 10);\n\nJsonFactory factory = new JsonFactory();\nJsonParser parser = factory.createParser(buffer, 700, 20);\nparser.nextToken(); // throws exception\n\n// Exception message will include \"SECRET\"\n```\n\n### Patches\nThis issue was silently fixed in jackson-core version 2.13.0, released on September 30, 2021, via [PR #652](https://github.com/FasterXML/jackson-core/pull/652).\n\nAll users should upgrade to version 2.13.0 or later.\n\n### Workarounds\nIf upgrading is not immediately possible, applications can mitigate the issue by:\n\n1. **Disabling exception message exposure to clients** \u2014 avoid returning parsing exception messages in HTTP responses.\n2. **Disabling source inclusion in exceptions** by setting:\n\n ```java\n jsonFactory.disable(JsonFactory.Feature.INCLUDE_SOURCE_IN_LOCATION);\n ```\n\n This prevents Jackson from embedding any source content in exception messages, avoiding leakage.\n\n\n### References\n* [Pull Request #652 (Fix implementation)](https://github.com/FasterXML/jackson-core/pull/652)\n* [CVE-2021-22145 (Elasticsearch exposure of this flaw)](https://nvd.nist.gov/vuln/detail/CVE-2021-22145)",
"id": "GHSA-wf8f-6423-gfxg",
"modified": "2025-06-07T00:33:54Z",
"published": "2025-06-07T00:10:42Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/security/advisories/GHSA-wf8f-6423-gfxg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22145"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-49128"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/pull/652"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-core/commit/a6c297682737dde13337cb7c3020f299518609a8"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-core"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Jackson-core Vulnerable to Memory Disclosure via Source Snippet in JsonLocation"
}
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…