TOON: Prototype pollution when decoding untrusted TOON input

Summary

Decoding attacker-controlled TOON containing a __proto__, constructor, or prototype key wrote through the object's prototype chain instead of creating an own property, polluting Object.prototype for the whole runtime. The expandPaths: 'safe' path (dotted keys such as a.__proto__.x) was the strongest vector; plain nested objects, tabular rows, and quoted keys were all affected. The encoder had a matching defect: it silently dropped own __proto__ properties and could fire an inherited setter while normalizing.

Impact

Any service that decodes untrusted TOON is affected. Prototype pollution can escalate to denial of service or, with a suitable downstream gadget, remote code execution.

Patches

Upgrade to @toon-format/toon@2.3.1. Decoders now materialize __proto__/constructor/prototype as ordinary own data properties, matching JSON.parse semantics; the encoder preserves the same keys without invoking inherited accessors.

Workarounds

None. Upgrade is the only fix. Callers who cannot upgrade should reject input whose keys include __proto__, constructor, or prototype before decoding.

Port maintainers

The same bug shape can exist in any implementation that assigns decoded keys with obj[key] = value. Rust, Swift, Java, Python, and C# ports should audit their object-construction and path-expansion paths for the three prototype keys.