Description

flat-to-nested converts a hierarchy from a flat representation to a nested representation. Prior to 1.1.2, FlatToNested.prototype.convert in index.js uses attacker-influenced id and parent record fields directly as keys in the plain temp and pendingChildOf objects. When parent or id is __proto__, temp[parent] can resolve to Object.prototype, and initPush() can write attacker-controlled data to the global children prototype property while existing prototype methods remain intact. Any application that passes attacker-influenced flat records to convert() can therefore expose unrelated objects to polluted inherited state, causing application-logic corruption or denial of service and potentially enabling greater impact when a downstream prototype-pollution gadget is present. The constructor and prototype strings are also unsafe inherited-key values in the same lookup design. This issue is fixed in version 1.1.2.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-14T18:17:54.790Z",
  "pubdate": "2026-09-14T18:17:54.790Z",
  "executiveSummary": "The flat-to-nested package is vulnerable to prototype pollution prior to version 1.1.2 due to improper handling of object keys derived from user-supplied input.\nThe vulnerability originates in the FlatToNested.prototype.convert function within index.js, where attacker-controlled 'id' and 'parent' fields are used as object keys without validation.\nBy manipulating these fields to include special properties such as '__proto__', 'constructor', or 'prototype', an attacker can inject arbitrary properties into the global Object.prototype.\nThis impact is severe, as it allows for the corruption of application logic across the entire runtime environment, potentially leading to denial-of-service conditions or providing a vector for further exploitation via downstream prototype-pollution gadgets.\nSuccessful exploitation requires the application to pass untrusted data directly to the convert() method. There are no specific authentication or privilege requirements to trigger the vulnerability, as the logic itself is inherently flawed when processing external data.\nUsers are strongly advised to update to version 1.1.2 or later to remediate this issue.",
  "technicalDetails": "The root cause of the vulnerability lies in the implementation of FlatToNested.prototype.convert in index.js, which creates temporary storage objects ('temp' and 'pendingChildOf') using user-provided object keys. The implementation fails to sanitize or blacklist dangerous keys such as '__proto__', 'constructor', and 'prototype'.\nIn JavaScript, accessing 'temp['__proto__']' resolves directly to the Object.prototype. When the library proceeds to assign values to these keys, it inadvertently modifies the prototype of all objects within the application. Specifically, the initPush() function writes data to these objects, allowing an attacker to inject properties into the global scope.\nThe attack flow begins when an application accepts a flat array of records from an untrusted source and passes this array to the convert() method. An attacker crafts a malicious record containing a key such as 'parent: \"__proto__\"' or 'id: \"__proto__\"'.\nWhen the convert() function iterates through these records, the line 'temp[parent] = ...' (or equivalent key-assignment logic) results in the prototype of the 'temp' object being modified. Because 'temp' shares the global Object prototype, this modification persists throughout the application lifecycle.\nThe exploitation allows an attacker to override existing built-in properties or introduce new properties that downstream components may implicitly trust. For example, if an application checks for an 'isAdmin' property on an object, an attacker can use this vulnerability to define 'isAdmin: true' on Object.prototype, forcing the application to treat every object as having administrative privileges.\nFurthermore, the use of 'constructor' and 'prototype' strings allows attackers to manipulate the prototype chain through 'Object.prototype.constructor.prototype', which further facilitates deep object state corruption. The lack of input validation enables this arbitrary property injection, which can lead to application instability, data corruption, or the bypass of security-sensitive logic depending on the available code gadgets within the application environment."
}