CVE-2026-82404

What it actually does

Untrusted TOON decode prior to 2.3.1 can write through the JavaScript prototype chain when input contains __proto__, constructor, or prototype keys. Instead of creating own properties, the decoder mutates Object.prototype for the entire runtime. The expandPaths 'safe' path and insertPathSafe handling of dotted keys are the strongest vectors; nested objects, tabular rows, quoted keys, and streaming decode are also affected. The encoder can drop own __proto__ properties and invoke inherited setters during normalization. Impact ranges from process-wide denial of service to remote code execution when a downstream gadget exists.

Why it matters to the business

Any service that decodes untrusted TOON—especially LLM prompt pipelines that accept compact serialized JSON from users or untrusted tools—can be crashed or, if other vulnerable code is present, taken over. There is no CISA KEV listing, no reported ransomware use, and exploit maturity is none, but the issue has been public for about a month with a network-reachable, unauthenticated CVSS 8.3 rating and changed scope. Outages, integrity loss in shared runtimes, and potential code execution in prompt-processing backends are the primary operational risks.

How an attack unfolds

An unauthenticated attacker sends TOON-encoded data to an application that decodes it with a vulnerable toon package. The payload uses reserved prototype-chain keys so that decode and path expansion assign onto Object.prototype rather than an isolated object. After pollution, every object in the Node.js or browser-like runtime inherits attacker-controlled properties. That can break control flow, authentication checks, or template/merge logic (denial of service). If the application later uses a known prototype-pollution gadget (for example unsafe merges, template engines, or child-process options), the same pollution can be turned into remote code execution. No named threat actors or in-the-wild campaigns are associated with this CVE.

How to fix it

Upgrade the toon package to 2.3.1 or later, which stops prototype-chain writes during decode and corrects encoder normalization of __proto__. Rebuild and redeploy every service, worker, and LLM prompt pipeline that depends on toon. Do not treat expandPaths: 'safe' as a substitute for the patch. Until upgraded, avoid decoding untrusted TOON and isolate decode in short-lived processes that are discarded after each request. Pin lockfiles so transitive dependents cannot pull a vulnerable 2.3.0 or earlier release.

How to confirm the fix worked

Confirm installed toon is 2.3.1 or newer in package manifests and lockfiles (including transitive LLM/prompt tooling). After upgrade, decode representative untrusted TOON—including nested objects, tabular rows, quoted keys, streaming input, and dotted paths—and assert that Object.prototype and constructor.prototype gain no new enumerable or unexpected properties and that inherited setters are not invoked. Regression-test encoder output so own __proto__ data is not silently dropped. Inventory call sites that decode external TOON and verify they run the patched build.

Typical attack path

1. Locate a service or library path that decodes TOON from untrusted clients, files, or LLM tool output.
2. Submit TOON that uses __proto__, constructor, or prototype keys, including dotted path forms processed by expand/insert-path logic.
3. Trigger decode (including nested, tabular, quoted-key, or streaming modes) so assignments land on Object.prototype.
4. Observe runtime-wide behavior change: crashes, failed checks, or inherited properties on unrelated objects.
5. If a suitable gadget exists downstream, chain the pollution into further integrity loss or code execution; otherwise maintain denial of service.

How to detect it

There is no KEV listing, no named actor, and exploit maturity is none, so confirmed mass exploitation is not reported; still hunt because the bug is unauthenticated. Review application and reverse-proxy logs for TOON bodies or query fields containing prototype-chain keys around decode endpoints. In Node.js processes that decode TOON, inspect Object.prototype (and Function/Object constructors) for unexpected own properties, especially after crashes or logic failures. Look for worker/process restarts, uncaught TypeErrors after ingest, and encoder/normalization errors involving inherited setters. Container and host forensics should focus on long-lived runtimes rather than dropped files. Correlate LLM gateway logs with decode exceptions in packages/toon decode paths.

• __proto__
• constructor.prototype
• a.__proto__
• expandPaths
• insertPathSafe
• packages/toon/src/decode/expand.ts

What your security team should do

• Patch all toon usages to 2.3.1 or later immediately; this is a network-unauthenticated prototype-pollution bug with changed scope.
• Inventory LLM prompt pipelines, agents, and APIs that accept or decode TOON from users or tools; treat those as internet-exposed even if behind an app tier.
• Until patched, block or sandbox untrusted TOON decode and recycle decoder processes after each job.
• Hunt for unexpected properties on Object.prototype in long-lived Node.js services that have decoded TOON since publication.
• Re-scan lockfiles and container images for toon < 2.3.1 and fail CI on vulnerable versions.