Prototype Pollution in locutus (>= 2.0.39) due to incomplete fix for CVE-2026-25521

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

1. Install locutus using npm install locutus
2. 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:

1. Authentication bypass
2. Denial of service
3. Remote code execution (if polluted property is passed to sinks like eval or child_process)

Weaknesses

References

• Original advisory: GHSA-rxrv-835q-v5mh
• Fix commit (incomplete): 042af9c
• Vulnerable file: https://github.com/locutusjs/locutus/blob/main/src/php/strings/parse_str.js#L77

Maintainer response

Thanks for the follow-up report. I reproduced this locally against locutus@3.0.24 and agree 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 locutus@3.0.25.

Fix shipped in:

• PR: #597
• merge commit on main: 345a6211e1e6f939f96a7090bfeff642c9fcf9e4
• release: https://github.com/locutusjs/locutus/releases/tag/v3.0.25

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.

Maintainer-tested repro before the fix:

• override RegExp.prototype.test to always return false
• call parse_str('__proto__[polluted]=yes', result)
• observe ({}).polluted === 'yes'

Maintainer-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

I am treating this as a real package vulnerability with patched version 3.0.25. The vulnerable range should end at < 3.0.25.