CVE-2026-4800

What it actually does

This vulnerability affects Lodash template compilation. The previous validation added for the _.template variable option did not also validate key names supplied through options.imports, even though both are ultimately used to build arguments to the JavaScript Function() constructor. If an application allows attacker-controlled imports key names, an attacker can craft a key that is interpreted as JavaScript syntax, such as a default-parameter expression, causing arbitrary code execution when the template is compiled. A secondary risk exists when Object.prototype has already been polluted by another flaw: Lodash uses assignInWith in a way that can enumerate inherited properties and copy polluted keys into the imports object, allowing prototype pollution to become code execution through the same Function() sink.

Why it matters to the business

Successful exploitation can allow a remote attacker to run arbitrary code in the context of the vulnerable application process, potentially leading to data theft, service disruption, credential exposure, lateral movement, or full compromise of application infrastructure. The issue is especially important because Lodash is widely embedded directly and transitively across JavaScript applications, including lodash, lodash-amd, lodash-es, and lodash.template. Although the CVSS score is high, exploitation generally requires a specific unsafe application pattern: untrusted input must influence options.imports key names, or a separate prototype pollution condition must already exist. The vulnerability is not currently listed in CISA KEV and no exploit maturity was reported in the provided data, but the affected ecosystem is broad enough that dependency inventory and patching should be prioritized.

How an attack unfolds

An attacker first identifies an application path that compiles Lodash templates and allows user-controlled data to influence _.template options, especially options.imports key names. The attacker then submits a crafted imports key that is valid in the generated Function() parameter list but contains a default-parameter expression or similar JavaScript syntax. When the application calls _.template, Lodash merges imports and constructs a new Function() using the unvalidated key names. During template compilation, the injected expression is evaluated, allowing the attacker to execute JavaScript in the server-side runtime if templates are compiled server-side. In Node.js environments, this may be escalated to operating-system command execution by reaching require, process, child_process, or equivalent primitives. In a second exploitation path, the attacker or another vulnerability first pollutes Object.prototype with a malicious inherited property name; when Lodash merges imports using inherited enumerable keys, that polluted key can be copied into the imports object and passed to Function(), producing the same code execution effect.

How to fix it

Upgrade affected Lodash packages to version 4.18.0 or later where available, including lodash, lodash-amd, lodash-es, and lodash.template. Because Lodash is often present as a transitive dependency, update lockfiles and rebuild applications rather than only changing top-level package manifests. If immediate upgrade is not possible, ensure applications never pass untrusted input as options.imports key names; only use developer-controlled, static, hardcoded import names. Treat all dynamic construction of _.template options as unsafe until reviewed. Also remediate any prototype pollution vulnerabilities in the same application, because polluted Object.prototype keys can be copied into imports and reach the same Function() constructor sink. As a defense-in-depth measure, restrict server-side template compilation from request-time user input, run application processes with least privilege, and block unnecessary operating-system command execution from application runtimes where feasible.

How to confirm the fix worked

Confirm that dependency manifests and resolved lockfiles no longer contain vulnerable Lodash package versions and that affected packages resolve to 4.18.0 or later. Use software composition analysis, npm/yarn/pnpm dependency tree inspection, and container image scanning to identify bundled or transitive copies. Search code for _.template, lodash.template, templateSettings.imports, and options.imports usage, then verify that imports key names are static and developer-controlled. Add tests that attempt to pass malicious imports key names containing default-parameter syntax and confirm they are rejected or not evaluated. Where prototype pollution has been a risk, add tests that pollute Object.prototype with enumerable properties before template compilation and confirm those inherited keys are not copied into the generated function. Validate deployed artifacts, not only source repositories, because JavaScript dependencies are frequently bundled into built assets or containers.

Typical attack path

1. Locate an application endpoint, API, plugin, build step, or rendering path that uses Lodash _.template or lodash.template.
2. Determine whether user-controlled input can affect options.imports key names, not just import values.
3. Craft an imports key that injects JavaScript syntax, such as a default-parameter expression, into the generated Function() constructor parameter list.
4. Submit the payload through the vulnerable input path, or first trigger a prototype pollution primitive that adds a malicious inherited enumerable property.
5. Cause the application to compile the Lodash template.
6. Execute arbitrary JavaScript during template compilation in the application process.
7. Use runtime primitives such as process, require, or child_process in Node.js to read files, access secrets, run commands, or establish persistence.

How to detect it

To determine whether this was already exploited, review application, API gateway, web server, and WAF logs for request parameters or JSON keys that appear to target Lodash template options, especially imports, templateSettings, or _.template-related configuration. Look for JavaScript syntax embedded in object key names rather than only in values, including default-parameter expressions, require/process access, Function constructor usage, and child_process references. In Node.js environments, correlate suspicious requests with process telemetry showing unexpected child processes spawned by the application runtime, such as sh, bash, curl, wget, nc, python, perl, powershell, or cmd.exe. Review application error logs for syntax errors thrown during template compilation, Function constructor failures, or unexpected parameter parsing errors near Lodash template execution. If prototype pollution may have been involved, search logs and telemetry for suspicious __proto__, constructor, and prototype parameters before template compilation events. For forensics, inspect deployed source, runtime configuration, uploaded templates, plugin metadata, and cached template artifacts for malicious imports keys or injected JavaScript. Also examine outbound network telemetry for unexpected connections from application servers shortly after suspicious template compilation errors or Node.js child-process activity.

• options.imports
• templateSettings.imports
• _.template
• lodash.template
• __proto__
• constructor.prototype
• prototype.polluted
• child_process
• require('child_process')
• require("child_process")
• process.mainModule.require
• process.binding
• constructor.constructor
• Function(
• execSync(
• spawnSync(
• exec(
• curl
• wget
• /bin/sh
• /bin/bash
• cmd.exe
• powershell.exe
• SyntaxError: Arg string terminates parameters early
• SyntaxError: Unexpected token '='
• SyntaxError: Malformed arrow function parameter list

What your security team should do

• Inventory all applications, packages, containers, and build artifacts that include lodash, lodash-amd, lodash-es, or lodash.template.
• Prioritize remediation for internet-facing services, server-side rendering paths, plugin systems, template editors, CMS-like functionality, and applications that compile templates at request time.
• Upgrade affected Lodash packages to 4.18.0 or later and refresh lockfiles to remove vulnerable transitive versions.
• Perform focused code review for _.template calls where options.imports, templateSettings.imports, or template options are derived from request parameters, JSON bodies, configuration uploaded by users, database content, or plugin metadata.
• Search for and remediate prototype pollution vulnerabilities in the same applications, because they can turn this issue into code execution even when imports are not directly user-controlled.
• Add regression tests preventing untrusted imports key names and inherited Object.prototype keys from reaching template compilation.
• Hunt historical logs for suspicious template option keys, JavaScript default-parameter payloads, child_process usage, and unexpected shell commands spawned by Node.js application processes.
• Apply runtime least privilege, egress restrictions, secret isolation, and process monitoring to reduce impact if template compilation is abused.