Insecure Deserialization
debt(d5/e3/b3/t9)
Closest to 'specialist tool catches it' (d5). The detection_hints list semgrep and psalm — both specialist/SAST tools. The code_pattern is a textual match (unserialize called on user-controlled sources), which these tools can flag, but it won't surface as a default linter warning and certainly won't be caught at compile time.
Closest to 'simple parameterised fix' (e3). The quick_fix is a clear replacement: swap unserialize() for json_decode(), or use allowed_classes:false plus HMAC signing. This is a per-call substitution that may touch a handful of sites in one component, but does not require cross-cutting architectural rework.
Closest to 'localised tax' (b3). The vulnerability applies wherever unserialize() is called on user-supplied data (web, cli, queue-worker per applies_to), but once the call sites are fixed the rest of the codebase is unaffected. It is not a load-bearing abstraction used everywhere; it is a specific dangerous call pattern.
Closest to 'catastrophic trap — the obvious way is always wrong' (t9). The misconception field states it precisely: developers believe validating data before calling unserialize() makes it safe, but PHP instantiates objects and fires __wakeup/__destruct during deserialization itself — the damage occurs before any validation code runs. This directly contradicts the intuitive validate-then-process pattern that competent developers apply everywhere else, making the obvious defensive approach always wrong.
Also Known As
TL;DR
Explanation
PHP's unserialize() reconstructs objects from a serialised string, invoking magic methods like __wakeup() and __destruct() in the process. Attackers can craft serialised payloads that exploit available classes (known as "gadget chains") to achieve arbitrary code execution, file deletion, or privilege escalation — without needing a file upload. The safe alternative is json_decode() for data exchange; if serialisation is required, restrict allowed_classes.
How It's Exploited
$ phpggc Laravel/RCE1 system 'id' -b
# Set as session cookie — on unserialize(), executes 'id' on the server
Common Misconception
Why It Matters
Common Mistakes
- Passing user-supplied cookies, tokens, or POST data directly to unserialize().
- Believing that a HMAC on the serialized string is sufficient — if the verification is bypassable, it isn't.
- Not using json_decode() or other format-specific parsers when PHP object serialization is not needed.
- Using unserialize() with allowed_classes but not restricting the class list tightly enough.
Code Examples
// Deserialising untrusted data — attacker crafts a payload
// that triggers arbitrary PHP object instantiation
$data = unserialize($_COOKIE['session']);
// Any class with __wakeup() or __destruct() in scope
// can be chained into a POP chain for RCE// Never unserialize untrusted input — use JSON instead
$data = json_decode(base64_decode($_COOKIE['session']), true);
// If you must use serialization, whitelist allowed classes:
$data = unserialize($input, ['allowed_classes' => [SafeValueObject::class]]);
// Best: sign the payload so tampering is detected
$payload = base64_encode(json_encode($data));
$sig = hash_hmac('sha256', $payload, $_ENV['SECRET']);
$cookie = $payload . '.' . $sig;
// Verify on read:
[$payload, $sig] = explode('.', $cookie, 2);
if (!hash_equals(hash_hmac('sha256', $payload, $_ENV['SECRET']), $sig)) abort(400);
$data = json_decode(base64_decode($payload), true);