Kritische Sicherheitslücken in PHP, das ist zu tun

Update 21.10.2026, 15:45 Uhr: Das PHP-Team hat die erwarteten Sicherheitsupdates veröffentlicht. Die neuen Versionen sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für WordPress-Websites heißt das: Entweder der Hoster spielt das Update ein, oder es muss selbst eingespielt werden.

Was jetzt feststeht

Laut offizieller Ankündigung betreffen beide Lücken jede PHP-Installation, die Webanfragen ausliefert. Sie erlauben damit das Ausführen von Code aus der Ferne (RCE), ohne Anmeldung. Bei CVE-2026-109618 geht es um beschädigte Daten, wenn PHP mitten in einer Anfrage der Speicher ausgeht. Bei CVE-2026-109619 kann ein Zustand aus einer früheren Anfrage im selben Prozess weiterleben und später missbraucht werden. Betroffen sind unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das PHP-Security-Team das Risiko bei mod_php ein.

Entdeckt hat die Lücken nach eigener Darstellung das Research-Team von Wiz, im August. Gemeldet wurden sie am 24. August. Am 21. September hat das PHP-Team die Arbeit an einem Fix aufgenommen. Die Veröffentlichung war also schon lange geplant. Ein Leak am Dienstag kam dazwischen und die Updates erschienen einen Tag früher als ursprünglich angedacht.

Eine Liste betroffener Versionen veröffentlicht das PHP-Security-Team weiterhin nicht. Wiz spricht von fast allen Versionen seit PHP 5.4 und davon, dass jede Version der letzten zehn Jahre mindestens einen der Fehler enthält.

Wenn heute noch kein Update möglich ist

Das PHP-Team hat inzwischen eigene Zwischenlösungen veröffentlicht. Sie verringern das Risiko, machen eine Installation aber nicht sicher. Der einzig vollständige Fix ist das Update.

Die Einstellung session.upload_progress.enabled = 0, die weiter unten in diesem Artikel erwähnt wird, gehört offiziell zu CVE-2026-109619 und hilft auch nur gegen diese eine Lücke. Und es gibt wichtige Einschränkung: Sie wirkt nur in der php.ini, im FPM-Pool oder in der Serverkonfiguration, jeweils mit anschließendem Neustart aller Worker. In einer .user.ini oder per ini_set() reicht sie laut PHP-Security-Team nicht aus. Wer Shared Hosting nutzt und nur eine .user.ini hat, kann sich damit also nicht absichern und muss auf den Hoster oder auf das Update warten.

Für CVE-2026-109618 nennt PHP andere Maßnahmen, etwa memory_limit = -1 und ein niedriges post_max_size, beides am besten dort gesetzt, wo Anwendungen es nicht überschreiben können. Das ist Handarbeit für Betreiber*innen eigener Server. Die Details stehen in der PHP-Ankündigung.

Und wenn schon jemand probiert hat?

Ein Update beseitigt zwar die Schwachstelle, behebt aber keine Infektion, sollte jemand die Lücke schon ausgenutzt haben. Die Details dieser Schwachstellen sind seit mindestens Dienstabend im Umlauf. Wer einen Server selbst betreibt, sollte deshalb vor dem Update die Logs sichern und nach ungewöhnlichen Multipart-Anfragen seit etwa 15:00 UTC am Dienstag suchen. Wiz gibt als zusätzlichen Hinweis Speicherlimit-Fehler oder wiederholte HTTP-500-Antworten, außerdem auffallend große oder fehlerhafte PHPSESSID-Cookies und unerklärlich viele neu gestartete PHP-Worker an. Die Anwendungslogs zeigen dabei oft wenig, weil die Fehler schon vor der Anwendung passieren. Dazu kommen neue oder geänderte Dateien in Webroot, Plugins und Uploads, außerdem .user.ini, auto_prepend_file und neue Admin-Konten.

Wiz hat auch gezeigt, dass sich Speicherinhalte anderer Anfragen auslesen lassen, etwa Passwörter, Zugangstokens oder API-Schlüssel. Angriffe in freier Wildbahn meldet Wiz bislang nicht. Wer aber einen Server betreibt, auf dem Zugangsdaten durch PHP laufen, sollte nach dem Update überlegen, welche davon er vorsorglich erneuert.

Auf Shared Hosting lässt sich das meiste davon nicht selbst prüfen. Da hilft im Zweifelsfall eine Nachfrage beim Hoster.

Ursprünglicher Post:

Einfache Updates für PHP, die Programmiersprache, auf der jede WordPress-Website basiert, sind hier für gewöhnlich keine Meldung wert. Sie kommen alle paar Wochen, und laufen bei guten Hostern still im Hintergrund mit. Heute ist eine Ausnahme.

Gestern Abend hat das PHP-Security-Team ein Sicherheits-Release für heute Nachmittag angekündigt. Heute, am Mittwoch, 21. Oktober, um 16:00 Uhr mitteleuropäischer Sommerzeit sollen zwei kritische Sicherheitslücken geschlossen werden. Beide Lücken fallen offenbar in den besonders kritischen Bereich der CVSS genannten Klassifizierung für Schwachstellen. Nach offiziellen Berichten erreichen die beiden Lücken offenbar einen Wert von 9,2. Wie genau die beiden Lücken aussehen ist bisher nicht bestätigt. Es ist aber schon sicher, dass ein sofortiges Update von PHP nötig sein wird, sobald offiziell verfügbar.

Dieser Beitrag ist für den Moment also ein Zwischenstand. Ich ergänze ihn, sobald die Releases da sind und wir mehr über die Tragweite sagen können.

Was wir bisher wissen

Im Rahmen der offiziellen Kommunikation ist bisher nur der Schweregrad der Lücken und der angekündigte Veröffentlichungszeitpunkt bekannt. Das PHP-Security-Team behält sich außerdem vor, die Updates früher zu veröffentlichen, falls Details zu den Lücken öffentlich werden oder Angriffe auftauchen.

Und schon vor der Ankündigung gestern tauchen immer wieder Gerüchte über einzelne Details online auf. Die substanziellsten Informationen stammt aus einem Leak. Demnach haben die Lücken die Kennungen CVE-2026-109618 und CVE-2026-109619 und erlauben Remote Code Execution, also das Ausführen von beliebigem Code auf einem System. Das Sichterheitsunternehmen watchTowr hat bestätigt, dass die geleakten Informationen echt sind. Ein Gerücht, dass alle PHP-Versionen ab PHP 5 betroffen sein sollen, hat das PHP-Security-Team bisher nicht bestätigt. Auch der CVSS-Wert von 10,0, der online kursiert, ist nicht die offizielle bestätigt.

Laut der Website BleepingComputer gibt watchTowr an, die Veröffentlichung sei ursprünglich erst für den morgigen Donnerstag geplant gewesen. Sie wurde also offenbar schon um einen Tag vorgezogen. watchTowr hat nach eigener Angaben bisher keine Angriffe in freier Wildbahn beobachtet, die auf die Lücken zurückzuführen sind. Das wird sich heute Nachmittag vermutlich aber schnell ändern.

Das CERT-EU ist das Notfallteam, das EU-Institutionen, Agenturen und Einrichtungen, bei Cyberbedrohungen berät und warnt, rät, zum sofortigen Patchen und dazu PHP-Anwendungen notfalls vom Netz zu nehmen, bis ein Update verfügbar ist. The Repository berichtet über eine Website mit angeblich funktionierendem Exploit-Code. Rae hat das nicht verifiziert. Ich habe die selbe Website

Was jetzt zu tun ist

Sprechen wir erstmal kurz darüber, wie diese Lücken behoben werden: wie das Security-Unternehmen Wordfence richtig erwähnt, helfen automatische WordPress-Updates dieses Mal nicht. Es geht um PHP, nicht um WordPress selbst. Im Shared Hosting und bei den meisten Managed-Hosting-Angeboten spielt der Hoster das Update ein. Wer eine VPS (Virtual Privat Server) oder einen eigenen Server betreibt, ist selbst für dieses Update verantwortlich.

Welche PHP-Version ist im Einsatz?

Es könnte heute Abend relevant werden, welche PHP-Version verwendet wird. In WordPress lässt sich die PHP-Version relativ einfach über das Website-Zustand-Tool ermitteln: Werkzeuge → Website-Zustand → Info → Server. Sobald die offiziellen Updates verfügbar sind, werde ich die Versionsnummer(n), die die Lücken schließen hier einfügen.

PHP-Version ändern

Die Support-Mitarbeitenden der verschiedenen Hosting-Unternehmen werden heute einen stressigen Tag haben. Eine Nachfrage beim Hoster, ob und wann er das Update einspielt, ist also nur bedingt sinnvoll.
Security-Updates wie das heutige werden bei den meisten Anbietern automatisch ausgespielt. Besondern im Shared-Hosting-Bereich müssen die Haupt-PHP-Versionen aber manuell umgestellt werden. Also etwa PHP 8.3 zu 8.4.

PHP 8.1 und älter erhalten keine offiziellen Updates mehr. Wer noch eine dieser Versionen verwendet, sollte also ohnehin auf eine neuere Version wechseln. (Einige Hosting-Anbieter haben kostenpflichtige Updates auch für ältere Versionen, dieser „Service“ ist meist unnötig teuer.)

Bei den meisten Hostern lässt sich die PHP-Version pro Website oder pro Domain einstellen. Das passiert in den gängigen Hosting-Panels (cPanel, Plesk oder eigene Control-Center der Anbieter). Hier empfiehlt sich schon heute Mittag ein Wechsel auf 8.3 oder 8.4. Die Version 8.2 bekommt zwar aktuell noch Sicherheitsfixes läuft aber zum Jahresende aus.

Wer jetzt auf eine neuere Version umstellt, ist noch nicht sicher, aber schonmal besser aufgestellt für das Update heute Nachmittag.

Externe Backups

Bernhard Kau empfiehlt in einer Diskussion in Slack das Anfertigen von Backups. Wenn diese außerhalb des Servers gespeichert werden, auf dem WordPress liegt, können sie für den Fall einer Kompromittierung als Ausgangspunkt für eine Wiederherstellung genutzt werden.

DIY für Betreiber*innen von VPS und eigenen Servern

Hier bleibt für den Moment vor allem das Warten auf das Release heute Nachmittag. Die neue PHP-Version kann dann über die Paketquellen der jeweiligen Distribution eingespielt werden. Wichtig ist der Anschließende Neustart von PHP-FPM und des Webservers. Sonst läuft der alte Prozess weiter. So kann das in etwa aussehen:

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # Version und Dienstname bei dir anpassen
php -vCode-Sprache: CSS (css)

(Debian und Ubuntu spielen teilweise Backports von Patches aus, sodass sich hier Versionsnummer unter Umständen nicht ändern. Ein Blick in die jeweiligen Changelos sollte Klarheit bringen.)

Eine schnelle spekulative Sicherheitsmaßnahme

Bis das Update da ist, können wir nicht viel mit Sicherheit sagen. Es scheint aber hilfreich zu sein session.upload_progress abschalten. Einige Hoster tun das offenbar schon für ihre gesamte Infrastruktur. Ben Word vom Roots-Projekt weist darauf hin, dass WordPress dieses Feature sowieso nicht nutzt. Die nötige Anpassung dafür findet in der php.ini oder .user.ini statt und sieht dann so aus:

session.upload_progress.enabled = 0

Aber: es gibt für den Moment keine offiziell Informationen über einen Zusammenhang der Lücken mit session.upload_progress. Joe Ferguson, der Release-Lead für PHP 8.6 ist und Einblick in den Code hat, warnt, das Abschalten reiche nicht aus. Wirkliche Sicherheit bringt also nur das PHP-Update.

Wer die neue PHP-Version manuell einspielt, sollte das Update für heute Nachmittag planen, nicht erst für das Wochenende.

Und wer seinen Server selbst betreibt, kann noch einen Schritt weitergehen. Verschiedene Anbieter schlagen vor, Anfragen mit multipart im Content-Type am Webserver zu blockieren. Das soll auch den zweiten Weg abdecken, den die Einstellung oben nicht erfasst. Eine wichtige Einschränkung gibt es: Damit funktionieren auch Uploads nicht mehr, in WordPress also zum Beispiel die Mediathek. Das kann also nur eine vorübergehende Maßnahme sein, keine dauerhafte Lösung.

Was heute nicht hilft

Sicherheits-Plugins, Login-Schutz und einige WAFs fühlen sich meistens gut an und helfen zum Teil sogar gegen gewöhnliche Bedrohungen. Nach allem, was bisher durchgesickert ist Wie jetzt vom PHP-Security-Team bestätigt, greift es aber zu spät. PHP dürfte Anfragen schon verarbeiten, bevor WordPress oder ein Plugin auch nur geladen werden. Alle Sicherheitsmaßnahmen auf dieser Ebene greifen also zu spät. Final bestätigt ist das im Moment noch nicht.

Wie groß ist das Problem?

Wenn wir rein nach den Statistiken von WordPress.org gehen laufen rund 35 Prozent der WordPress-Seiten auf PHP-Versionen, die keine Sicherheits-Updates mehr bekommen. Allein 16,5 Prozent noch auf PHP 7.4. Ich habe den Verdacht, dass einige davon auch in den schon erwähnten und etwas fragwürdigen „Extended Support“ Angeboten von Hosting-Unternehmen stecken, die sich mit bezahltem Support für alte PHP-Versionen eine goldene Nase verdienen.

PHP 8.1 und älter bekommen von PHP selbst keine offiziellen Updates mehr. Das PHP-Team hat zwar minimale Backports für 7.4, 8.0 und 8.1 im Quellcode veröffentlicht, die helfen aber nur denen, die PHP selbst bauen. Einige Distributionen und Anbieter liefern eigene Fixes aus. Für alle anderen bedeutet das: Version wechseln.

Zweifellos werden aber viele WordPress-Website weiterhin auf hoffnungslos veralteten PHP-Versionen zurückbleiben und ab heute damit noch angreifbarer sein.