CVE-2026-4800 is a code injection flaw in lodash's _.template, scored CVSS 8.1 (high). Untrusted key names in options.imports can run code when a template compiles. The fix is lodash 4.18.1, which also covers lodash-es, lodash-amd and lodash.template. Upgrade, or stop passing untrusted input as import keys.
What's affected
The GitHub advisory lists four npm packages, all in the range 4.0.0 up to but not including 4.18.1:
- lodash
- lodash-es
- lodash-amd
- lodash.template
The patched version is 4.18.1 for each of them.
The issue only matters for applications that call _.template and pass untrusted input as key names in options.imports. The vector in the NVD record is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. High complexity reflects those conditions.
The advisory also describes a second path. _.template merged imports with assignInWith, which also copies inherited properties. If Object.prototype has been polluted through some other flaw, the polluted keys can reach the same code.
How to check if you're exposed
Find every copy of the four packages in your project tree, including transitive ones.
npm ls lodash lodash-es lodash-amd lodash.template
For Yarn, use yarn why lodash. For pnpm, use pnpm why lodash.
Each copy below 4.18.1 is affected. Lodash is often nested under other packages, so a project can hold several versions at once.
Then search your own code for template use.
grep -rn "_.template\|lodash.template\|lodash/template" src/
If you call the function, look at where the imports option gets its keys. Static keys written by developers are safe in the sense of this advisory. Keys built from request data are not. A reachability analysis tells you which services call the template function at all.
What to do now
- Run npm ls for the four packages in each repository and each container image build.
- Upgrade to 4.18.1. For nested copies, update the parent package, or force the version with an overrides entry in package.json (resolutions in Yarn).
- Reinstall, rebuild and redeploy. Check the lockfile shows no copy below 4.18.1.
- As the advisory's workaround, never pass untrusted input as key names in options.imports. Use fixed keys written in code.
- Add a check in CI that fails the build when a vulnerable lodash version appears.
Why it matters
The weakness is CWE-94, code injection. The advisory explains that the earlier fix for CVE-2021-23337 validated the variable option of _.template but did not apply the same validation to the key names in options.imports. Both reach the same Function constructor, which builds code from strings. The 4.18.1 fix applies the same character validation to import keys and copies only own properties.
This is a good example of a follow up bug: a fix that guards one path to a dangerous function while another path stays open. It also shows why a prototype pollution bug elsewhere can raise the risk of an unrelated library. The record's KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is CVE-2026-4800 exploited in the wild?
The record's KEV flag is false, and the pages I read do not say it is exploited. Treat it as a patch item and keep an eye on the advisory for changes.
Am I safe if I never use _.template?
If no code path calls it, the vulnerable function is not used by your code. Upgrade anyway, and check dependencies that might call it for you.
Sources
Last reviewed: 19 October 2026.
