PHP 8.4.8: Das solltest du über das Update wissen
Sie befinden sich: Home > Webmaster News
Mit PHP 8.4.8 ist erneut ein Update erschienen, das zunächst wie ein gewöhnliches Bugfix-Release wirkt – tatsächlich adressiert es aber gleich mehrere Fehler, die in sicherheitskritischen und produktionsnahen Szenarien relevant sind. Die Version wurde am 5. Juni 2025 veröffentlicht. Wer PHP 8.4.x produktiv einsetzt, sollte das Update als Pflicht betrachten. In diesem Artikel analysiere ich die wichtigsten Änderungen, ihre technischen Hintergründe und erkläre, warum ein Update unumgänglich ist.
Warum ist dieses Release der PHP 8.4.8 wichtig?
Im Zentrum steht die Korrektur von Fehlern, die:
-
Systeme angreifbar machen (z. B. DoS, Authentifizierungslecks, Zertifikatsvalidierung)
-
Produktivsysteme instabil machen (z. B. Stack-Overflows, Deadlocks, Speicherlecks)
-
Fehler in Daten und Berechnungen verursachen (z. B. Sunrise/Sunset)
Wer diese Bugs ignoriert, riskiert Stabilität und Sicherheit seiner Anwendungen.
Core: Tiefergehende Analyse der wichtigsten Fixes
In PHP 8.4.8 wurde ein subtiler, aber potenziell gefährlicher Bug in der Array-Verarbeitung korrigiert.
1. array_splice() und Integer-Überläufe (GH-18480)
Problem: Wird array_splice() mit extrem großen Werten für offset oder length gefüttert (häufig per Benutzereingabe möglich), kann es intern zu einem Integer-Überlauf kommen.
Folge: Der Vorgang führt zu fehlerhaften Array-Manipulationen oder gar zu Speicherzugriffsfehlern – schlimmstenfalls stürzt der Prozess ab.
Was wurde behoben?
Die Grenzwerte werden jetzt sauber geprüft, Überläufe zuverlässig abgefangen.
Praxisbeispiel:
$aArray = range(1, 5);
/* Früher konnte ein großer Offset zu undefiniertem Verhalten führen: */
array_splice($aArray, PHP_INT_MAX - 1, 2);
Kritikalität: Mittel. Besonders riskant bei direkter Übergabe von Benutzereingaben.
2. Stack Overflow bei Objektvergleichen (GH-18572)
Problem: PHP vergleicht rekursiv verschachtelte Objekte (z. B. bei Sortierung, Serialisierung). Wenn dabei zirkuläre Referenzen oder zu tiefe Verschachtelung vorliegen, kann dies zu endlosen Rekursionen führen.
Folge: Der Stack läuft voll → Absturz (klassischer Denial-of-Service-Vektor).
Was wurde behoben?
Der Vergleichsmechanismus erkennt und begrenzt jetzt Rekursionen besser.
Hinweis: Die Lösung ist „teilweise“, da nicht alle exotischen Zirkelfälle automatisch ausgeschlossen sind.
Beispiel für ein Risiko:
class Knoten {
/** @var Knoten|null */
public $kind;
}
$oKnotenA = new Knoten;
$oKnotenB = new Knoten;
$oKnotenA->kind = $oKnotenB;
$oKnotenB->kind = $oKnotenA;
var_dump($oKnotenA == $oKnotenB);
Kritikalität: Hoch. Besonders in großen Anwendungen und Frameworks relevant.
3. OSS-Fuzz Sicherheitslücken
Was ist OSS-Fuzz?
Eine von Google bereitgestellte Plattform, die durch automatisiertes „Fuzzing“ (Einspeisen von Zufallsdaten) Fehler aufdeckt, meist Speicherlecks, Pufferüberläufe oder andere Schwachstellen.
Was bedeutet die Behebung?
Die konkreten Bugs werden aus Sicherheitsgründen nicht detailliert veröffentlicht – aber jeder Fix aus OSS-Fuzz sollte als potentiell kritisch betrachtet werden.
cURL: Fehler beim Entfernen von Authentifizierungsdaten (GH-18460)
Problem:
Setzt man in cURL (z. B. bei API-Requests) einen Auth-Header auf NULL, wurde trotzdem weiterhin ein Authorization-Header gesendet – entweder mit alten Werten oder leer.
Folge:
Sensibler Auth-Header kann an falsche Endpunkte gelangen, besonders bei mehrfacher Wiederverwendung eines cURL-Handles (z. B. im Batch).
Korrektur:
Ein explizites Setzen auf NULL entfernt jetzt die Header wirklich und zuverlässig.
Beispiel:
$sUrl = "https://api.example.com/";
$oCurl = curl_init($sUrl);
/* Erst authentifizierte Anfrage */
curl_setopt($oCurl, CURLOPT_USERPWD, "user:pass");
curl_exec($oCurl);
/* Dann für einen anderen Endpunkt die Authentifizierung entfernen */
curl_setopt($oCurl, CURLOPT_USERPWD, null);
/* Jetzt sicher! */
curl_exec($oCurl);
Kritikalität: Mittel–hoch (Datenlecks möglich).
Date: Korrekturen bei Sonnenzeiten und Robustheit
Ein lange übersehener Fehler bei der Berechnung von Sonnenaufgang und -untergang wurde nun endlich behoben.
date_sun_info() liefert wieder korrekte Zeiten (GH-18076)
Problem: Seit PHP 8 stimmten die berechneten Werte für Sonnenaufgang und -untergang nicht mehr – ein Fehler im Algorithmus.
Konsequenz:
Wer auf genaue astronomische Daten angewiesen ist (Landwirtschaft, Wissenschaft, Automatisierung), erhielt falsche Informationen.
date_sunrise() mit NaN-Offset (GH-18481)
Problem: Gab man einen Wert wie NaN (not a number) als Offset, reagierte PHP unvorhersehbar statt mit einer klaren Fehlermeldung.
Beides ist jetzt behoben.
Kritikalität: Niedrig–mittel.
LDAP: TLS_CACERT wird wieder beachtet (GH-18529)
Problem:
Verbindet sich eine Anwendung über LDAP mit StartTLS und gibt in der Datei ldaprc ein eigenes CA-Zertifikat an, wurde dieses ignoriert – stattdessen wurde ggf. das unsichere System-Default-Zertifikat verwendet.
Folge:
Gefahr für Man-in-the-Middle-Angriffe, Identitätsprüfung des Servers ausgehebelt.
Korrektur:
Die Direktive wird wieder ausgewertet und schützt vor Angriffen.
Kritikalität: Kritisch – vor allem für Unternehmen und Infrastrukturbetreiber.
Opcache: Stabilität und Speicherverwaltung
Opcache ist zentral für die Performance moderner PHP-Anwendungen. Die folgenden Probleme wurden beseitigt:
-
SHM-Neuzuordnung unter Windows: Erhöhung von Speicher-Parametern führte zu Startfehlern (GH-18417).
-
Mehrere Absturzursachen im JIT: Unbehandelte Exceptions, State-Management-Fehler, Preloading- und Trait-Probleme (GH-18297, GH-18408, GH-18567, GH-18534).
-
Speicherleck: accel_globals->key wurde nicht sauber freigegeben.
Kritikalität: Hoch. Instabiler Opcache bedeutet: Abstürze, Latenzen, Deadlocks – Produktionsbetrieb ernsthaft gestört.
Standard-Bibliothek: Deadlocks & Assertion-Konfiguration
Die Behandlung von Umgebungsvariablen konnte bisher unter bestimmten Bedingungen zu einem vollständigen Deadlock führen.
putenv()-Deadlock (GH-17403)
In Multi-Threaded-Umgebungen konnte ein Fehler bei der Nutzung von putenv() zu einem Deadlock führen. Jetzt gelöst.
assert() ignorierte Konfiguration (GH-18509)
Dynamisch aufgerufene Assertions (z. B. per call_user_func("assert", ...)) beachteten die globale Einstellung zend.assertions nicht. Damit liefen Debug-Ausgaben auch in der Produktion.
Kritikalität: Hoch bei putenv(), Mittel bei assert().
Übersicht: Kritikalität der wichtigsten Fixes
Diese Tabelle zeigt, welche Komponenten besonders betroffen sind und wie gravierend die jeweiligen Fehler einzustufen sind.
| Bereich |
Ticket |
Kritikalität |
| Core |
GH-18572 |
Hoch (DoS möglich) |
| LDAP |
GH-18529 |
Kritisch (MitM) |
| Opcache |
div. |
Hoch |
| putenv |
GH-17403 |
Hoch (Deadlock) |
| cURL |
GH-18460 |
Mittel–hoch (Leak) |
| OSS-Fuzz |
#4170… |
Hoch–kritisch |
| Date |
GH-18076 |
Niedrig–mittel |
Handlungsempfehlung und Praxis-Tipps
-
Update einspielen – keine Ausreden:
Produktions-, Test- und Staging-Systeme auf 8.4.8 bringen. Pakete gibt es für alle Plattformen, auch Docker & Windows.
-
Vorher: Smoke-Tests!
-
Laufen (Re-)Deploys, Cronjobs und Preloading-Skripte sauber durch?
-
Funktioniert die Anbindung an LDAP-Server, v. a. mit eigenen Zertifikaten?
-
Nachher: Monitoring scharfstellen
-
Überwache Deadlocks, Stack-Overflows und Fehler im Opcache.
-
Prüfe Logfiles auf Residualprobleme, v. a. bei stark benutzerdefinierten Array-Operationen.
-
Regressionstests empfehlen sich dort, wo du viele dynamische Objektvergleiche, Deserialisierungen oder selbstgeschriebene Preloader einsetzt.
Fazit: PHP 8.4.8 ist ein Pflicht-Update
Viele der behobenen Fehler mögen auf den ersten Blick wie Spezialfälle wirken, entfalten aber große Wirkung, sobald sie in der Produktion auftreten – meist in genau dem Moment, in dem du es am wenigsten gebrauchen kannst.
LDAP-Lücke, Stack Overflow bei Vergleichen, Deadlocks und cURL-Leaks: Das sind keine „Nice-to-have“-Fixes, sondern echte Problemzonen für Security und Verfügbarkeit. Ein sofortiges Update schützt dich vor Ausfällen, Support-Nachtschichten und bösen Überraschungen.
Meine Empfehlung:
Nicht warten. Update einspielen. Kurz testen. Beobachten. Erst dann ist deine PHP-Installation wieder „state of the art“.
(Autor: 
schubertmedia), Eingetragen am 06.06.2025
