GHSA-w2cq-g8g3-gm83
content-security-policy-parser Prototype Pollution Vulnerability May Lead to RCE
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
Weekly download volume for affected packages — a proxy for how broadly this vulnerability is deployed.
content-security-policy-parsernpmDescription
Impact
A prototype pollution vulnerability exists in versions 0.5.0 and earlier, wherein if you provide a policy name called __proto__ you can override the Object prototype.
For example:
const parse = require('content-security-policy-parser');
const x = parse("default-src 'self'; __proto__ foobar");
console.log('raw print:', x);
console.log('toString:', x.toString());
Outputs:
raw print: Array { 'default-src': [ "'self'" ] }
toString: foobar
Whilst no gadget exists in this library, it is possible via other libraries expose functionality that enable RCE. It is customary to label prototype pollution vulnerabilities in this way. The most common effect of this is denial of service, as you can trivially overwrite properties.
As the content security policy is provided in HTTP queries, it is incredibly likely that network exploitation is possible.
Patches
There has been a patch implemented a year ago (11 Feb 2024), but low uptake of patched versions has not been observed in the wild - only 17% of weekly downloads are of patched versions.
Workarounds
By disabling prototype method in NodeJS you can neutralise all possible prototype pollution attacks. Provide either --disable-proto=delete (recommended) or --disable-proto=throw as an argument to node to enable this feature.
References
Issue revealing the problem, January 26 2024 Commit fixing the problem
Credit to @EvanHahn for patching the vulnerability promptly, and @pnappa (Patrick Nappa) for discovery.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | content-security-policy-parser | all versions | 0.6.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for content-security-policy-parser. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update content-security-policy-parser to 0.6.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-w2cq-g8g3-gm83 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-w2cq-g8g3-gm83 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-w2cq-g8g3-gm83. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-w2cq-g8g3-gm83 in your dependencies?
O3 detects GHSA-w2cq-g8g3-gm83 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.