CWE-502
AllowedDeserialization of Untrusted Data
Abstraction: Base · Status: Draft
The product deserializes untrusted data without sufficiently ensuring that the resulting data will be valid.
5884 vulnerabilities reference this CWE, most recent first.
GHSA-XXPH-C9WW-HJ94
Vulnerability from github – Published: 2026-10-27 14:27 – Updated: 2026-10-27 14:27CompactHashMap/CompactHashSet/MapMakerInternalMap native deserialization triggers uncontrolled memory allocation
Summary
CompactHashMap, CompactHashSet, and MapMakerInternalMap implement readObject(ObjectInputStream) by reading an attacker-controlled elementCount or initialCapacity from the stream. On the very first insertion during or after deserialization (for the CompactHash* collections, inside allocArrays()) or immediately during deserialization (for MapMakerInternalMap), the implementation eagerly allocates arrays sized to that full, unvalidated value (up to CompactHashing.MAX_SIZE = 2^30-1, ~1.07 billion, for example) before the rest of the stream's actual content has been consumed. A 72-byte malicious serialized stream containing a single tiny element can force a multi-gigabyte allocation and crash a JVM with OutOfMemoryError, dynamically confirmed against the current release.
Details
CompactHashMap.readObject() (guava/src/com/google/common/collect/CompactHashMap.java):
private void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
stream.defaultReadObject();
int elementCount = stream.readInt();
if (elementCount < 0) {
throw new InvalidObjectException("Invalid size: " + elementCount);
}
init(elementCount);
for (int i = 0; i < elementCount; i++) {
K key = (K) stream.readObject();
V value = (V) stream.readObject();
put(key, value);
}
}
elementCount is only checked for being non-negative; there is no upper bound and no relationship enforced between the declared count and how much data actually follows in the stream. init(elementCount) (line 251) just stores the value (clamped to [1, CompactHashing.MAX_SIZE], i.e. up to 2^30-1):
void init(int expectedSize) {
Preconditions.checkArgument(expectedSize >= 0, "Expected size must be >= 0");
this.metadata = Ints.constrainToRange(expectedSize, 1, CompactHashing.MAX_SIZE);
}
The real allocation is deferred to allocArrays(), which fires lazily on the first put() call — i.e. after only one key/value pair has actually been read off the wire:
int allocArrays() {
...
int expectedSize = metadata;
int buckets = CompactHashing.tableSize(expectedSize);
this.table = CompactHashing.createTable(buckets);
setHashTableMask(buckets - 1);
this.entries = new int[expectedSize];
this.keys = new Object[expectedSize];
this.values = new Object[expectedSize];
return expectedSize;
}
With expectedSize near CompactHashing.MAX_SIZE (2^30-1), this single call allocates a hash table plus three expectedSize-length arrays — multiple gigabytes — triggered by a stream that has, at that point, only supplied one small real element. CompactHashSet.readObject()/allocArrays() have the identical shape. CompactLinkedHashMap/CompactLinkedHashSet extend these classes and inherit the same unguarded path.
The problem with MapMakerInternalMap is similar, with a size read from the serialized data and stored in a MapMaker instance for later user during deserialization, when the MapMaker is passed back to MapMakerInternalMap and segments are allocated by calling newSegment, whose implementations (example) create Segment instances (example) that allocate arrays of the requested capacity through the newTable helper.
This is the same amplification shape as the already-fixed CVE-2018-10237 (AtomicDoubleArray/CompoundOrdering: attacker declares a large size, library eagerly allocates before validating against actual stream content). That fix rewrote AtomicDoubleArray.readObject() to grow an ImmutableLongArray.Builder incrementally per element actually read, rather than pre-allocating from the declared size — Guava's own HashBiMap.readObject() documents the same defensive principle explicitly in a comment: init(16); // resist hostile attempts to allocate gratuitous heap. CompactHashMap/CompactHashSet do not follow either of these two patterns already present elsewhere in the same codebase.
Reachability: All classes are top-level, implements ... Serializable, and require no special classpath setup beyond Guava being present (near-ubiquitous on JVM backends). A native Java deserialization attacker names the class directly in a hand-crafted stream — no particular Guava factory method needs to have been used by the victim application, exactly as with the precedent CVE.
PoC
Full source and run instructions in the attached poc-guava-compacthash-dos.zip (Maven project, guava:33.7.1-jre — the current latest release — as the only dependency). The PoC:
- Uses reflection only to legitimately obtain a
CompactHashSetinstance (it is package-private; a real attacker does not need this step, since they craft the serialized bytes directly rather than calling Guava's own serialization code). - Serializes one set with 1 element and one with 2 elements, diffs the two byte streams to locate the exact offset of the
elementCountfield (byte-precise, not guessed). - Patches that one 4-byte field in the 1-element stream from
1to0x3FFFFFFF(CompactHashing.MAX_SIZE), leaving the rest of the 72-byte stream (one real"A"element) untouched. - Feeds the resulting 72-byte malicious stream into a plain
new ObjectInputStream(...).readObject()call against the real, unmodifiedguava-33.7.1-jre.jar.
Actual run output:
### -Xmx8g (generous heap) ###
Located size field at offset 63, value=1 (expected 1)
Malicious stream size: 72 bytes
Declared elementCount: 1073741823 (~1.07 billion)
Real payload: 1 tiny string element ("A")
=== RESULT ===
Exception: java.lang.OutOfMemoryError: Java heap space
Time to allocate+fail: 4013 ms
Heap used before: 3 MB
Heap used after (at failure point): 4103 MB
JVM max heap (-Xmx): 8192 MB
### -Xmx128m (ordinary service-sized heap) ###
Located size field at offset 63, value=1 (expected 1)
Malicious stream size: 72 bytes
Declared elementCount: 1073741823 (~1.07 billion)
Real payload: 1 tiny string element ("A")
=== RESULT ===
Exception: java.lang.OutOfMemoryError: Java heap space
Time to allocate+fail: 24 ms
Heap used before: 4 MB
Heap used after (at failure point): 2 MB
JVM max heap (-Xmx): 128 MB
A 72-byte input forces ~4.1 GB of real allocation before failing on an 8 GB heap, and crashes a 128 MB heap in 24 ms — over 50,000x amplification between input size and forced allocation.
To reproduce: mvn -q compile dependency:build-classpath -Dmdep.outputFile=cp.txt && java -Xmx128m -cp "target/classes:$(cat cp.txt)" poc.Poc
Impact
Uncontrolled resource consumption (CWE-770 / CWE-400) via native Java deserialization: any application that runs ObjectInputStream.readObject() on data reachable by an attacker, and has Guava on its classpath (true for a large fraction of the JVM ecosystem), can be crashed with a single ~72-byte payload, regardless of what type the application itself expected to deserialize.
Severity
CVSS 3.1: AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H — identical vector to CVE-2018-10237, the precedent this is a sibling of. Recomputed with the full formula: exploitability = 8.22×0.85×0.44×0.85×0.85 = 2.221; ISS = 1-(1×1×0.44) = 0.56; impact = 6.42×0.56 = 3.595; base = roundup(5.816) = 5.9 (Medium).
Affected
com.google.guava:guava, all editions (-jre/-android) — confirmed on the current latest release, 33.7.1-jre. CompactHashMap/CompactHashSet/CompactLinkedHashMap/CompactLinkedHashSet have had this same readObject/allocArrays shape for a long time (probably since they were added in Guava 23.6), and similarly for MapMakerInternalMap (which was introduced in Guava 4.0); not tested against older individual releases.
Suggested fix
Apply the same defense already used elsewhere in this codebase: either clamp the initial init() capacity to a small constant regardless of the declared elementCount (as HashBiMap.readObject() already does — init(16); // resist hostile attempts to allocate gratuitous heap) and grow incrementally as elements are actually read, or grow the backing arrays incrementally per iteration of the deserialization loop (as the fixed AtomicDoubleArray.readObject() does via ImmutableLongArray.Builder) instead of eagerly sizing to the full attacker-declared count on first insert.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 33.7.1"
},
"package": {
"ecosystem": "Maven",
"name": "com.google.guava:guava"
},
"ranges": [
{
"events": [
{
"introduced": "4.0"
},
{
"fixed": "33.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102554"
],
"database_specific": {
"cwe_ids": [
"CWE-400",
"CWE-502",
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-27T14:27:53Z",
"nvd_published_at": "2026-10-09T16:17:20Z",
"severity": "HIGH"
},
"details": "# CompactHashMap/CompactHashSet/MapMakerInternalMap native deserialization triggers uncontrolled memory allocation\n\n## Summary\n\n`CompactHashMap`, `CompactHashSet`, and `MapMakerInternalMap` implement `readObject(ObjectInputStream)` by reading an attacker-controlled `elementCount` or `initialCapacity` from the stream. On the very first insertion during or after deserialization (for the `CompactHash*` collections, inside `allocArrays()`) or immediately during deserialization (for `MapMakerInternalMap`), the implementation eagerly allocates arrays sized to that full, unvalidated value (up to `CompactHashing.MAX_SIZE` = 2^30-1, ~1.07 billion, for example) before the rest of the stream\u0027s actual content has been consumed. A 72-byte malicious serialized stream containing a single tiny element can force a multi-gigabyte allocation and crash a JVM with `OutOfMemoryError`, dynamically confirmed against the current release.\n\n## Details\n\n`CompactHashMap.readObject()` (`guava/src/com/google/common/collect/CompactHashMap.java`):\n\n```java\nprivate void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {\n stream.defaultReadObject();\n int elementCount = stream.readInt();\n if (elementCount \u003c 0) {\n throw new InvalidObjectException(\"Invalid size: \" + elementCount);\n }\n init(elementCount);\n for (int i = 0; i \u003c elementCount; i++) {\n K key = (K) stream.readObject();\n V value = (V) stream.readObject();\n put(key, value);\n }\n}\n```\n\n`elementCount` is only checked for being non-negative; there is no upper bound and no relationship enforced between the declared count and how much data actually follows in the stream. `init(elementCount)` (line 251) just stores the value (clamped to `[1, CompactHashing.MAX_SIZE]`, i.e. up to 2^30-1):\n\n```java\nvoid init(int expectedSize) {\n Preconditions.checkArgument(expectedSize \u003e= 0, \"Expected size must be \u003e= 0\");\n this.metadata = Ints.constrainToRange(expectedSize, 1, CompactHashing.MAX_SIZE);\n}\n```\n\nThe real allocation is deferred to `allocArrays()`, which fires lazily on the *first* `put()` call \u2014 i.e. after only one key/value pair has actually been read off the wire:\n\n```java\nint allocArrays() {\n ...\n int expectedSize = metadata;\n int buckets = CompactHashing.tableSize(expectedSize);\n this.table = CompactHashing.createTable(buckets);\n setHashTableMask(buckets - 1);\n this.entries = new int[expectedSize];\n this.keys = new Object[expectedSize];\n this.values = new Object[expectedSize];\n return expectedSize;\n}\n```\n\nWith `expectedSize` near `CompactHashing.MAX_SIZE` (2^30-1), this single call allocates a hash `table` plus three `expectedSize`-length arrays \u2014 multiple gigabytes \u2014 triggered by a stream that has, at that point, only supplied one small real element. `CompactHashSet.readObject()`/`allocArrays()` have the identical shape. `CompactLinkedHashMap`/`CompactLinkedHashSet` extend these classes and inherit the same unguarded path.\n\nThe problem with `MapMakerInternalMap` is similar, with [a size read from the serialized data and stored in a `MapMaker` instance](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L2848-L2851) for [later user during deserialization](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L2897), when [the `MapMaker` is passed back to `MapMakerInternalMap`](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMaker.java#L287) and [segments are allocated](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L173-L200) by [calling `newSegment`](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L1143), whose implementations ([example](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L443)) create `Segment` instances ([example](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L2019)) that [allocate arrays of the requested capacity](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L1234) through [the `newTable`](https://github.com/google/guava/blob/1278ad9c2257f48dc82fb7b7c625ab563605aa24/guava/src/com/google/common/collect/MapMakerInternalMap.java#L1262) helper.\n\nThis is the same amplification shape as the already-fixed **CVE-2018-10237** (`AtomicDoubleArray`/`CompoundOrdering`: attacker declares a large size, library eagerly allocates before validating against actual stream content). That fix rewrote `AtomicDoubleArray.readObject()` to grow an `ImmutableLongArray.Builder` incrementally per element actually read, rather than pre-allocating from the declared size \u2014 Guava\u0027s own `HashBiMap.readObject()` documents the same defensive principle explicitly in a comment: `init(16); // resist hostile attempts to allocate gratuitous heap`. `CompactHashMap`/`CompactHashSet` do not follow either of these two patterns already present elsewhere in the same codebase.\n\n**Reachability**: All classes are top-level, `implements ... Serializable`, and require no special classpath setup beyond Guava being present (near-ubiquitous on JVM backends). A native Java deserialization attacker names the class directly in a hand-crafted stream \u2014 no particular Guava factory method needs to have been used by the victim application, exactly as with the precedent CVE.\n\n## PoC\n\nFull source and run instructions in the attached `poc-guava-compacthash-dos.zip` (Maven project, `guava:33.7.1-jre` \u2014 the current latest release \u2014 as the only dependency). The PoC:\n\n1. Uses reflection only to legitimately obtain a `CompactHashSet` instance (it is package-private; a real attacker does not need this step, since they craft the serialized bytes directly rather than calling Guava\u0027s own serialization code).\n2. Serializes one set with 1 element and one with 2 elements, diffs the two byte streams to locate the exact offset of the `elementCount` field (byte-precise, not guessed).\n3. Patches that one 4-byte field in the 1-element stream from `1` to `0x3FFFFFFF` (`CompactHashing.MAX_SIZE`), leaving the rest of the 72-byte stream (one real `\"A\"` element) untouched.\n4. Feeds the resulting 72-byte malicious stream into a plain `new ObjectInputStream(...).readObject()` call against the real, unmodified `guava-33.7.1-jre.jar`.\n\nActual run output:\n\n```\n### -Xmx8g (generous heap) ###\nLocated size field at offset 63, value=1 (expected 1)\nMalicious stream size: 72 bytes\nDeclared elementCount: 1073741823 (~1.07 billion)\nReal payload: 1 tiny string element (\"A\")\n=== RESULT ===\nException: java.lang.OutOfMemoryError: Java heap space\nTime to allocate+fail: 4013 ms\nHeap used before: 3 MB\nHeap used after (at failure point): 4103 MB\nJVM max heap (-Xmx): 8192 MB\n\n### -Xmx128m (ordinary service-sized heap) ###\nLocated size field at offset 63, value=1 (expected 1)\nMalicious stream size: 72 bytes\nDeclared elementCount: 1073741823 (~1.07 billion)\nReal payload: 1 tiny string element (\"A\")\n=== RESULT ===\nException: java.lang.OutOfMemoryError: Java heap space\nTime to allocate+fail: 24 ms\nHeap used before: 4 MB\nHeap used after (at failure point): 2 MB\nJVM max heap (-Xmx): 128 MB\n```\n\nA 72-byte input forces ~4.1 GB of real allocation before failing on an 8 GB heap, and crashes a 128 MB heap in 24 ms \u2014 over 50,000x amplification between input size and forced allocation.\n\nTo reproduce: `mvn -q compile dependency:build-classpath -Dmdep.outputFile=cp.txt \u0026\u0026 java -Xmx128m -cp \"target/classes:$(cat cp.txt)\" poc.Poc`\n\n## Impact\n\nUncontrolled resource consumption (CWE-770 / CWE-400) via native Java deserialization: any application that runs `ObjectInputStream.readObject()` on data reachable by an attacker, and has Guava on its classpath (true for a large fraction of the JVM ecosystem), can be crashed with a single ~72-byte payload, regardless of what type the application itself expected to deserialize.\n\n## Severity\n\nCVSS 3.1: `AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H` \u2014 identical vector to CVE-2018-10237, the precedent this is a sibling of. Recomputed with the full formula: exploitability = 8.22\u00d70.85\u00d70.44\u00d70.85\u00d70.85 = 2.221; ISS = 1-(1\u00d71\u00d70.44) = 0.56; impact = 6.42\u00d70.56 = 3.595; base = roundup(5.816) = **5.9 (Medium)**.\n\n## Affected\n\n`com.google.guava:guava`, all editions (`-jre`/`-android`) \u2014 confirmed on the current latest release, 33.7.1-jre. `CompactHashMap`/`CompactHashSet`/`CompactLinkedHashMap`/`CompactLinkedHashSet` have had this same `readObject`/`allocArrays` shape for a long time (probably since they were added in Guava 23.6), and similarly for `MapMakerInternalMap` (which was introduced in Guava 4.0); not tested against older individual releases.\n\n## Suggested fix\n\nApply the same defense already used elsewhere in this codebase: either clamp the initial `init()` capacity to a small constant regardless of the declared `elementCount` (as `HashBiMap.readObject()` already does \u2014 `init(16); // resist hostile attempts to allocate gratuitous heap`) and grow incrementally as elements are actually read, or grow the backing arrays incrementally per iteration of the deserialization loop (as the fixed `AtomicDoubleArray.readObject()` does via `ImmutableLongArray.Builder`) instead of eagerly sizing to the full attacker-declared count on first insert.",
"id": "GHSA-xxph-c9ww-hj94",
"modified": "2026-10-27T14:27:53Z",
"published": "2026-10-27T14:27:53Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/google/guava/security/advisories/GHSA-xxph-c9ww-hj94"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102554"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/commit/b931fe9d6d5cf00bc55714ad3308d086f71850fe"
},
{
"type": "PACKAGE",
"url": "https://github.com/google/guava"
},
{
"type": "WEB",
"url": "https://github.com/google/guava/releases/tag/v33.7.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Google Guava: CompactHashMap/CompactHashSet/MapMakerInternalMap deserialization triggers uncontrolled memory allocation"
}
GHSA-XXR7-8H46-RXXW
Vulnerability from github – Published: 2026-09-10 15:33 – Updated: 2026-09-10 15:33Unauthenticated PHP Object Injection in Wise Chat <= 3.4 versions.
{
"affected": [],
"aliases": [
"CVE-2026-81784"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-10T15:17:43Z",
"severity": "HIGH"
},
"details": "Unauthenticated PHP Object Injection in Wise Chat \u003c= 3.4 versions.",
"id": "GHSA-xxr7-8h46-rxxw",
"modified": "2026-09-10T15:33:20Z",
"published": "2026-09-10T15:33:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81784"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/wise-chat/vulnerability/wordpress-wise-chat-plugin-3-4-php-object-injection-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XXRC-HH9X-4PWX
Vulnerability from github – Published: 2026-10-22 03:33 – Updated: 2026-10-22 03:33Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 contains an object injection primitive in rcube_session::unserialize(). A session key prefixed with “!” was treated as having no value, and the reconstructed serialized string was emitted with a key but no corresponding value, desynchronizing the remainder of the input so that following session data was interpreted as a serialized value. This yields a PHP object injection primitive for an attacker able to influence stored session data. Upstream fixed this in the commit “Fix object injection primitive in rcube_session::unserialize() via “!”-prefixed session keys”, which rejects such keys.
{
"affected": [],
"aliases": [
"CVE-2026-114724"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-10-22T02:17:00Z",
"severity": "HIGH"
},
"details": "Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5 contains an object injection primitive in rcube_session::unserialize(). A session key prefixed with \u201c!\u201d was treated as having no value, and the reconstructed serialized string was emitted with a key but no corresponding value, desynchronizing the remainder of the input so that following session data was interpreted as a serialized value. This yields a PHP object injection primitive for an attacker able to influence stored session data. Upstream fixed this in the commit \u201cFix object injection primitive in rcube_session::unserialize() via \u201c!\u201d-prefixed session keys\u201d, which rejects such keys.",
"id": "GHSA-xxrc-hh9x-4pwx",
"modified": "2026-10-22T03:33:37Z",
"published": "2026-10-22T03:33:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114724"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/commit/833770d3d3c35cfde74cc2614d368f25a75b6f99"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/commit/93284f3f0e13f99af37fc3b81861e142eea8a922"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/1151279"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/releases/tag/1.6.20"
},
{
"type": "WEB",
"url": "https://github.com/roundcube/roundcubemail/releases/tag/1.7.5"
},
{
"type": "WEB",
"url": "https://roundcube.net/news/2026/10/19/security-updates-1.6.20-and-1.7.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-XXV9-73GC-96FM
Vulnerability from github – Published: 2026-02-17 03:30 – Updated: 2026-02-17 03:30LightLLM version 1.1.0 and prior contain an unauthenticated remote code execution vulnerability in PD (prefill-decode) disaggregation mode. The PD master node exposes WebSocket endpoints that receive binary frames and pass the data directly to pickle.loads() without authentication or validation. A remote attacker who can reach the PD master can send a crafted payload to achieve arbitrary code execution.
{
"affected": [],
"aliases": [
"CVE-2026-26220"
],
"database_specific": {
"cwe_ids": [
"CWE-502"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-17T03:16:01Z",
"severity": "CRITICAL"
},
"details": "LightLLM version 1.1.0 and prior contain an unauthenticated remote code execution vulnerability in PD (prefill-decode) disaggregation mode. The PD master node exposes WebSocket endpoints that receive binary frames and pass the data directly to pickle.loads() without authentication or validation. A remote attacker who can reach the PD master can send a crafted payload to achieve arbitrary code execution.",
"id": "GHSA-xxv9-73gc-96fm",
"modified": "2026-02-17T03:30:15Z",
"published": "2026-02-17T03:30:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26220"
},
{
"type": "WEB",
"url": "https://github.com/ModelTC/LightLLM/issues/1213"
},
{
"type": "WEB",
"url": "https://chocapikk.com/posts/2026/lightllm-pickle-rce"
},
{
"type": "WEB",
"url": "https://github.com/ModelTC/lightllm/blob/a27dfc88c2144ed51a6e160b6fbe20aad66c8fe0/lightllm/server/api_http.py#L310"
},
{
"type": "WEB",
"url": "https://github.com/ModelTC/lightllm/blob/a27dfc88c2144ed51a6e160b6fbe20aad66c8fe0/lightllm/server/api_http.py#L331"
},
{
"type": "WEB",
"url": "https://lightllm-en.readthedocs.io/en/latest/index.html"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/lightllm-pd-mode-unsafe-deserialization-rce"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
Mitigation
If available, use the signing/sealing features of the programming language to assure that deserialized data has not been tainted. For example, a hash-based message authentication code (HMAC) could be used to ensure that data has not been modified.
Mitigation
When deserializing data, populate a new object rather than just deserializing. The result is that the data flows through safe input validation and that the functions are safe.
Mitigation
Explicitly define a final object() to prevent deserialization.
Mitigation
- Make fields transient to protect them from deserialization.
- An attempt to serialize and then deserialize a class containing transient fields will result in NULLs where the transient data should be. This is an excellent way to prevent time, environment-based, or sensitive variables from being carried over and used improperly.
Mitigation
Avoid having unnecessary types or gadgets (a sequence of instances and method invocations that can self-execute during the deserialization process, often found in libraries) available that can be leveraged for malicious ends. This limits the potential for unintended or unauthorized types and gadgets to be leveraged by the attacker. Add only acceptable classes to an allowlist. Note: new gadgets are constantly being discovered, so this alone is not a sufficient mitigation.
Mitigation
Employ cryptography of the data or code for protection. However, it's important to note that it would still be client-side security. This is risky because if the client is compromised then the security implemented on the client (the cryptography) can be bypassed.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
CAPEC-586: Object Injection
An adversary attempts to exploit an application by injecting additional, malicious content during its processing of serialized objects. Developers leverage serialization in order to convert data or state into a static, binary format for saving to disk or transferring over a network. These objects are then deserialized when needed to recover the data/state. By injecting a malformed object into a vulnerable application, an adversary can potentially compromise the application by manipulating the deserialization process. This can result in a number of unwanted outcomes, including remote code execution.