PHP 5.5.30 — Full Changelog (Detailed) + Examples

At a Glance

• Scope of changes (official changelog): Phar extension only [oai_citation:1‡php.net](https://www.php.net/ChangeLog-5.php)
• Security fixes:
  • Bug #69720 → CVE-2015-7803 (NULL pointer dereference → crash / DoS)
  • Bug #70433 → CVE-2015-7804 (uninitialized pointer → crash / undefined behavior)

  [oai_citation:2‡php.net](https://www.php.net/ChangeLog-5.php)

Official Changelog (PHP 5.5.30)

• Phar:
  • Fixed bug #69720
    (Null pointer dereference in phar_get_fp_offset()). (CVE-2015-7803)
    [oai_citation:3‡php.net](https://www.php.net/ChangeLog-5.php)
  • Fixed bug #70433
    (Uninitialized pointer in phar_make_dirstream when zip entry filename is “/“). (CVE-2015-7804)
    [oai_citation:4‡php.net](https://www.php.net/ChangeLog-5.php)

What These Fixes Mean (Practical Detail)

1) Bug #69720 / CVE-2015-7803 — NULL pointer dereference in phar_get_fp_offset()

A NULL pointer dereference is a classic crash condition: code tries to use a pointer that is NULL (points to “nothing”),
causing a segmentation fault. In this case, the issue was in Phar’s internal file pointer offset handling
(phar_get_fp_offset()), and could be triggered under specific error paths (e.g., referencing a non-existent file).
The typical impact is Denial of Service (DoS) via process crash. [oai_citation:5‡php.net](https://www.php.net/ChangeLog-5.php)

Example (Crash-style Regression Test Idea)

The goal here is not to “exploit” anything, but to illustrate how you’d validate you’re not on a vulnerable build.
The vulnerable behavior is a crash; the fixed behavior is a clean error/exception instead of a segfault.

<?php
// Example: run from CLI to reduce noise.
// Expectation:
// - Vulnerable builds: may crash (segfault) under certain conditions.
// - Patched builds: should NOT crash; should emit a warning/exception/false.

error_reporting(E_ALL);
ini_set('display_errors', 1);

// Phar stream wrapper is commonly involved in Phar parsing paths.
// This path is intentionally "bad" / non-existent to exercise error handling.
$path = 'phar:///path/that/does/not/exist/archive.phar/test.txt';

echo "Reading: {$path}\n";
$data = @file_get_contents($path);

var_dump($data);
echo "Done (process should still be alive).\n";
?>

Notes:

• This is a test pattern, not a guarantee of reproducing a crash on every vulnerable environment.
• In CI, you’d typically treat “process crash” as a hard fail and require the patched runtime.

2) Bug #70433 / CVE-2015-7804 — Uninitialized pointer in phar_make_dirstream for zip entry “/“

“Uninitialized pointer” means a pointer variable is used before it is set to a valid value. That can lead to crashes
or undefined behavior depending on what garbage value it contains. The reported edge case is a ZIP-based Phar (or ZIP handling path)
where an entry’s filename is exactly “/“. PHP 5.5.30 fixes this to prevent unsafe pointer use in that path. [oai_citation:6‡php.net](https://www.php.net/ChangeLog-5.php)

Example (ZIP Entry Edge Case Test Idea)

This test demonstrates the “weird ZIP entry name” scenario at a high level. Creating an entry named “/” is not a normal
archive structure, but malformed archives are exactly what security hardening needs to handle safely.

<?php
// Requires ZipArchive enabled.
// This is a conceptual regression test: you create an unusual zip and then iterate it.
// On patched builds, this should behave safely (no crash).

error_reporting(E_ALL);
ini_set('display_errors', 1);

$zipFile = __DIR__ . '/edgecase.zip';
@unlink($zipFile);

$zip = new ZipArchive();
if ($zip->open($zipFile, ZipArchive::CREATE) !== true) {
  die("Cannot create zip\n");
}

// Attempt to add a weird entry name "/"
$zip->addFromString('/', 'edge case content');
$zip->close();

// Now open and list entries
$zip = new ZipArchive();
$zip->open($zipFile);

echo "Entries:\n";
for ($i = 0; $i < $zip->numFiles; $i++) {
  $stat = $zip->statIndex($i);
  echo "- " . $stat['name'] . "\n";
}

$zip->close();
echo "Done (should not crash).\n";
?>

Why this matters:

• Attackers often use malformed inputs (archives, images, payloads) to force code into unsafe branches.
• Even if the “only” outcome is a crash, that’s still a production stability/security problem (DoS).

Upgrade Guidance (Reality Check)

PHP 5.5 is long end-of-life. If you are maintaining legacy systems that still run 5.5.x, PHP 5.5.30 is the minimum
to include these specific Phar security fixes, but you should plan a migration to a supported PHP version.
The PHP team’s release announcement explicitly marks 5.5.30 as a security release and encourages upgrading. [oai_citation:7‡php.net](https://www.php.net/releases/5_5_30.php?utm_source=chatgpt.com)