|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45573 unserialize does not work if a linebreak is inside the input string
Submitted: 2008-07-20 20:23 UTC Modified: 2016-07-26 23:03 UTC
From: t_mueller_stolzenhain at yahoo dot de Assigned:
Status: Not a bug Package: Strings related
PHP Version: any OS: any
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
2 + 12 = ?
Subscribe to this entry?

 [2008-07-20 20:23 UTC] t_mueller_stolzenhain at yahoo dot de
After updating PHP to version 5.2.6 on a windows 2003 server running under IIS, it was not possible to update PEAR anymore. Each package created some error messages like

Notice: unserialize(): Error at offset 1139 of 4783 bytes in PEAR\Registry.php on line 1062

After putting the line

$data = str_replace("\15\12", "\12", $data);

before the unserialize-including line, the error message disappeared an I was able to update PEAR again.

I asume, this is an IIS related issue, because on an other Computer with PHP 5.2.5 (running on Win XP and Apache) are no error messages.

Reproduce code:
These are the lines 1058-1064 from /PEAR/PEAR/Registry.php including one line with an fix

        $data = file_get_contents($this->_packageFileName($package, $channel));
        $data = str_replace("\15\12", "\12", $data);//additional line with fix
        $data = unserialize($data);
        if ($key === null) {
            return $data;

Expected result:
no error message

Actual result:

Notice: unserialize(): Error at offset 1139 of 4783 bytes in PEAR\Registry.php on line 1062


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2008-07-23 21:40 UTC] t_mueller_stolzenhain at yahoo dot de
I tried the package from, but the error is still there.

I changed the category for this bug, because the PEAR update was not running inside the browser, it was running inside a dos window.
 [2008-07-24 00:31 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

 [2008-07-24 21:10 UTC] t_mueller_stolzenhain at yahoo dot de
I don't have a sample script (I'm not able to create an text with two different line endings in it), but I found the reason for that issue:

As you know, PEAR is storing some information inside the .registry directory in *.reg files. Some of these files I found converted to the windows style, means they had a windows line ending ("\15\12") instead of the linux line ending ("\12").

After reformating these files with the linux line ending, the error messages disappeared, and the PEAR update was running without any error messages.

I asume, the most of the files on a windows computer have the windows line ending included, not the linux line ending.

PHP is able to detect that it is running on a windows computer, and unserialize should be able to handle the windows line ending without error message.
 [2008-07-24 23:04 UTC]
As long as there is no preproducing script, there is no problem either.
 [2008-07-25 19:18 UTC] t_mueller_stolzenhain at yahoo dot de
sample to reproduce the error I had:
//the original array
$a = array(
    'a23' => 'abcdefg
//make it serial
$s = serialize($a);
//just to see the serial string
//the serialized array
$s1 = 'a:1:{s:3:"a23";s:11:"abcdefg
//the same with linux line end character
$s2 = "a:1:{s:3:\"a23\";s:11:\"abcdefg\12hij\";}";
//the same with windows line end character, same I had in my PEAR files
$s3 = "a:1:{s:3:\"a23\";s:11:\"abcdefg\15\12hij\";}";
//turn it back to an array
$a1 = unserialize($s1); // ok
$a2 = unserialize($s2); // ok
$a3 = unserialize($s3); // not ok
 [2015-06-30 14:49 UTC] josh at josheaton dot org
I'm wondering why this issue never got any attention even with a reduced test case that reproduced the issue? I recently ran into this issue with a WordPress site and found this bug.

WordPress ticket:

netweb was kind enough to provide a link that tests the issue in many different PHP versions, and it appears to break in all of them. Any windows line endings within a serialized string break when unserialized.

Is it possible to reopen this issue?
 [2015-07-01 05:39 UTC]
-Status: Not a bug +Status: Re-Opened -Package: CGI/CLI related +Package: Strings related -Operating System: windows2003 +Operating System: any -PHP Version: 5.2CVS-2008-07-23 +PHP Version: any
 [2015-07-01 05:39 UTC]
Because this is marked as Not a Bug. I re-opened this.
 [2015-07-01 11:55 UTC]
-Assigned To: fb-req-jani +Assigned To:
 [2015-07-01 11:55 UTC]
This is not a general bug. unserialize() fails due to the wrong
string length; s:11 has to be changed to s:12 when the LF is
replaced by CRLF, see <>.

The PEAR issue still may be an issue or not.
 [2016-07-26 23:03 UTC]
-Status: Re-Opened +Status: Not a bug
 [2016-07-26 23:03 UTC]
Closing here, as this is working as intended. The serialized string has been corrupted and consequently unserialize fails.

Serialized data is binary data, it can't be treated as "text".
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Sun Oct 01 11:01:24 2023 UTC