CVE-2026-33994 — locutus
Fix: locutusjs/locutus@345a621CVE-2026-33994 is a CWE-1321 vulnerability in locutus. A fix is available for locutus — see the affected versions and patch details below.
Locutus Prototype Pollution due to incomplete fix for CVE-2026-25521
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-33994.
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.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
locutusnpmDescription
Summary
A prototype pollution vulnerability exists in the parse_str function of the npm package locutus. An attacker can pollute Object.prototype by overriding RegExp.prototype.test and then passing a crafted query string to parse_str, bypassing the prototype pollution guard.
This vulnerability stems from an incomplete fix for CVE-2026-25521. The CVE-2026-25521 patch replaced the String.prototype.includes()-based guard with a RegExp.prototype.test()-based guard. However, RegExp.prototype.test is itself a writable prototype method that can be overridden, making the new guard bypassable in the same way as the original — trading one hijackable built-in for another.
Package
locutus (npm)
Affected versions
= 2.0.39, <= 3.0.24
Tested and confirmed vulnerable on 2.0.39 and 3.0.24 (latest). Version 2.0.38 (pre-fix) uses a different guard (String.prototype.includes) and is not affected by this specific bypass.
Description
Details
The vulnerability resides in parse_str.js where the RegExp.prototype.test() function is used to check whether user-provided input contains forbidden keys:
if (/__proto__|constructor|prototype/.test(key)) {
break
}
The previous guard (fixed in CVE-2026-25521) used String.prototype.includes():
if (key.includes('__proto__')) {
break
}
The CVE-2026-25521 fix correctly identified that String.prototype.includes can be hijacked. However, the replacement guard using RegExp.prototype.test() suffers from the same class of weakness — RegExp.prototype.test is a writable method on the prototype chain and can be overridden to always return false, completely disabling the guard.
The robust fix is to use direct string comparison operators (===) in native control flow (for/if) instead of prototype methods like RegExp.prototype.test(), since === is a language-level operator that cannot be overridden.
PoC
Steps to reproduce
- Install locutus using
npm install locutus - Run the following code snippet:
const parse_str = require('locutus/php/strings/parse_str');
// Hijack RegExp.prototype.test (simulates a prior prototype pollution gadget)
const original = RegExp.prototype.test;
RegExp.prototype.test = function () { return false; };
// Payload
const result = {};
parse_str('__proto__[polluted]=yes', result);
// Check
RegExp.prototype.test = original;
console.log(({}).polluted); // 'yes' — prototype is polluted
Expected behavior
Prototype pollution should be prevented and ({}).polluted should print undefined.
undefined
Actual behavior
Object.prototype is polluted. This is printed on the console:
yes
Impact
This is a prototype pollution vulnerability with the same impact as CVE-2026-25521. The attack requires a chaining scenario — an attacker needs a separate prototype pollution gadget (e.g., from another npm package in the same application) to override RegExp.prototype.test before exploiting parse_str. This is realistic in Node.js applications that use multiple npm packages, where one package's vulnerability can disable another package's defenses.
Any application that processes attacker-controlled input using locutus/php/strings/parse_str may be affected. It could potentially lead to:
- Authentication bypass
- Denial of service
- Remote code execution (if polluted property is passed to sinks like
evalorchild_process)
Resources
- Original advisory: https://github.com/locutusjs/locutus/security/advisories/GHSA-rxrv-835q-v5mh
- Fix commit (incomplete): https://github.com/locutusjs/locutus/commit/042af9ca7fde2ff599120783e720a17f335bb01c
- Vulnerable file: https://github.com/locutusjs/locutus/blob/main/src/php/strings/parse_str.js#L77
Maintainer response
Thank you for the follow-up report. This issue was reproduced locally against [email protected], confirming that the earlier parse_str guard was incomplete: if RegExp.prototype.test was already compromised, the guard could be bypassed and parse_str('__proto__[polluted]=yes', result) could still pollute Object.prototype.
This is now fixed on main and released in [email protected].
Fix Shipped In
- PR: locutusjs/locutus#597
- Merge commit on
main:345a6211e1e6f939f96a7090bfeff642c9fcf9e4 - Release: v3.0.25
What the Fix Does
The new fix no longer relies on a regex-prototype guard for safety. Instead, src/php/strings/parse_str.ts now rejects dangerous key paths during parsed-segment assignment, so the sink itself is hardened even if RegExp.prototype.test has been tampered with beforehand.
Tested Repro Before the Fix
- Override
RegExp.prototype.testto always returnfalse - Call
parse_str('__proto__[polluted]=yes', result) - Observe
({}).polluted === 'yes'
Tested State After the Fix in 3.0.25
- Dangerous key paths are skipped during assignment
- The same chained repro no longer pollutes
Object.prototype - The regression is covered by
test/custom/parse_str-prototype-pollution.vitest.ts
The locutus team is treating this as a real package vulnerability with patched version 3.0.25. The vulnerable range should end at < 3.0.25.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | locutus | ≥ 2.0.39&&< 3.0.25 | 3.0.25npm install locutus@3.0.25 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for locutus, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update locutus to 3.0.25 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-33994 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 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-33994 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-33994. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-33994 in your dependencies?
O3 Security finds CVE-2026-33994 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.