phanalist

E0053: Unserialize Without allowed_classes

In plain English: unserialize() can create objects of classes named inside the input. If an attacker controls that input, they may choose a class with dangerous __wakeup() or __destruct() methods. This is called object injection.

Why it matters: Object injection can lead to file writes, command execution, or other side effects depending on which classes the application loads.

Bad

$cart = unserialize($_COOKIE['cart']);
$cart = unserialize($payload, []);
$cart = unserialize($payload, ['allowed_classes' => true]);

Good

$cart = unserialize($payload, ['allowed_classes' => false]);

$dto = unserialize($payload, [
    'allowed_classes' => [Cart::class, CartItem::class],
]);

allowed_classes => false prevents object creation and allows only arrays and scalars. A list allows only the classes you name.

What the rule checks

• unserialize($payload) with no options argument
• A literal options array without an allowed_classes key
• allowed_classes => true, which explicitly allows every class
• Named arguments such as unserialize(data: $payload, options: [...])

When it does not report

• allowed_classes is false or a list of class names.
• The options argument is not a literal array, because the rule cannot prove the key is absent.
• The input is a literal serialized string.
• The input is unserialize(serialize($value)), a local round-trip.

How to fix

• Prefer JSON or another data-only format.
• If you must use unserialize(), set allowed_classes to false or to a short list of expected classes.
• Never pass request data directly to unserialize().

Model limits

• Only literal options arrays are inspected.
• The rule does not check whether the trusted class list is safe.

Configuration

E0053 has no configuration options and is enabled by default.

This site is open source. Improve this page.