CVE-2022-37601 is a prototype pollution vulnerability in the parseQuery function of the webpack loader-utils package, and it is fixed by upgrading to version 1.4.1 or 2.0.3. The flaw sits in parseQuery.js, where a crafted name value in a query string can inject properties into an object's prototype. It carries a critical CVSS 3.1 base score of 9.8.
If you build front-end code with webpack, loader-utils is almost certainly somewhere in your dependency tree, usually pulled in transitively by loaders you never installed directly. That is what makes this one easy to miss.
What loader-utils does and why it matters
loader-utils is a small utility package used by webpack loaders to parse loader options and query strings. Loaders such as css-loader, file-loader, and many others depend on it. Because it is a transitive dependency for most projects, a lot of teams carried the vulnerable version without ever adding it to package.json themselves.
The vulnerable code path is parseQuery, which turns a query string on a resource request into an options object. Handling a value like __proto__ or constructor without guarding against it is the classic setup for prototype pollution.
How prototype pollution works, briefly
In JavaScript, almost every object inherits from Object.prototype. Prototype pollution is when an attacker manages to set a property on that shared prototype. Because the property is inherited by every object, code elsewhere that reads it can behave unexpectedly — a flag that should be false suddenly reads as attacker-controlled, a missing config value is now populated, and so on.
Conceptually, a malicious query string carrying a __proto__ payload gets parsed and the polluting key ends up modifying the prototype rather than a plain data property. The public advisories describe the impact as ranging from denial of service to, in the wrong context, a path toward code execution. The exact severity in your app depends on what downstream code trusts.
We are describing the mechanism, not shipping a working exploit — the point is to recognize the pattern and remediate, not to weaponize it.
Affected versions and the fix
According to the GitHub Advisory Database and NVD, the vulnerability affects loader-utils before the patched releases. The remediation is a version bump:
- Upgrade to
loader-utils1.4.1if you are on the 1.x line. - Upgrade to
2.0.3or later if you are on the 2.x line.
In practice you rarely edit loader-utils directly. You update the parent loaders that depend on it, or you force a resolution. With npm you can pin a safe version using overrides in package.json:
{
"overrides": {
"loader-utils": ">=2.0.3"
}
}
With Yarn, the equivalent is a resolutions field. After changing it, delete the lockfile entry or run a fresh install and confirm the resolved version:
npm ls loader-utils
If the tree still shows a version below 2.0.3 (or below 1.4.1 on the 1.x branch), a parent dependency is pinning the old one and you need to bump that parent too.
Finding it in your projects
Prototype pollution in a transitive dependency is exactly the kind of thing manual review misses. The dependency is not in your direct manifest, and the vulnerable version can hide several levels deep. Running npm audit will surface it, and a dedicated software composition analysis scan will show the full transitive path so you know which parent to upgrade. An SCA tool such as Safeguard can flag this transitively and point to the shortest remediation path.
Two loader-utils prototype pollution CVEs were disclosed close together in late 2022, so when you remediate, confirm you have cleared all of them rather than just the one you were chasing.
Verifying the fix
After upgrading, do three things:
- Re-run
npm ls loader-utilsand confirm every instance is at a patched version. - Re-run your scanner and confirm CVE-2022-37601 no longer appears.
- Run your build and test suite.
loader-utilschanges here are backward compatible, so a green build is the expected outcome.
Because this is a build-time dependency, the risk is mostly relevant during development and CI rather than at runtime in production. That does not make it safe to ignore — a poisoned build toolchain is a supply-chain problem — but it does mean the fix is low-risk to apply.
FAQ
Is CVE-2022-37601 exploitable in production?
loader-utils is a build-time dependency, so the parsing code generally runs during bundling rather than in your shipped application. The main exposure is your development and CI environments, which is still worth protecting. Upgrade regardless.
What CVSS score does CVE-2022-37601 have?
Public sources including the GitHub Advisory Database rate it as critical with a CVSS 3.1 base score of 9.8, reflecting the potential impact of prototype pollution. Real-world impact in your app depends on what downstream code trusts.
How do I know if I even use loader-utils?
Run npm ls loader-utils. If it prints any version, it is in your tree, almost always pulled in by a webpack loader you installed. If the command returns nothing, you are not affected.
Do I need to change my own code?
No. The fix is a dependency version bump to 1.4.1 or 2.0.3 (or later), typically applied via your loaders or an overrides/resolutions entry. No application code changes are required.