threat-model.md
The Lodash threat model defines what Lodash trusts and does not trust when executing within a JavaScript environment. Lodash is a general-purpose utility library that operates within the same trust boundaries as the code that calls it. Therefore, vulnerabilities requiring the compromise of trusted elements — such as the JavaScript runtime, the host environment, or developer-controlled inputs — lie outside the scope of this threat model.
For a vulnerability to be considered within scope, it must result from Lodash itself violating its documented behavior or failing to maintain integrity, confidentiality, or availability under its standard usage assumptions.
Data provided to Lodash functions
Lodash treats all input data (arrays, objects, strings, functions, etc.) as untrusted. It does not attempt to validate or sanitize the semantic correctness of inputs — it operates on values as they are given.
If an untrusted input can cause Lodash to execute behavior beyond what is documented — such as prototype pollution, type confusion, memory exhaustion, or code injection — that would indicate a security vulnerability.
Untrusted network sources or user-controlled data
Any input derived from unvalidated user input, network responses, file contents, or deserialized data is untrusted. Lodash does not perform input isolation or sandboxing.
Tampering with Lodash internals at runtime
Modifying Lodash’s internal symbols, monkey-patching its functions, or overwriting internal references at runtime is outside the trusted boundary.
If such modification changes Lodash behavior, that reflects a compromise of trusted code, not a Lodash vulnerability.
The JavaScript runtime and its standard library
Lodash assumes a correct, uncompromised runtime environment (e.g., Node.js, browser). Vulnerabilities in the runtime (e.g., prototype chain issues, engine crashes) are out of scope.
The environment and its configuration
Lodash relies on the correct functioning of the host environment (Node.js, browser, Deno, etc.) and any global objects or APIs it uses (e.g., Object, Array, Function, JSON).
The code that invokes Lodash
The application or library using Lodash is responsible for validating user input, performing security checks, and handling execution context appropriately.
Installed package integrity
Lodash assumes that the package installed (via npm, cdn, etc.) has not been tampered with and originates from the legitimate Lodash distribution channel.
Supply-chain compromise or malicious clones are not considered Lodash vulnerabilities.
The privileges and permissions of the execution context
Lodash inherits the privileges of the user or process that invokes it. Misuse or over-privileged execution environments (e.g., running as root, or with excessive browser permissions) are not within scope.
Prototype Pollution (CWE-1321)
If a Lodash function (e.g., merge, defaultsDeep, or set) allows modification of Object.prototype properties via untrusted input (e.g., __proto__ keys) due to insufficient sanitization, it is in scope.
This class of vulnerability has been observed in prior Lodash versions (e.g., CVE-2019-10744).
Unexpected code execution (CWE-94)
If a Lodash method (e.g., template()) executes attacker-controlled input as code without documented warnings or sanitization requirements, that is a Lodash vulnerability (e.g., CVE-2021-23337).
Denial of Service (DoS) through logic flaws (CWE-400)
If Lodash enters unbounded recursion, excessive memory usage, or hangs when operating on otherwise valid inputs within documented usage limits, this is a vulnerability in Lodash (e.g, CVE-2020-28500).
_.templateThe current implementation of _.template compiles template strings into executable code, which can lead to code injection when given untrusted input (e.g., CVE-2021-23337). For that reason we consider it insecure and advise against its use.
We plan to remove _.template in Lodash v5. Until then it remains available; if you continue to use it, we recommend using only developer-controlled, static template strings and trusted data, and avoiding untrusted input (e.g. user-controlled data or unvalidated network content) in both the template string and the data passed to the compiled function.
If a project includes a malicious dependency that overrides Lodash behavior or injects malicious code into Lodash’s namespace, it does not represent a Lodash vulnerability. Lodash trusts its runtime and installation context.
Applications using Lodash are responsible for input validation. Passing attacker-controlled data directly into Lodash functions (e.g., _.merge(req.body, config)) is an application bug, not a Lodash vulnerability.
If a developer intentionally merges user input into global objects or fails to isolate data structures, that is a misuse of Lodash’s documented API, not a Lodash defect.
If a Lodash method triggers a bug in the JavaScript engine (e.g., V8, SpiderMonkey, JavaScriptCore) that leads to memory corruption or incorrect behavior, the vulnerability lies in the engine, not Lodash.
Issues arising from misconfigured execution environments, such as running outdated Node.js versions or insecure Content Security Policies in browsers, are not considered Lodash vulnerabilities.
Tampering with Lodash packages in the npm registry, MITM attacks during installation, or local file system manipulation are not vulnerabilities in Lodash itself.
Lodash is a utility library operating entirely within the trust boundary of its caller. Vulnerabilities in scope are limited to cases where Lodash fails to uphold its documented behavior in the presence of untrusted input, without assuming compromise of trusted components such as the runtime, the operating system, or the invoking application code.