Zwei kritische PHP-Lücken: Was ein Betrieb mit eigener Website jetzt tun sollte

Am 21. Oktober 2026 hat das PHP-Projekt neue Fassungen veröffentlicht, die zwei kritische Sicherheitslücken schließen. Beide lassen sich ohne Anmeldung ausnutzen: Wer eine PHP-Anwendung über das Netz erreicht, kann im schlimmsten Fall eigenen Code auf dem Server ausführen. Das PHP-Projekt schreibt dazu nur einen Satz an alle: sofort aktualisieren.

Das betrifft mehr Betriebe, als es klingt. WordPress läuft auf PHP, die meisten Shop-Systeme auch, dazu viele Kundenportale, Buchungsseiten und Intranets. Wer eine Website hat, die nicht nur aus festen Seiten besteht, sollte heute nachsehen.

Was bekannt ist

Die Lücken haben die Kennungen CVE-2026-109618 und CVE-2026-109619. Die erste betrifft den Fall, dass PHP der Speicher ausgeht, die zweite einen Zustand, der zwischen zwei Anfragen übrig bleibt. Beide hat das PHP-Projekt als kritisch eingestuft. Gefährdet sind laut php.net alle PHP-Installationen, die Webanfragen beantworten, also die üblichen Varianten auf einem Webserver. Am höchsten ist das Risiko bei einer bestimmten Einbindung in den Apache-Webserver, für die bereits ein Angriff vorgeführt wurde, der greift, bevor überhaupt Code der Anwendung läuft.

Gefunden wurden die Lücken unter anderem mit Hilfe von KI-Werkzeugen, bei einem Prüfprogramm, an dem auch OpenAI beteiligt war. Zum Zeitpunkt der Veröffentlichung hatte das PHP-Projekt nach eigener Aussage keinen funktionierenden Angriff in freier Wildbahn gesehen. Sicherheitsfirmen erwarten aber, dass bald einer öffentlich wird. In manchen Meldungen ist zu lesen, die Lücken würden schon ausgenutzt; das konnten wir an keiner Primärquelle bestätigen.

Welche Fassung ihr braucht

Behoben sind die Lücken in diesen Fassungen:

PHP 8.5   ab 8.5.12
PHP 8.4   ab 8.4.27
PHP 8.3   ab 8.3.36
PHP 8.2   ab 8.2.35

Für 8.1, 8.0, 7.4 und ältere Reihen hat das PHP-Projekt keine neue Fassung veröffentlicht. Diese Reihen werden dort nicht mehr gepflegt. Einzelne Linux-Distributionen und Hoster liefern für ihre eigenen Pakete teils trotzdem Korrekturen nach; darauf verlassen kann man sich nicht.

Für Debian haben wir nachgesehen: Laut der Sicherheitsübersicht von Debian gibt es korrigierte Pakete für Debian 12 (PHP 8.2.35) und Debian 13 (PHP 8.4.27), Stand 22. Oktober 2026.

Was ein Betrieb jetzt tun sollte

Je nachdem, wo die Website liegt:

1. Bei einem Hoster mit verwaltetem Hosting, also dem üblichen Paket mit Kundenbereich: Im Kundenbereich nachsehen, welche PHP-Reihe eingestellt ist. Steht dort 8.2 oder neuer, spielt der Hoster die Korrektur in aller Regel selbst ein; fragt im Zweifel nach, ob das schon passiert ist. Steht dort 8.1 oder älter, ist ein Wechsel auf eine neuere Reihe nötig. Vorher eine Sicherung machen und die Seite danach einmal durchklicken, weil alte Erweiterungen auf neuen Reihen manchmal nicht laufen.
2. Bei einer Agentur oder einem IT-Dienstleister: eine kurze Mail mit drei Fragen. Läuft unsere Website auf PHP? Welche Fassung? Ist die Korrektur vom 21. Oktober eingespielt?
3. Auf einem eigenen Server: die Pakete der Distribution aktualisieren und den Webserver beziehungsweise PHP-FPM neu starten. Danach mit php -v prüfen, welche Fassung wirklich läuft.

php -v

Wer heute nicht aktualisieren kann, findet bei Sicherheitsfirmen vorübergehende Einstellungen, die einen Teil der Angriffe erschweren. Das ist Arbeit für den Administrator und ersetzt das Update nicht.

Was das mit unserem Lagebericht zu tun hat

Anfang Oktober haben wir über Microsofts Lagebericht geschrieben: Von der Entdeckung einer Lücke bis zum Angriff vergehen im Median deutlich weniger als 24 Stunden. Die PHP-Lücken zeigen, warum das so ist. Die Kennungen kursierten laut PHP Foundation schon am 20. Oktober, einen Tag vor den Korrekturen, und die Sicherheitsfirma Rapid7 sieht mehrere Hinweise darauf, dass der Angriff unabhängig nachgebaut wird. Wer erst in der nächsten Wartungswoche nachsieht, ist spät dran.

Was wir nicht geprüft haben

Wir haben die Lücken nicht selbst ausgenutzt und keinen Hoster nach seinem Stand gefragt. Die Angaben stammen von php.net, aus dem Beitrag der PHP Foundation vom 21. Oktober und aus der Sicherheitsübersicht von Debian. Den Stand bei Ubuntu und bei einzelnen Hostern haben wir nicht nachgesehen. Ob die vorübergehenden Einstellungen wirken, haben wir nicht getestet.

Stand dieses Artikels

Geschrieben am 22. Oktober 2026. Quellen: php.net (Ankündigung der Fassungen vom 21. Oktober 2026), Beitrag der PHP Foundation vom 21. Oktober 2026, Debian Security Tracker zu CVE-2026-109618, alle gelesen am 22. Oktober 2026. Nichts davon ist von uns gemessen. Keine Rechtsberatung.

Häufige Fragen