Introduction
lodash's _.template() function compiles a string into an executable JavaScript function — that's the whole point of it. It accepts an imports option that lets callers inject named variables into the compiled function's scope. CVE-2026-4800 describes exactly the failure mode you'd expect from that design: when untrusted input is allowed to flow into the template string or into the imports map, lodash can end up compiling and running attacker-supplied JavaScript rather than the developer's intended template.
This matters for a very ordinary category of application code: anything that builds HTML, email bodies, config snippets, or report output by handing user-influenced strings to a templating helper. If that helper is lodash's _.template(), and the imports option (or the template body itself) is reachable by request data, the templating engine becomes a code-execution primitive instead of a string formatter.
The remediation that landed here is a dependency bump, not a first-party code change — the project's own code wasn't touched at all. The pull request upgrades lodash in the lockfile and flags, in its own description, that the author "has not verified that your code reaches the affected function." That caveat is worth taking seriously, and we'll come back to it.
Affected Versions
| Affected | unknown |
| Fixed in | unknown |
| Ecosystem | npm |
| CVE / GHSA | CVE-2026-4800 / not assigned |
| CWE | unknown |
No GHSA advisory has been assigned yet, and the precise vulnerable version range for lodash hasn't been published at the time of this fix. What is known from the dependency tree: the project was pinned to lodash 4.17.21 before this change.
The Vulnerability Explained
The underlying flaw lives inside lodash itself — specifically in how _.template() handles the imports option when building its compiled function. Conceptually, _.template() works by stitching caller-provided pieces (the template string, variable names from imports) into source code that it then evaluates. If any of those pieces originate from untrusted input — a template body sourced from user content, or imports keys/values built from request data — the compiled function can contain logic the developer never intended, including code that executes arbitrary statements.
The lockfile shows exactly where the vulnerable version sat in this project's dependency tree:
"node_modules/lodash": {
- "version": "4.17.21",
+ "version": "4.18.1",
Nothing else in this repository's own code changed — the exposure, if any, lived entirely inside lodash's packaged source for _.template(), not in application logic.
Attack scenario: picture a service that lets users customize a notification message, and the backend renders that customization with _.template(), passing in some computed values through imports for convenience. If the service doesn't strictly separate "static template defined by the developer" from "user-supplied content," an attacker who can influence the template string or the imports map could smuggle in a payload that lodash compiles into executable code. The result isn't a cross-site scripting issue confined to a browser — it's code execution inside whatever process is running _.template(), which could be a Node.js backend with filesystem and network access.
The Fix
Because the vul