PHP-Sicherheitsrelease vom 21. Oktober 2026: zwei kritische Lücken, Update jetzt

Das PHP-Projekt hat am 21. Oktober 2026 um 14:00 UTC ein Sicherheitsrelease veröffentlicht, das zwei kritische Schwachstellen behebt: CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2. Beide erlauben Codeausführung ohne Anmeldung. Behoben sind sie in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Betroffen ist jede Installation, die Webanfragen bedient, als höchstes Risiko nennt das Projekt mod_php. Zu tun ist eines: auf eine dieser Versionen aktualisieren.

Sachstand

Die beiden Schwachstellen liegen in der Speicherverwaltung von PHP selbst, nicht in einer Anwendung:

• CVE-2026-109618, Codeausführung über Speicherüberlauf: die Behandlung eines Out-of-Memory-Zustands kann PHP unterbrechen, während interne Request-Daten nur teilweise initialisiert sind. Das Aufräumen des Requests behandelt die ungültigen Daten dann als gültig.
• CVE-2026-109619, Codeausführung über liegengebliebenen Zustand: interner Zustand eines Requests kann den zugehörigen Speicher überleben, nachdem dieser freigegeben wurde. Ein späterer Request desselben Workers benutzt diesen Zustand, bevor die normale Initialisierung ihn zurücksetzt.
• Betroffen sind alle Betriebsarten, die Webanfragen bedienen: php-fpm, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko trägt laut Projekt mod_php, mit vorgeführten Angriffen, bei denen unauthentifizierte Anfragen zuschlagen, bevor Anwendungscode überhaupt läuft.
• Für PHP 8.1 und älter gibt es kein Update vom Projekt. Einzelne Distributionen liefern zurückportierte Korrekturen, und für 7.4, 8.0 und 8.1 gibt es minimale Quell-Backports.

CVSS 9.2 bedeutet in der Praxis, dass ein Angreifer ohne Zugangsdaten eigenen Code auf dem Server ausführen kann. Da PHP den Webserver bedient, betrifft das nicht eine einzelne Anwendung, sondern die Plattform, auf der sie läuft.

Handlungsempfehlung

1. Bestandsaufnahme. Welche Server liefern PHP aus, in welcher Version, über welche Schnittstelle, also mod_php, php-fpm oder LiteSpeed? Die Angabe php -v auf der Kommandozeile genügt dafür nicht: der Webserver liest in der Regel eine andere Konfiguration. Verbindlich ist eine phpinfo()-Ausgabe oder php-fpm -i.
2. Update einspielen, sobald verfügbar. Debian und Ubuntu: apt update && apt install --only-upgrade 'php8.*', danach systemctl reload apache2 bei mod_php beziehungsweise systemctl restart 'php8.*-fpm' bei FPM. RHEL-Derivate: dnf update 'php*'. Wer PHP in Containern betreibt, braucht einen Neubau des Images, ein apt upgrade im Container erreicht das PHP der offiziellen php:-Images nicht, weil es dort aus den Quellen übersetzt ist.
3. Version nach dem Update verifizieren, wieder über phpinfo() oder php-fpm -i.

Was vor dem Release kursierte

Vor dem Release kursierten die beiden Kennungen bereits, zusammen mit einem angeblichen Angriffsweg über Formulardaten mit Datei-Anhängen und einer darauf aufbauenden Abwehrregel für Apache. Die Kennungen haben sich als richtig erwiesen. Der Angriffsweg nicht: die veröffentlichten Beschreibungen nennen die Behandlung eines Speicherüberlaufs und liegengebliebenen Request-Zustand, nicht das Verarbeiten von Formulardaten.

Die Lehre daraus ist allgemein: Kennungen und Mechanismus aus einer Drittquelle sind zwei getrennte Behauptungen, und sie können unterschiedlich ausgehen. Maßnahmen, die auf dem Mechanismus aufbauen, blieben bis zur Veröffentlichung des Herstellers eine begründete Annahme, keine belegte Entscheidung.

Fazit

Bekannt war die Sache seit dem 20. Oktober, der Patch lag seit dem 21. Oktober um 14:00 UTC vor. Wir haben noch am selben Tag aktualisiert, den Patch innerhalb kürzester Zeit eingespielt und anschließend die Logs auf mögliche Angriffe geprüft: keine Hinweise auf einen Angriff oder eine erfolgreiche Ausnutzung.

Quelle

Primärquelle ist allein die Vorankündigung des PHP-Sicherheitsteams: php.net/archive, 21.10.2026. Die Kennungen tragen dort zusätzlich die GitHub-Advisory-Nummern GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp.