flawopen.com/Prototype Pollution/lodash.merge()
Is lodash.merge() safe from prototype pollution?
Think of a deep merge as copying labels from someone else’s nested filing cabinet into your application’s master records. Older Lodash paths could treat special property names as directions into shared prototype state; newer fixes block known paths, but copying every request field still creates mass-assignment risk. Validate the fields your application accepts.
const _ = require("lodash");
const settings = {};
const input = request.body;
_.merge(settings, input);
_.set(settings, request.query.path, request.query.value);
const allowedLocales = new Set(["en", "fr"]);
const input = request.body;
const settings = {
theme: input.theme === "dark" ? "dark" : "light",
locale: allowedLocales.has(input.locale)
? input.locale
: "en",
};
How the vulnerability path works
On an affected release, untrusted JSON or a caller-controlled path reaches a vulnerable Lodash helper. A recursive merge or path operation mishandles a special path component and changes or deletes a property on a built-in prototype. Other code may then read that inherited property; the effect depends on the property and the application’s reachable gadget. Prototype pollution alone does not prove remote code execution.
The npm lodash advisories have different scopes: CVE-2018-16487 affected defaultsDeep, merge, and mergeWith before 4.17.11; CVE-2019-10744 covered defaultsDeep before 4.17.12; CVE-2020-8203 covered pick, set, setWith, update, updateWith, and zipObjectDeep before 4.17.19. CVE-2025-13465 affected unset and omit through 4.17.22, fixed in 4.17.23. CVE-2026-2950 then affected those two methods in 4.17.23, fixed in 4.18.0. The latest release checked for this guide is 4.18.1. These ranges are package-specific: verify the advisory for lodash-es, modular packages, or OS-distributed builds separately.
How to check and remediate your dependency
npm install lodash@^4.18.1
npm ls lodash
npm audit
npm explain lodash
Upgrade the direct and transitive copies, commit the updated lockfile, and inspect vendored or bundled copies. Keep request data out of deep merges and path APIs; build a new object from validated, allowlisted fields. The hardened example avoids attacker-selected keys and paths. As checked on 2026-10-05, Lodash 4.18.1 is the latest release; follow the project advisory for any later security fix.
FAQ
The reviewed advisories for the npm lodash package list the relevant fixes in later releases; 4.18.1 is the latest release checked here. Keep it updated, verify every installed copy, and still avoid merging request bodies wholesale because that can cause mass assignment.
No. Pollution changes or deletes inherited properties. Impact depends on what the application later reads or invokes, and whether that creates a reachable security-sensitive gadget. Describe the demonstrated effect rather than assuming RCE.
Not necessarily. Advisories may list different affected and fixed releases for each package. Check the exact package name, lockfile entry, and advisory instead of applying the main lodash cutoff to every distribution.
References
- GitHub Advisory — CVE-2018-16487 / GHSA-4xc9-xhrj-v574
- GitHub Advisory — CVE-2019-10744 / GHSA-jf85-cpcp-j695
- GitHub Advisory — CVE-2020-8203 / GHSA-p6mc-m468-83gw
- GitHub Advisory — CVE-2025-13465 / GHSA-xxjr-mmjv-4gpg
- Lodash Advisory — CVE-2026-2950 / GHSA-f23m-r3pf-42rh
- Lodash 4.18.1 release and security changelog
- CWE-1321 — Prototype Pollution
- What is prototype pollution?
- What is mass assignment?