To better understand which classes of vulnerabilities are considered in-scope or out-of-scope for Lodash, please review the [Lodash Threat Model](./threat-model.md).

The threat model defines Lodash’s trust boundaries and clarifies how security issues are assessed for triage and disclosure.

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.

1. **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.*

2. **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.

3. **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.*

1. **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.

2. **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`).

3. **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.

4. **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.*

5. **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](https://cwe.mitre.org/data/definitions/1321.html))**

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](https://www.cve.org/CVERecord?id=CVE-2019-10744)).

- **Unexpected code execution ([CWE-94](https://cwe.mitre.org/data/definitions/94.html))**

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](https://nvd.nist.gov/vuln/detail/CVE-2021-23337)).

- **Denial of Service (DoS) through logic flaws ([CWE-400](https://cwe.mitre.org/data/definitions/400.html))**

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](https://www.cve.org/CVERecord?id=CVE-2020-28500)).

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.