|  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
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
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-2020 The PHP Group
All rights reserved.
Last updated: Sat Aug 08 09:01:23 2020 UTC