CVE-2026-82404 in toon
Summary
by MITRE • 09/02/2026
TOON is a compact, human-readable serialization of JSON data for LLM prompts. Prior to 2.3.1, decoding attacker-controlled TOON with a __proto__, constructor, or prototype key wrote through the object prototype chain instead of creating an own property, polluting Object.prototype for the runtime. In packages/toon/src/decode/expand.ts, the expandPaths: 'safe' path and insertPathSafe function made dotted keys such as a.__proto__.x the strongest vector, while plain nested objects, tabular rows, quoted keys, and streaming decode were also affected. The encoder also dropped own __proto__ properties and could invoke an inherited setter during normalization. Services that decode untrusted TOON could experience denial of service or, when a suitable downstream gadget is present, remote code execution. This issue is fixed in version 2.3.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/02/2026
The vulnerability identified as CVE-2024-28869 represents a critical prototype pollution flaw within the TOON serialization library, specifically affecting versions prior to 2.3.1. TOON serves as a compact, human-readable alternative to JSON for Large Language Model prompts, and its security model relies heavily on safe parsing mechanisms when processing untrusted input. The core technical deficiency lies in how the decoder handles specific reserved property names such as _proto_, constructor, and prototype during the expansion of dotted keys. When an attacker supplies a TOON payload containing these keys, particularly within nested structures or via paths like a._proto_.x, the decoding logic fails to treat them as standard own properties. Instead, it traverses up the object prototype chain, inadvertently modifying Object.prototype itself. This behavior is consistent with CWE-1321: Prototype Pollution, where an attacker can inject properties into JavaScript objects' prototypes, leading to unpredictable application state and potential security breaches.
The operational impact of this vulnerability extends beyond simple data corruption. By polluting Object.prototype, the attack affects all subsequent object instantiations within the same runtime environment that do not explicitly override these polluted properties. This leads to a denial of service scenario where legitimate applications may crash or behave erratically due to unexpected property values inherited from the prototype chain. More critically, if the application utilizes downstream gadgets such as unsafe deserialization patterns or specific library functions that rely on object structure integrity, this pollution can be chained with other vulnerabilities to achieve remote code execution. The vulnerability is not limited to simple nested objects; it also affects tabular row representations, quoted keys, and streaming decode operations, indicating a systemic flaw in the expandPaths safe mode implementation within packages/toon/src/decode/expand.ts.
Furthermore, the encoder component of TOON exhibits related weaknesses that exacerbate the risk profile. During normalization processes, the encoder may drop own _proto_ properties or invoke inherited setters when handling certain inputs. This inconsistency between encoding and decoding behaviors can lead to data integrity issues and further opportunities for exploitation if an attacker can manipulate the input stream before it reaches the decoder. The combination of these flaws means that any service accepting untrusted TOON-formatted LLM prompts is at significant risk, as the attack vector does not require complex manipulation but rather specific key naming conventions that are common in JavaScript object structures.
To mitigate this vulnerability, organizations must immediately upgrade to version 2.3.1 or later of the TOON library, which addresses these prototype pollution vectors by enforcing strict checks on reserved property names and preventing their propagation up the prototype chain. Additionally, developers should implement input validation strategies that sanitize incoming data before it is processed by serialization libraries. It is also advisable to use Object.create(null) when creating objects intended for dynamic key assignment to avoid inheriting from Object.prototype entirely. From a defense-in-depth perspective, integrating static analysis tools and runtime application self-protection mechanisms can help detect attempts at prototype pollution in real-time. This incident underscores the importance of rigorous validation in serialization libraries used within AI-driven applications, aligning with ATT&CK techniques related to input manipulation and potential privilege escalation through environmental state modification.