PHP 8.5.12 und 8.4.27 schließen zwei kritische RCE-Lücken

PHP hat am 21. Oktober 2026 die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, um zwei kritische Lücken zu schließen. Beide können es einem Angreifer erlauben, ohne Anmeldung Code auf einem Webserver auszuführen. Die Sicherheitsmeldung von PHP.net fordert alle PHP-Nutzer auf, sofort zu aktualisieren. Sie fügt hinzu, dass keine Konfigurationsänderung einen Server vollständig schützt. Die Installation des neuen Releases ist daher die einzige sichere Wahl.

PHP hatte dieses außerplanmäßige Release einen Tag zuvor angekündigt, nachdem Details zu den Fehlern vorzeitig durchgesickert waren. Über diese Vorankündigung haben wir heute Morgen berichtet. Das heutige Release beantwortet die offenen Fragen: welche Versionen korrigiert sind, was die Fehler bewirken und wer am stärksten gefährdet ist.

Was die beiden PHP-Lücken bewirken

Beide Fehler stecken im Code, der jede Webanfrage vorbereitet und danach aufräumt. PHP bewertet jeden von ihnen mit 9.2 nach CVSS v4.0, der Standardskala für den Schweregrad von 0 bis 10. Laut PHP „können beide eine nicht authentifizierte Remote-Code-Ausführung ermöglichen“. Nicht authentifiziert heißt, dass der Angreifer weder ein Konto noch ein Passwort braucht.

CVE	GitHub-Advisory	Was schiefgeht
CVE-2026-109618	GHSA-w8hw-w9fx-j79w	Wenn der Speicher ausgeht, kann PHP mitten in der Vorbereitung einer Anfrage abbrechen. Der Aufräumcode behandelt die halb aufgebauten Daten dann womöglich als gültig.
CVE-2026-109619	GHSA-6wmf-4rv5-p3rp	Manche Anfragedaten können länger bestehen als der Speicher dahinter. Die nächste Anfrage im selben Worker-Prozess verwendet diese veralteten Daten dann womöglich zuerst.

Ein Worker-Prozess ist eine der dauerhaft laufenden Kopien von PHP, die ein Webserver aktiv hält, um Anfragen zu beantworten. Worker wiederzuverwenden ist normal und schnell. Deshalb spielen Datenreste einer Anfrage für die nächste eine Rolle.

Wer gefährdet ist

Laut der Meldung von PHP kann jede Installation betroffen sein, die Webanfragen bedient. Dazu gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. PHP stuft mod_php, das Modul, das PHP direkt in Apache ausführt, als größtes Risiko ein. Die Meldung beschreibt einen „demonstrierten Exploit“, bei dem eine einzige nicht authentifizierte Anfrage den Angriff auslöst, bevor irgendein Anwendungscode läuft.

Dieses Detail ist wichtig für alle, die sich auf Schutzmaßnahmen auf Anwendungsebene verlassen. Eine Firewall-Regel in WordPress oder einem Framework kommt gar nicht erst zum Zug.

Die Meldung von PHP berichtet nicht von Angriffen in freier Wildbahn. Andere Berichte sind weniger eindeutig. Laut TechStartups hat der CTO von Cloudflare erste Anzeichen von Angriffen gesehen, auch wenn das Ausmaß unklar ist. TechStartups zitiert außerdem Benjamin Harris, CEO von watchTowr, der BleepingComputer sagte, beide Fehler seien „CVSS10“. Das liegt über PHPs eigener Bewertung von 9.2. Gulf News berichtet unter Berufung auf Reuters, dass Regierungswebsites in Europa und anderswo am Mittwoch nach der Offenlegung offline gingen. Ob Angriffe diese Ausfälle verursacht haben, sagt der Bericht nicht.

Amazon meldete später, dass seine MadPot-Honeypots schon am 17. Oktober einen Angriffsversuch protokolliert hatten, vier Tage vor diesem Release, wie Amazon sah PHP2Shell-Angriffsversuche vier Tage vor der Offenlegung beschreibt.

Welche PHP-Versionen Sie installieren sollten

Branch	Korrigiertes Release	Hinweise
PHP 8.5	8.5.12	Korrigiert
PHP 8.4	8.4.27	Korrigiert
PHP 8.3	8.3.36	Korrigiert
PHP 8.2	8.2.35	Korrigiert; der Branch erreicht am 31. Dezember 2026 sein End of Life
PHP 8.1, 8.0, 7.4	Keins	Nur minimale Quellcode-Patches, in Branches namens PHP-8.1-CVE-2026-109618-109619 und ähnlich
Älter als 7.4	Keins	Keine Korrektur von PHP

Die Quellcode-Patches für 7.4, 8.0 und 8.1 sind keine paketierten Releases. Jemand muss sie bauen. Gulf News merkt an, dass einige Anbieter die Korrekturen auf ältere Versionen zurückportieren könnten, die sie noch unterstützen.

PHP nennt außerdem teilweise Abhilfen, darunter das Abschalten von session.upload_progress.enabled und strengere Grenzen für die Anfragegröße. Die Meldung sagt unverblümt, dass diese „eine Installation nicht sicher machen“. Sie schränken den Angriff nur ein, während ein echtes Update ausgerollt wird.

Was das für Entwickler bedeutet

Patchen Sie heute, und patchen Sie auch die Stellen, die Sie vergessen. Der offensichtliche Server ist selten die einzige PHP-Kopie, die eine Organisation betreibt.

• Prüfen Sie jede Laufzeitumgebung, nicht nur die Hauptseite. Führen Sie php -v auf jedem Host aus. Prüfen Sie danach Container-Basis-Images, CI-Runner, Staging-Server und interne Tools. Ein Docker-Image, das auf einen alten Tag festgelegt ist, behält den Fehler, bis es jemand neu baut.
• Starten Sie nach dem Update neu. PHP-FPM und Apache halten Worker-Prozesse am Leben. Ein neues Paket auf der Festplatte bewirkt nichts, bis diese Worker neu starten. Prüfen Sie danach also die laufende Version.
• Nehmen Sie sich mod_php-Hosts zuerst vor. PHP nennt dies die riskanteste Konfiguration, mit einem Exploit, der greift, bevor Ihr Code läuft. Wenn Sie einen mod_php-Server heute nicht aktualisieren können, erwägen Sie, ihn vom Netz zu nehmen, bis Sie es können.
• Behandeln Sie PHP 8.1 und älter als Notfall-Upgrade. Es kommt kein offizielles Release. Die Quellcode-Patches verschaffen Zeit, aber nur, wenn jemand sie baut und pflegt. Fragen Sie Ihren Hosting-Anbieter oder Ihre Linux-Distribution, ob dort ein Backport angeboten wird.
• Planen Sie das End of Life von PHP 8.2 ein. Am 31. Dezember 2026 enden die Sicherheitskorrekturen für den Branch 8.2. Wer jetzt auf 8.4 oder 8.5 umsteigt, vermeidet eine zweite Hektik zum Jahresende.
• Behalten Sie die Logs im Blick. Berichte über erste Angriffe sind unbestätigt, aber die Details sind inzwischen öffentlich. Ungewöhnliche Abstürze oder Out-of-Memory-Fehler in PHP-Workern verdienen einen genaueren Blick.