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:33
Summary
Security fixes in spark-sc213-jdk17-py312 3.5.8-r0
Details
Package spark-sc213-jdk17-py312 version 3.5.8-r0 fixes 74 vulnerabilities: CVE-2026-54515, ghsa-5jmj-h7xm-6q6v, ghsa-337m-mw94-2v6g, CVE-2026-45205, ghsa-2r2c-cx56-8933...
References
| URL | Type | |
|---|---|---|
{
"affected": [
{
"package": {
"ecosystem": "Alpine",
"name": "spark-sc213-jdk17-py312"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.5.8-r0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.5.8-r0"
]
}
],
"credits": [],
"database_specific": {},
"details": "Package spark-sc213-jdk17-py312 version 3.5.8-r0 fixes 74 vulnerabilities: CVE-2026-54515, ghsa-5jmj-h7xm-6q6v, ghsa-337m-mw94-2v6g, CVE-2026-45205, ghsa-2r2c-cx56-8933...",
"id": "CLEANSTART-2026-MG63413",
"modified": "2026-07-30T09:33:48Z",
"published": "2026-07-30T07:10:53Z",
"references": [
{
"type": "WEB",
"url": "https://spark.apache.org"
}
],
"related": [],
"schema_version": "1.7.3",
"summary": "Security fixes in spark-sc213-jdk17-py312 3.5.8-r0",
"upstream": [
"CVE-2026-54515",
"ghsa-5jmj-h7xm-6q6v",
"ghsa-337m-mw94-2v6g",
"CVE-2026-45205",
"ghsa-2r2c-cx56-8933",
"ghsa-47qp-hqvx-6r3f",
"CVE-2018-10237",
"CVE-2023-2976",
"CVE-2020-8908",
"ghsa-mvr2-9pj6-7w5j",
"ghsa-5mg8-w23w-74h3",
"ghsa-7g45-4rm6-3mm3",
"CVE-2025-52999",
"ghsa-72hv-8253-57qq",
"ghsa-h46c-h94j-95f3",
"CVE-2026-54512",
"CVE-2026-54513",
"CVE-2026-54514",
"CVE-2026-54515",
"CVE-2026-6860",
"ghsa-3g76-f9xq-8vp6",
"CVE-2021-0341",
"ghsa-3cqm-mf7h-prrj",
"CVE-2019-0205",
"CVE-2020-13949",
"CVE-2026-43869",
"ghsa-rj7p-rfgp-852x",
"ghsa-g2fg-mr77-6vrm",
"ghsa-7pwc-h2j2-rjgj",
"CVE-2024-25710",
"CVE-2024-26308",
"CVE-2023-42503",
"ghsa-4265-ccf5-phj5",
"ghsa-4g9r-vxhx-9pgx",
"ghsa-cgwf-w82q-5jrr",
"CVE-2024-23953",
"ghsa-p953-3j66-hg45",
"ghsa-2r2c-cx56-8933",
"ghsa-47qp-hqvx-6r3f",
"CVE-2023-25613",
"ghsa-3f7h-mf4q-vrm4",
"CVE-2022-40152",
"CVE-2018-10237",
"CVE-2023-2976",
"ghsa-mvr2-9pj6-7w5j",
"ghsa-5mg8-w23w-74h3",
"ghsa-7g45-4rm6-3mm3",
"CVE-2021-22569",
"CVE-2022-3509",
"CVE-2022-3510",
"CVE-2024-7254",
"CVE-2022-3171",
"CVE-2021-22570",
"ghsa-735f-pc8j-v9w8",
"ghsa-wrvw-hg22-4m67",
"ghsa-4gg5-vx3j-xwc7",
"ghsa-g5ww-5jh7-63cx",
"ghsa-h4h5-3hr4-j3g2",
"CVE-2021-31684",
"CVE-2023-1370",
"ghsa-fg2v-w576-w4v3",
"ghsa-493p-pfq6-5258",
"CVE-2024-29131",
"CVE-2024-29133",
"ghsa-xjp4-hw94-mvp5",
"ghsa-9w38-p64v-xpmv",
"CVE-2024-47554",
"ghsa-78wr-2p64-hpwj",
"CVE-2024-25638",
"ghsa-cfxw-4h78-h7fw",
"CVE-2021-37533",
"ghsa-cgp8-4m63-fhh5",
"CVE-2024-23454",
"ghsa-f5fw-25gw-5m92"
]
}
GHSA-47QP-HQVX-6R3F
Vulnerability from github – Published: 2026-06-18 13:07 – Updated: 2026-07-20 21:21
VLAI
Summary
JLine3 Telnet server: Unauthenticated Remote Memory Exhaustion via Unbounded Telnet NEW-ENVIRON Variables
Details
Summary
The JLine3 Telnet server (remote-telnet module) does not limit the number of
environment variables a client may inject via the Telnet NEW-ENVIRON option. An
unauthenticated attacker can flood the server with a large number of unique
variable pairs before sending the terminating IAC SE byte, exhausting JVM heap
memory and causing an OutOfMemoryError (denial of service). Approximately 3–4 MB of
network traffic is sufficient to consume a 512 MB JVM heap.
Details
TelnetIO.readNEVariables() (TelnetIO.java:1127-1180) processes incoming NEW-ENVIRON
variable pairs in a loop and stores each pair in a HashMap held by ConnectionData:
// TelnetIO.java:1139-1178
boolean cont = true;
if (i == NE_VAR || i == NE_USERVAR) {
do {
switch (readNEVariableName(sbuf)) {
case NE_VAR_OK:
TelnetIO.this.connectionData.getEnvironment().put(str, sbuf.toString());
// ← no per-connection count limit
break;
case NE_VAR_UNDEFINED:
break; // cont remains true, loop continues
}
} while (cont); // cont is never set to false; only exits via return
}
The variable accumulator map is a plain HashMap initialized with capacity 20 and
no maximum size:
// ConnectionData.java:98
environment = new HashMap<String, String>(20);
Per-variable limits exist (name: max 50 chars, value: max 1000 chars), but there is no
cap on the count of variables. Each map entry occupies approximately 2 KB of heap
(String headers + Map.Entry + backing char arrays). On a JVM with a 512 MB heap,
approximately 250,000 unique entries trigger an OutOfMemoryError.
Network cost: using sequential 1-byte names (e.g., \x01, \x02, ...) and 1-byte
values, each variable pair requires roughly 13 protocol bytes. Sending 250,000 pairs
requires only ~3.25 MB of network traffic — feasible in seconds over any reasonable
network connection.
No authentication is required. NEW-ENVIRON negotiation occurs before login.
Affected source files:
- remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java lines 1127-1180
- remote-telnet/src/main/java/org/jline/builtins/telnet/ConnectionData.java line 98
PoC
Connect to the JLine3 Telnet server and, after completing WILL/DO option negotiation, send a NEW-ENVIRON SEND subneg followed by a single large IS subneg containing thousands of unique variable pairs before the final IAC SE.
Protocol structure (no authentication required): 1. Standard Telnet option negotiation (IAC DO NEW-ENVIRON, IAC WILL NEW-ENVIRON) 2. Server sends IAC SB NEW-ENVIRON SEND IAC SE 3. Client responds with: IAC SB NEW-ENVIRON IS [NE_VAR 0x01 NE_VALUE 0x01] ← variable pair 1 [NE_VAR 0x02 NE_VALUE 0x01] ← variable pair 2 ... repeated N times ... IAC SE ← only sent after N pairs
Each iteration adds one entry to the per-connection environment map. The connection thread blocks reading from the socket while accumulating pairs, so the attacker controls the timing of the OOM.
Reproduction environment:
- JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2
- remote-telnet module started with its default configuration
- Confirmed by source-code analysis; loop exit condition and missing count guard
verified by inspection of readNEVariables() and ConnectionData constructor
Impact
Type: Denial of Service (heap memory exhaustion / OutOfMemoryError)
Who is affected: Any application embedding the JLine3 remote-telnet module and
exposing its Telnet server. No credentials are required. A single connection can exhaust
the entire JVM heap, crashing the host process or triggering JVM out-of-memory
handling that impacts all users sharing that JVM instance.
Credits
This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jline:jline-remote-telnet"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-56740"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:07:25Z",
"nvd_published_at": "2026-07-17T22:17:57Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe JLine3 Telnet server (`remote-telnet` module) does not limit the number of\nenvironment variables a client may inject via the Telnet NEW-ENVIRON option. An\nunauthenticated attacker can flood the server with a large number of unique\nvariable pairs before sending the terminating IAC SE byte, exhausting JVM heap\nmemory and causing an OutOfMemoryError (denial of service). Approximately 3\u20134 MB of\nnetwork traffic is sufficient to consume a 512 MB JVM heap.\n\n### Details\n\n`TelnetIO.readNEVariables()` (TelnetIO.java:1127-1180) processes incoming NEW-ENVIRON\nvariable pairs in a loop and stores each pair in a `HashMap` held by `ConnectionData`:\n\n```java\n// TelnetIO.java:1139-1178\nboolean cont = true;\nif (i == NE_VAR || i == NE_USERVAR) {\n do {\n switch (readNEVariableName(sbuf)) {\n case NE_VAR_OK:\n TelnetIO.this.connectionData.getEnvironment().put(str, sbuf.toString());\n // \u2190 no per-connection count limit\n break;\n case NE_VAR_UNDEFINED:\n break; // cont remains true, loop continues\n }\n } while (cont); // cont is never set to false; only exits via return\n}\n```\n\nThe variable accumulator map is a plain `HashMap` initialized with capacity 20 and\n**no maximum size**:\n\n```java\n// ConnectionData.java:98\nenvironment = new HashMap\u003cString, String\u003e(20);\n```\n\nPer-variable limits exist (name: max 50 chars, value: max 1000 chars), but there is no\ncap on the *count* of variables. Each map entry occupies approximately 2 KB of heap\n(String headers + `Map.Entry` + backing char arrays). On a JVM with a 512 MB heap,\napproximately 250,000 unique entries trigger an `OutOfMemoryError`.\n\nNetwork cost: using sequential 1-byte names (e.g., `\\x01`, `\\x02`, ...) and 1-byte\nvalues, each variable pair requires roughly 13 protocol bytes. Sending 250,000 pairs\nrequires only ~3.25 MB of network traffic \u2014 feasible in seconds over any reasonable\nnetwork connection.\n\nNo authentication is required. NEW-ENVIRON negotiation occurs before login.\n\nAffected source files:\n- `remote-telnet/src/main/java/org/jline/builtins/telnet/TelnetIO.java` lines 1127-1180\n- `remote-telnet/src/main/java/org/jline/builtins/telnet/ConnectionData.java` line 98\n\n### PoC\n\nConnect to the JLine3 Telnet server and, after completing WILL/DO option negotiation,\nsend a NEW-ENVIRON SEND subneg followed by a single large IS subneg containing\nthousands of unique variable pairs before the final IAC SE.\n\nProtocol structure (no authentication required):\n1. Standard Telnet option negotiation (IAC DO NEW-ENVIRON, IAC WILL NEW-ENVIRON)\n2. Server sends IAC SB NEW-ENVIRON SEND IAC SE\n3. Client responds with: IAC SB NEW-ENVIRON IS\n [NE_VAR 0x01 NE_VALUE 0x01] \u2190 variable pair 1\n [NE_VAR 0x02 NE_VALUE 0x01] \u2190 variable pair 2\n ... repeated N times ...\n IAC SE \u2190 only sent after N pairs\n\nEach iteration adds one entry to the per-connection environment map. The connection\nthread blocks reading from the socket while accumulating pairs, so the attacker\ncontrols the timing of the OOM.\n\nReproduction environment:\n- JLine3 built from current master on x86_64 Linux, OpenJDK 25.0.2\n- `remote-telnet` module started with its default configuration\n- Confirmed by source-code analysis; loop exit condition and missing count guard\n verified by inspection of `readNEVariables()` and `ConnectionData` constructor\n\n### Impact\n\n**Type**: Denial of Service (heap memory exhaustion / OutOfMemoryError)\n**Who is affected**: Any application embedding the JLine3 `remote-telnet` module and\nexposing its Telnet server. No credentials are required. A single connection can exhaust\nthe entire JVM heap, crashing the host process or triggering JVM out-of-memory\nhandling that impacts all users sharing that JVM instance.\n\n### Credits \n\nThis issue was identified by Micha\u0142 Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.",
"id": "GHSA-47qp-hqvx-6r3f",
"modified": "2026-07-20T21:21:41Z",
"published": "2026-06-18T13:07:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/jline/jline3/security/advisories/GHSA-47qp-hqvx-6r3f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56740"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/pull/2000"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/pull/2001"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/commit/0389f0ee6d0375901b602671ad5dafd4d1d4ee09"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/commit/4ee3a73849ffb9a85ec748e4e8cd8f6d81f84f40"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/commit/934f09e6128cee33c2b13d42b6e859c1ee2d194b"
},
{
"type": "PACKAGE",
"url": "https://github.com/jline/jline3"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/releases/tag/4.0.16"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/releases/tag/4.2.1"
},
{
"type": "WEB",
"url": "https://github.com/jline/jline3/releases/tag/jline-3.30.14"
}
],
"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"
}
],
"summary": "JLine3 Telnet server: Unauthenticated Remote Memory Exhaustion via Unbounded Telnet NEW-ENVIRON Variables"
}
GHSA-493P-PFQ6-5258
Vulnerability from github – Published: 2023-03-23 20:32 – Updated: 2026-08-04 22:06
VLAI
Summary
json-smart Uncontrolled Recursion vulnerability
Details
Impact
Affected versions of net.minidev:json-smart are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.
When reaching a ‘[‘ or ‘{‘ character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.
Patches
This vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.
Workarounds
N/A
References
- https://www.cve.org/CVERecord?id=CVE-2023-1370
- https://nvd.nist.gov/vuln/detail/CVE-2023-1370
- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "net.minidev:json-smart"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-1370"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2023-03-23T20:32:03Z",
"nvd_published_at": "2023-03-22T06:15:00Z",
"severity": "HIGH"
},
"details": "### Impact\nAffected versions of [net.minidev:json-smart](https://github.com/netplex/json-smart-v1) are vulnerable to Denial of Service (DoS) due to a StackOverflowError when parsing a deeply nested JSON array or object.\n\nWhen reaching a \u2018[\u2018 or \u2018{\u2018 character in the JSON input, the code parses an array or an object respectively. It was discovered that the 3PP does not have any limit to the nesting of such arrays or objects. Since the parsing of nested arrays and objects is done recursively, nesting too many of them can cause stack exhaustion (stack overflow) and crash the software.\n\n### Patches\nThis vulnerability was fixed in json-smart version 2.4.9, but the maintainer recommends upgrading to 2.4.10, due to a remaining bug.\n\n### Workarounds\nN/A\n\n### References\n- https://www.cve.org/CVERecord?id=CVE-2023-1370\n- https://nvd.nist.gov/vuln/detail/CVE-2023-1370\n- https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748",
"id": "GHSA-493p-pfq6-5258",
"modified": "2026-08-04T22:06:15Z",
"published": "2023-03-23T20:32:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1370"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/issues/137"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/commit/5b3205d051952d3100aa0db1535f6ba6226bd87a"
},
{
"type": "WEB",
"url": "https://github.com/netplex/json-smart-v2/commit/e2791ae506a57491bc856b439d706c81e45adcf8"
},
{
"type": "PACKAGE",
"url": "https://github.com/oswaldobapvicjr/jsonmerge"
},
{
"type": "WEB",
"url": "https://research.jfrog.com/vulnerabilities/stack-exhaustion-in-json-smart-leads-to-denial-of-service-when-parsing-malformed-json-xray-427633"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240621-0006"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JAVA-NETMINIDEV-3369748"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-1370"
}
],
"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"
}
],
"summary": "json-smart Uncontrolled Recursion vulnerability"
}
GHSA-4G9R-VXHX-9PGX
Vulnerability from github – Published: 2024-02-19 09:30 – Updated: 2025-11-04 19:43
VLAI
Summary
Apache Commons Compress: Denial of service caused by an infinite loop for a corrupted DUMP file
Details
Loop with Unreachable Exit Condition ('Infinite Loop') vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0.
Users are recommended to upgrade to version 1.26.0 which fixes the issue.
Severity
5.9 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.apache.commons:commons-compress"
},
"ranges": [
{
"events": [
{
"introduced": "1.3"
},
{
"fixed": "1.26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-25710"
],
"database_specific": {
"cwe_ids": [
"CWE-835"
],
"github_reviewed": true,
"github_reviewed_at": "2024-02-20T23:58:47Z",
"nvd_published_at": "2024-02-19T09:15:37Z",
"severity": "MODERATE"
},
"details": "Loop with Unreachable Exit Condition (\u0027Infinite Loop\u0027) vulnerability in Apache Commons Compress. This issue affects Apache Commons Compress: from 1.3 through 1.25.0.\n\nUsers are recommended to upgrade to version 1.26.0 which fixes the issue.",
"id": "GHSA-4g9r-vxhx-9pgx",
"modified": "2025-11-04T19:43:57Z",
"published": "2024-02-19T09:30:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25710"
},
{
"type": "PACKAGE",
"url": "https://github.com/apache/commons-compress"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/cz8qkcwphy4cx8gltn932ln51cbtq6kf"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20240307-0010"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Aug/37"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2024/02/19/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Apache Commons Compress: Denial of service caused by an infinite loop for a corrupted DUMP file"
}
GHSA-4GG5-VX3J-XWC7
Vulnerability from github – Published: 2022-12-12 15:30 – Updated: 2025-09-02 19:38
VLAI
Summary
Protobuf Java vulnerable to Uncontrolled Resource Consumption
Details
A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.
Severity
7.5 (High)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.16.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "3.19.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.0"
},
{
"fixed": "3.20.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.21.7"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "3.16.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.17.0"
},
{
"fixed": "3.19.6"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.20.0"
},
{
"fixed": "3.20.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "3.21.0"
},
{
"fixed": "3.21.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-3510"
],
"database_specific": {
"cwe_ids": [
"CWE-400"
],
"github_reviewed": true,
"github_reviewed_at": "2022-12-12T22:34:26Z",
"nvd_published_at": "2022-12-12T13:15:00Z",
"severity": "HIGH"
},
"details": "A parsing issue similar to CVE-2022-3171, but with Message-Type Extensions in protobuf-java core and lite versions prior to 3.21.7, 3.20.3, 3.19.6 and 3.16.3 can lead to a denial of service attack. Inputs containing multiple instances of non-repeated embedded messages with repeated or unknown fields causes objects to be converted back-n-forth between mutable and immutable forms, resulting in potentially long garbage collection pauses. We recommend updating to the versions mentioned above.",
"id": "GHSA-4gg5-vx3j-xwc7",
"modified": "2025-09-02T19:38:11Z",
"published": "2022-12-12T15:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-3510"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/db7c17803320525722f45c1d26fc08bc41d1bf48"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf/tree/main/java"
}
],
"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"
}
],
"summary": "Protobuf Java vulnerable to Uncontrolled Resource Consumption"
}
GHSA-5JMJ-H7XM-6Q6V
Vulnerability from github – Published: 2026-06-23 21:23 – Updated: 2026-07-16 21:25
VLAI
Summary
jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties
Details
Summary
In BeanDeserializerBase.createContextual(), per-property @JsonIgnoreProperties exclusions are applied by _handleByNameInclusion(), producing a contextual deserializer whose BeanPropertyMap has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by @JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)) rebuilds from this._beanProperties (the original, unfiltered map) instead of contextual._beanProperties, then overwrites the filtered map — restoring every property _handleByNameInclusion had just removed. The ignored property becomes writable again.
Impact
An application that both enables case-insensitive matching and relies on per-property @JsonIgnoreProperties to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).
Affected / Patched
Will be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.
Severity / CWE
Maintainer: minor. Reporter: Moderate. CWE-915.
Upstream fix
FasterXML/jackson-databind#5962 (PR #5964, 0e1b0b2), milestone 3.1.4. Released 2026-06-04.
Severity
5.3 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "tools.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.0"
},
{
"fixed": "3.1.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.8.0"
},
{
"fixed": "2.18.9"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.19.0"
},
{
"fixed": "2.21.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.fasterxml.jackson.core:jackson-databind"
},
"ranges": [
{
"events": [
{
"introduced": "2.22.0"
},
{
"fixed": "2.22.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54515"
],
"database_specific": {
"cwe_ids": [
"CWE-915"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-23T21:23:58Z",
"nvd_published_at": "2026-06-23T21:17:02Z",
"severity": "MODERATE"
},
"details": "## Summary\nIn `BeanDeserializerBase.createContextual()`, per-property `@JsonIgnoreProperties` exclusions are applied by `_handleByNameInclusion()`, producing a `contextual` deserializer whose `BeanPropertyMap` has the ignored properties removed. The subsequent per-property case-insensitivity block (triggered by `@JsonFormat(ACCEPT_CASE_INSENSITIVE_PROPERTIES)`) rebuilds from `this._beanProperties` (the original, unfiltered map) instead of `contextual._beanProperties`, then overwrites the filtered map \u2014 restoring every property `_handleByNameInclusion` had just removed. The ignored property becomes writable again.\n\n## Impact\nAn application that both enables case-insensitive matching and relies on per-property `@JsonIgnoreProperties` to keep a field unwritable can have that field set from untrusted JSON (mass-assignment-style write).\n\n## Affected / Patched\nWill be fixed in 2.18.9, 2.21.5, 2.22.1 and 3.1.4.\n\n## Severity / CWE\nMaintainer: minor. Reporter: Moderate. CWE-915.\n\n## Upstream fix\nFasterXML/jackson-databind#5962 (PR #5964, `0e1b0b2`), milestone 3.1.4. Released 2026-06-04.",
"id": "GHSA-5jmj-h7xm-6q6v",
"modified": "2026-07-16T21:25:45Z",
"published": "2026-06-23T21:23:58Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/security/advisories/GHSA-5jmj-h7xm-6q6v"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54515"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5962"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/issues/5964"
},
{
"type": "WEB",
"url": "https://github.com/FasterXML/jackson-databind/commit/0e1b0b211f7a53baa62ba2f4c9bd006c7bf4d5fa"
},
{
"type": "PACKAGE",
"url": "https://github.com/FasterXML/jackson-databind"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "jackson-databind has case-insensitive deserialization bypasses per-property @JsonIgnoreProperties"
}
GHSA-5MG8-W23W-74H3
Vulnerability from github – Published: 2021-03-25 17:04 – Updated: 2026-02-23 22:45
VLAI
Summary
Information Disclosure in Guava
Details
A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava com.google.common.io.Files.createTempDir(). The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method.
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.guava:guava"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "32.0.0-android"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-8908"
],
"database_specific": {
"cwe_ids": [
"CWE-173",
"CWE-200",
"CWE-378",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-25T17:01:09Z",
"nvd_published_at": "2020-12-10T23:15:00Z",
"severity": "LOW"
},
"details": "A temp directory creation vulnerability exists in Guava prior to version 32.0.0 allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava `com.google.common.io.Files.createTempDir()`. The permissions granted to the directory created default to the standard unix-like /tmp ones, leaving the files open. Maintainers recommend explicitly changing the permissions after the creation of the directory, or removing uses of the vulnerable method.",
"id": "GHSA-5mg8-w23w-74h3",
"modified": "2026-02-23T22:45:53Z",
"published": "2021-03-25T17:04:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-8908"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/4011"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/4011#issuecomment-1578991974"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/feb83a1c8fd2e7670b244d5afd23cba5aca43284"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/fec0dbc4634006a6162cfd4d0d09c962073ddf40"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd5d58088812cf8e677d99b07f73c654014c524c94e7fedbdee047604@%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd5d58088812cf8e677d99b07f73c654014c524c94e7fedbdee047604%40%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd2704306ec729ccac726e50339b8a8f079515cc29ccb77713b16e7c5@%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd2704306ec729ccac726e50339b8a8f079515cc29ccb77713b16e7c5%40%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd01f5ff0164c468ec7abc96ff7646cea3cce6378da2e4aa29c6bcb95@%3Cgithub.arrow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd01f5ff0164c468ec7abc96ff7646cea3cce6378da2e4aa29c6bcb95%40%3Cgithub.arrow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcafc3a637d82bdc9a24036b2ddcad1e519dd0e6f848fcc3d606fd78f@%3Cdev.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rcafc3a637d82bdc9a24036b2ddcad1e519dd0e6f848fcc3d606fd78f%40%3Cdev.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc607bc52f3507b8b9c28c6a747c3122f51ac24afe80af2a670785b97@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc607bc52f3507b8b9c28c6a747c3122f51ac24afe80af2a670785b97%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc2dbc4633a6eea1fcbce6831876cfa17b73759a98c65326d1896cb1a@%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rc2dbc4633a6eea1fcbce6831876cfa17b73759a98c65326d1896cb1a%40%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc7642b9800249553f13457e46b813bea1aec99d2bc9106510e00ff3@%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rbc7642b9800249553f13457e46b813bea1aec99d2bc9106510e00ff3%40%3Ctorque-dev.db.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb8c0f1b7589864396690fe42a91a71dea9412e86eec66dc85bbacaaf@%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb8c0f1b7589864396690fe42a91a71dea9412e86eec66dc85bbacaaf%40%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb2364f4cf4d274eab5a7ecfaf64bf575cedf8b0173551997c749d322@%3Cgitbox.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rb2364f4cf4d274eab5a7ecfaf64bf575cedf8b0173551997c749d322%40%3Cgitbox.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra7ab308481ee729f998691e8e3e02e93b1dedfc98f6b1cd3d86923b3@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujan2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuApr2021.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com//security-alerts/cpujul2021.html"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-1015415"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20220210-0003"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfc27e2727a20a574f39273e0432aa97486a332f9b3068f6ac1346594@%3Cdev.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rfc27e2727a20a574f39273e0432aa97486a332f9b3068f6ac1346594%40%3Cdev.myfaces.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf9f0fa84b8ae1a285f0210bafec6de2a9eba083007d04640b82aa625@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf9f0fa84b8ae1a285f0210bafec6de2a9eba083007d04640b82aa625%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf00b688ffa620c990597f829ff85fdbba8bf73ee7bfb34783e1f0d4e@%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rf00b688ffa620c990597f829ff85fdbba8bf73ee7bfb34783e1f0d4e%40%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/reebbd63c25bc1a946caa419cec2be78079f8449d1af48e52d47c9e85@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/reebbd63c25bc1a946caa419cec2be78079f8449d1af48e52d47c9e85%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re120f6b3d2f8222121080342c5801fdafca2f5188ceeb3b49c8a1d27@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/re120f6b3d2f8222121080342c5801fdafca2f5188ceeb3b49c8a1d27%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd7e12d56d49d73e2b8549694974b07561b79b05455f7f781954231bf@%3Cdev.pig.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/rd7e12d56d49d73e2b8549694974b07561b79b05455f7f781954231bf%40%3Cdev.pig.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/ra7ab308481ee729f998691e8e3e02e93b1dedfc98f6b1cd3d86923b3%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4776f62dfae4a0006658542f43034a7fc199350e35a66d4e18164ee6%40%3Ccommits.cxf.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3dd8881de891598d622227e9840dd7c2ef1d08abbb49e9690c7ae1bc@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3dd8881de891598d622227e9840dd7c2ef1d08abbb49e9690c7ae1bc%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3c3b33ee5bef0c67391d27a97cbfd89d44f328cf072b601b58d4e748@%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r3c3b33ee5bef0c67391d27a97cbfd89d44f328cf072b601b58d4e748%40%3Ccommits.pulsar.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2fe45d96eea8434b91592ca08109118f6308d60f6d0e21d52438cfb4@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r2fe45d96eea8434b91592ca08109118f6308d60f6d0e21d52438cfb4%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r294be9d31c0312d2c0837087204b5d4bf49d0552890e6eec716fa6a6@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r294be9d31c0312d2c0837087204b5d4bf49d0552890e6eec716fa6a6%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215b3d50f56faeb2f9383505f3e62faa9f549bb23e8a9848b78a968e@%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r215b3d50f56faeb2f9383505f3e62faa9f549bb23e8a9848b78a968e%40%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r161b87f8037bbaff400194a63cd2016c9a69f5949f06dcc79beeab54@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r161b87f8037bbaff400194a63cd2016c9a69f5949f06dcc79beeab54%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r07ed3e4417ad043a27bee7bb33322e9bfc7d7e6d1719b8e3dfd95c14@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r07ed3e4417ad043a27bee7bb33322e9bfc7d7e6d1719b8e3dfd95c14%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r037fed1d0ebde50c9caf8d99815db3093c344c3f651c5a49a09824ce@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r007add131977f4f576c232b25e024249a3d16f66aad14a4b52819d21@%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r007add131977f4f576c232b25e024249a3d16f66aad14a4b52819d21%40%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "PACKAGE",
"url": "https://github.com/google/guava"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r841c5e14e1b55281523ebcde661ece00b38a0569e00ef5e12bd5f6ba@%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r841c5e14e1b55281523ebcde661ece00b38a0569e00ef5e12bd5f6ba%40%3Cissues.maven.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7b0e81d8367264d6cad98766a469d64d11248eb654417809bfdacf09@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r7b0e81d8367264d6cad98766a469d64d11248eb654417809bfdacf09%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r79e47ed555bdb1180e528420a7a2bb898541367a29a3bc6bbf0baf2c@%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r79e47ed555bdb1180e528420a7a2bb898541367a29a3bc6bbf0baf2c%40%3Cissues.hive.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r68d86f4b06c808204f62bcb254fcb5b0432528ee8d37a07ef4bc8222@%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r68d86f4b06c808204f62bcb254fcb5b0432528ee8d37a07ef4bc8222%40%3Ccommits.ws.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6874dfe26eefc41b7c9a5e4a0487846fc4accf8c78ff948b24a1104a@%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r6874dfe26eefc41b7c9a5e4a0487846fc4accf8c78ff948b24a1104a%40%3Cdev.drill.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5d61b98ceb7bba939a651de5900dbd67be3817db6bfcc41c6e04e199@%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5d61b98ceb7bba939a651de5900dbd67be3817db6bfcc41c6e04e199%40%3Cyarn-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5b3d93dfdfb7708e796e8762ab40edbde8ff8add48aba53e5ea26f44@%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r5b3d93dfdfb7708e796e8762ab40edbde8ff8add48aba53e5ea26f44%40%3Cissues.geode.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58a8775205ab1839dba43054b09a9ab3b25b423a4170b2413c4067ac@%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r58a8775205ab1839dba43054b09a9ab3b25b423a4170b2413c4067ac%40%3Ccommon-issues.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r49549a8322f62cd3acfa4490d25bfba0be04f3f9ff4d14fe36199d27@%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r49549a8322f62cd3acfa4490d25bfba0be04f3f9ff4d14fe36199d27%40%3Cyarn-dev.hadoop.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/r4776f62dfae4a0006658542f43034a7fc199350e35a66d4e18164ee6@%3Ccommits.cxf.apache.org%3E"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Information Disclosure in Guava"
}
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-735F-PC8J-V9W8
Vulnerability from github – Published: 2024-09-19 16:06 – Updated: 2025-09-10 20:53
VLAI
Summary
protobuf-java has potential Denial of Service issue
Details
Summary
When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.
Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team ecosystem@trailofbits.com
Affected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.
Severity
CVE-2024-7254 High CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication) This is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.
Proof of Concept
For reproduction details, please refer to the unit tests (Protobuf Java LiteTest and CodedInputStreamTest) that identify the specific inputs that exercise this parsing weakness.
Remediation and Mitigation
We have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages: * protobuf-java (3.25.5, 4.27.5, 4.28.2) * protobuf-javalite (3.25.5, 4.27.5, 4.28.2) * protobuf-kotlin (3.25.5, 4.27.5, 4.28.2) * protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2) * com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)
Severity
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.25.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0.rc.1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "RubyGems",
"name": "google-protobuf"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0.rc.1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin-lite"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-kotlin"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-javalite"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "4.0.0-RC1"
},
{
"fixed": "4.27.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "com.google.protobuf:protobuf-java"
},
"ranges": [
{
"events": [
{
"introduced": "4.28.0-RC1"
},
{
"fixed": "4.28.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-7254"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-400",
"CWE-787"
],
"github_reviewed": true,
"github_reviewed_at": "2024-09-19T16:06:03Z",
"nvd_published_at": "2024-09-19T01:15:10Z",
"severity": "HIGH"
},
"details": "### Summary\nWhen parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.\n\nReporter: Alexis Challande, Trail of Bits Ecosystem Security Team \u003cecosystem@trailofbits.com\u003e\n\nAffected versions: This issue affects all versions of both the Java full and lite Protobuf runtimes, as well as Protobuf for Kotlin and JRuby, which themselves use the Java Protobuf runtime.\n\n### Severity\n[CVE-2024-7254](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-7254) **High** CVSS4.0 Score 8.7 (NOTE: there may be a delay in publication)\nThis is a potential Denial of Service. Parsing nested groups as unknown fields with DiscardUnknownFieldsParser or Java Protobuf Lite parser, or against Protobuf map fields, creates unbounded recursions that can be abused by an attacker.\n\n### Proof of Concept\nFor reproduction details, please refer to the unit tests (Protobuf Java [LiteTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/lite/src/test/java/com/google/protobuf/LiteTest.java) and [CodedInputStreamTest](https://github.com/protocolbuffers/protobuf/blob/a037f28ff81ee45ebe008c64ab632bf5372242ce/java/core/src/test/java/com/google/protobuf/CodedInputStreamTest.java)) that identify the specific inputs that exercise this parsing weakness.\n\n### Remediation and Mitigation\nWe have been working diligently to address this issue and have released a mitigation that is available now. Please update to the latest available versions of the following packages:\n* protobuf-java (3.25.5, 4.27.5, 4.28.2)\n* protobuf-javalite (3.25.5, 4.27.5, 4.28.2)\n* protobuf-kotlin (3.25.5, 4.27.5, 4.28.2)\n* protobuf-kotlin-lite (3.25.5, 4.27.5, 4.28.2)\n* com-protobuf [JRuby gem only] (3.25.5, 4.27.5, 4.28.2)",
"id": "GHSA-735f-pc8j-v9w8",
"modified": "2025-09-10T20:53:03Z",
"published": "2024-09-19T16:06:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-735f-pc8j-v9w8"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7254"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/4728531c162f2f9e8c2ca1add713cfee2db6be3b"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/850fcce9176e2c9070614dab53537760498c926b"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/9a5f5fe752a20cbac2e722b06949ac985abdd534"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/ac9fb5b4c71b0dd80985b27684e265d1f03abf46"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/cc8b3483a5584b3301e3d43d17eb59704857ffaa"
},
{
"type": "WEB",
"url": "https://github.com/protocolbuffers/protobuf/commit/d6c82fc55a76481c676f541a255571e8950bb8c3"
},
{
"type": "PACKAGE",
"url": "https://github.com/protocolbuffers/protobuf"
},
{
"type": "WEB",
"url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/google-protobuf/CVE-2024-7254.yml"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241213-0010"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20250418-0006"
}
],
"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": "protobuf-java has potential Denial of Service issue"
}
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-7G45-4RM6-3MM3
Vulnerability from github – Published: 2023-06-14 18:30 – Updated: 2025-11-04 16:44
VLAI
Summary
Guava vulnerable to insecure use of temporary directory
Details
Use of Java's default temporary directory for file creation in FileBackedOutputStream in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.
Even though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.
Severity
5.5 (Medium)
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.google.guava:guava"
},
"ranges": [
{
"events": [
{
"introduced": "1.0"
},
{
"fixed": "32.0.0-android"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-2976"
],
"database_specific": {
"cwe_ids": [
"CWE-379",
"CWE-552"
],
"github_reviewed": true,
"github_reviewed_at": "2023-06-14T21:01:07Z",
"nvd_published_at": "2023-06-14T18:15:09Z",
"severity": "MODERATE"
},
"details": "Use of Java\u0027s default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.\n\nEven though the security vulnerability is fixed in version 32.0.0, maintainers recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.",
"id": "GHSA-7g45-4rm6-3mm3",
"modified": "2025-11-04T16:44:26Z",
"published": "2023-06-14T18:30:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-2976"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/2575"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/issues/6532"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/feb83a1c8fd2e7670b244d5afd23cba5aca43284"
},
{
"type": "PACKAGE",
"url": "https://github.com/google/guava"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/releases/tag/v32.0.0"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20230818-0008"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20241108-0002"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-01006.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Guava vulnerable to insecure use of temporary directory"
}
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…