|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #73836 unserialize() with $options['allowed_classes'] = null behaves different
Submitted: 2016-12-29 19:04 UTC Modified: 2016-12-30 13:37 UTC
From: denis dot brumann at sensiolabs dot de Assigned: cmb (profile)
Status: Closed Package: Variables related
PHP Version: 7.1.0 OS: macOS Sierra
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: denis dot brumann at sensiolabs dot de
New email:
PHP Version: OS:


 [2016-12-29 19:04 UTC] denis dot brumann at sensiolabs dot de
I just built a polyfill around the $options parameter added to unserialize() in PHP 7.0. I noticed a different behaviour when allowed_classes is set to null (instead of false) when using PHP 7.0 and 7.1.

See Travis builds:
7.0 (fails)
7.1 (passes)

This is the test that's being executed:

It seems that PHP 7.1 shows a warning, whereas 7.0 does not. I would expect PHP 7.0 to show the same warning.

Test script:
$serialized = serialize(new \stdClass());
unserialize($serialized, ['allowed_classes' => null]);

Expected result:
I would expect both versions to behave the same, either both throw a warning (seems more plausible or neither does).


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-30 01:00 UTC]
-Status: Open +Status: Analyzed -Type: Bug +Type: Documentation Problem -Package: Unknown/Other Function +Package: Variables related
 [2016-12-30 01:00 UTC]
The warning (and bailing out with FALSE) has been introduced with
the fix of bug #72785, because the supplied test script showed an
unfortunate mistake, which would have caused all classes to be
allowed to be unserialized.

The fix had been only applied to PHP 7.1 for BC reasons, and it
makes sense to treat the warning also this way for the same

What is missing, however, are entries in UPGRADING and the
migration guide, plus patching the unserialize() man page. Thus,
I'm changing to doc-bug.

As the other bug has not been classified as security issue, I take
it for granted that unserialize() shouldn't be used on untrusted
user input even if allowed_classes is appropriately set, what
might be mentioned more explicitly in the docs.
 [2016-12-30 13:37 UTC]
Automatic comment from SVN on behalf of cmb
Log: Fix #73836: unserialize() with $options['allowed_classes'] = null behaves different
 [2016-12-30 13:37 UTC]
-Status: Analyzed +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-02-07 06:06 UTC]
Automatic comment on behalf of cmb
Log: Fix #73836: unserialize() with $options['allowed_classes'] = null behaves different
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Wed Sep 22 03:03:36 2021 UTC