PHP2Shell: kritische PHP-Sicherheitslücke – ist Ihre Website betroffen?

Betroffen sind alle PHP-Versionen, die in ihrem Zweig älter sind als 8.5.12, 8.4.27, 8.3.36 und 8.2.35, und das heißt nahezu jede PHP-Website, die diese Woche niemand aktualisiert hat. Heute besteht die erste Aufgabe darin, festzustellen, unter welcher Version Ihre Website läuft, und sie zu aktualisieren – eine vollständige Umgehung gibt es nicht, und die Meldung von PHP selbst sagt, dass die Aktualisierung die einzige sichere Wahl ist.

Am Mittwoch, dem 21. Oktober, hat das PHP-Team gleichzeitig vier Notfallversionen veröffentlicht. Das Paar von Sicherheitslücken, das sie beheben, hat den Namen PHP2Shell erhalten, und der beschreibt das Ergebnis genau: von der Netzwerkanfrage bis zur Ausführung von Code auf dem Server. Dieser Artikel handelt davon, was genau gefunden wurde, wie Sie erkennen, ob es Sie betrifft, und in welcher Reihenfolge Sie handeln – auch dann, wenn Sie nicht sofort aktualisieren können.

Was PHP2Shell ist und was am 21. Oktober geschah

In der offiziellen Meldung heißt es, dass 8.5.12, 8.4.27, 8.3.36 und 8.2.35 zwei kritische Sicherheitslücken beheben, die einem nicht authentifizierten Angreifer die Ausführung von Code aus der Ferne (Remote Code Execution, RCE) erlauben können, und dass allen PHP-Nutzern dringend geraten wird, sofort zu aktualisieren. Dort steht auch der Satz, der den übrigen Inhalt dieses Artikels bestimmt: eine vollständige Umgehung gibt es nicht, und die Aktualisierung ist die einzige sichere Wahl.

PHP hat beiden Sicherheitslücken im Common Vulnerability Scoring System (CVSS) v4.0 den CVSS-Wert 9.2 von 10 zugewiesen, doch es sind zwei getrennte Fehler mit unterschiedlichem Mechanismus und, wie Sie weiter unten sehen, auch mit unterschiedlichem Nachweisgrad – und genau dieser zweite Unterschied bestimmt in der Praxis, bei welchem Server Sie anfangen.

CVE-2026-109618 – beschädigter Speicher nach einem Out-of-Memory (OOM): Wenn PHP der Speicher ausgeht, bricht es die Verarbeitung der Anfrage mit longjmp() ab. Die offizielle Beschreibung hält fest, dass der Speicher der Anfrage in manchen Momenten erreichbar ist, bevor er vollständig initialisiert wurde; schlägt genau dann die Speicherzuweisung fehl, wird der Abbruch nicht korrekt behandelt, und es bleibt ungültiger Speicher, den der Code beim Abschluss der Anfrage noch liest oder anhand dessen er eine Entscheidung trifft.

Ein wichtiges Detail, das ändert, wen diese Gefahr betrifft: den Out-of-Memory-Zustand erreicht eine eigens präparierte Multipart-Anfrage, und in ihr muss keine einzige hochgeladene Datei stecken. Die offizielle Beschreibung nennt mehrere Probleme bei der Multipart-Verarbeitung – eine Anfrage ohne nutzbare angegebene Länge, einen Teil mit unbegrenzter Zahl von Headern, leere Dateifelder, die nicht in die Begrenzungen eingerechnet werden. Das heißt, die Anfrage kann ganz klein sein und innerhalb der gewöhnlichen Grenzen von post_max_size und memory_limit bleiben.

CVE-2026-109619 – veralteter globaler Zustand: Im PHP-Prozess bleibt zwischen den Anfragen ein globaler Zustand erhalten: Daten zu Fehlern, Sitzungen, Objekten und Erweiterungen. Die offizielle Beschreibung sagt, dass dieser Zustand zurückgesetzt werden muss, bevor der Speicher der Anfrage freigegeben wird. Wird das Zurücksetzen von einem fatalen Fehler unterbrochen oder füllt die Diagnose ihn im Abschluss erneut, wird der Speicher freigegeben, der Zeiger darauf bleibt aber; diese Fehlerklasse heißt international Use-after-free.

Danach kommt eine Bedingung, die diese Sicherheitslücke schwieriger macht, als sie klingt: den veralteten Zeiger kann nur eine Aktion benutzen, die vor der gewöhnlichen Initialisierung der Anfrage geschieht, und die offizielle Beschreibung nennt zwei bestätigte solche Fälle – die INI-Diagnose und die Verarbeitung des Upload-Fortschritts der Sitzung. Außerdem muss die spätere Anfrage des Angreifers genau in demselben Prozess ankommen, in dem der beschädigte Zustand entstanden ist, deshalb gelingt ein einzelner Versuch selten, und die Beschreibung weist ausdrücklich darauf hin, dass mehrere Prozesse und ihr Wechsel die Chancen senken, die Bedingung selbst aber nicht beseitigen.

Wie leicht sich das ausnutzen lässt und wogegen es nachgewiesen ist

Hier lohnt sich Genauigkeit, denn genau an dieser Stelle übertreiben die meisten Artikel im Netz in die eine oder die andere Richtung.

Ein Passwort ist nicht nötig, und es ist auch nicht nötig, dass jemand auf der Website etwas anklickt – im CVSS-Vektor ist das als PR:N und UI:N zu sehen. Im selben Vektor stehen allerdings AC:H und AT:P: die Angriffskomplexität ist als hoch bewertet, und es gibt zusätzliche Voraussetzungen. In der Praxis heißt das wiederholte Versuche, und ob sie gelingen, hängt vom PHP-Build, von den Erweiterungen, vom Verhalten des Frontends und vom Speicherlayout ab. Also nein – eine einzige gewöhnliche Anfrage reicht nicht; dem Angreifer kostet das aber auch nichts, denn nichts begrenzt die Zahl der Versuche.

Der Nachweisgrad unterscheidet sich bei beiden Fehlern, und dieser Unterschied ist wichtig, wenn Sie entscheiden, wie sehr Sie sich beeilen. Im Fall von CVE-2026-109618 ist die vollständige Ausführung von Code aus der Ferne gegen mod_php mit den Standardgrenzen für Eingabe und Speicher bestätigt; über PHP-FPM sagt dieselbe Beschreibung, dass die Quelltextanalyse es für anfällig hält, ein vollständiger PHP-FPM-Angriff aber nicht vorgeführt wurde. FrankenPHP wird dort als Analogon zu mod_php genannt, LSAPI als Analogon zu PHP-FPM, in beiden Fällen ohne geprüften Angriff.

Im Fall von CVE-2026-109619 ist der Weg über den Lebenszyklus der Sitzung sowohl gegen mod_php als auch gegen PHP-FPM geprüft, während der andere Weg, der über die Ablaufverfolgung des fatalen Fehlers führt, nur gegen mod_php bestätigt ist.

Daraus folgt eine praktische Reihenfolge: läuft Ihre Website auf mod_php, stehen Sie ganz vorn, denn genau dort sind beide Fehler bestätigt. Bei PHP-FPM und LiteSpeed ist das Risiko real, aber vorerst nur teilweise bestätigt. In keinem dieser Fälle ist das ein Grund zu warten – es ist ein Grund zu wissen, bei welchem Server Sie anfangen.

Wie diese Woche Stunde für Stunde aussah

Die Chronologie ist keine Kuriosität – sie erklärt, warum die Empfehlungen in den ersten Stunden von denen abwichen, die jetzt gelten, und warum ein Teil der Artikel im Netz noch veraltet ist.

Am Abend des 20. Oktober war bekannt, dass etwas kommt, aber nicht, was genau: PHP hatte eine bevorstehende Notfallveröffentlichung angekündigt, und die Statusseite von CloudLinux hält am selben Abend fest, dass die technischen Daten und die betroffenen Versionen zum Zeitpunkt der Veröffentlichung am nächsten Tag geplant veröffentlicht werden sollten; die technische Beschreibung war da noch nicht öffentlich.

Bis zum nächsten Tag hatte sich die Lage geändert, und nicht zum Besseren: am Morgen des 21. Oktober hält CloudLinux fest, dass bereits ein Angriffsmuster öffentlich zirkuliert, und um 9:08 Uhr UTC verbreitet es einen Firewall-Regelsatz, der das bekannte Muster der Ausnutzungsanfrage blockiert. Achtzehn Minuten später erscheint auf derselben Seite der Satz, der diese Woche am besten kennzeichnet – Versuche, die diesem Muster entsprechen, werden bereits beobachtet – jemand suchte also schon nach Servern, auf denen das Sicherheitsupdate noch fehlt.

Die PHP-Sicherheitsupdates kamen um 14:00 Uhr UTC heraus, das heißt, zwischen einem öffentlich verfügbaren Angriffsmuster und einem öffentlich verfügbaren Sicherheitsupdate lagen mehrere Stunden, und in diesen Stunden fanden Angriffsversuche bereits statt.

Eine Einschränkung ist hier ehrlich zu sagen: ganz ohne Sicherheitsupdate war die Welt nicht, denn in der PHP-Meldung steht, dass Linux-Distributionen und Anbieter mit langfristigem Support die Sicherheitsupdates im Voraus erhielten, sodass für einen Teil der Server das Sicherheitsupdate früher verfügbar war als für die übrigen – öffentlich verfügbar war es allerdings für niemanden.

Danach begann der längere Teil, der noch andauert: die Verteilung der Pakete. Die Paketbetreuer der Betriebssysteme und die Hosting-Plattformen bauen ihre Pakete getrennt, und sie erscheinen im Lauf von Stunden oder Tagen, jedes in seinem eigenen Tempo. Genau in dieser Phase befindet sich ein großer Teil der Nutzer von Webhosting (Shared Hosting), und genau deshalb sind die Frage „ist das Sicherheitsupdate erschienen“ und die Frage „ist das Sicherheitsupdate auf meinem Server“ diese Woche zwei verschiedene Fragen mit verschiedenen Antworten.

Ob Ihre Website betroffen ist

In den offiziellen Warnungen sind die Bereiche der betroffenen Versionen so geschrieben: alles, was älter ist als 8.2.35, alles, was älter ist als 8.3.36, alles, was älter ist als 8.4.27, und alles, was älter ist als 8.5.12 – jeder Zweig für sich.

Ein wichtiges Detail, das einen Fehler zulässt: die Zahl, die php -v zeigt, sagt nicht immer alles. Linux-Distributionen und Hosting-Plattformen übertragen das Sicherheitsupdate oft auf eine ältere Version, ohne deren Nummer zu ändern – es ändert sich nur die Release-Nummer des Pakets. In dem Fall kann 8.4.26 bereits repariert sein, muss es aber nicht. Der einzige Weg, das zu wissen, ist ein Blick in die Paketbeschreibung oder eine Frage an den Anbieter; die Versionsnummer selbst beantwortet diese Frage nicht.

Gesondert zu den älteren Versionen: PHP 8.1 und älter erhalten vom PHP-Projekt keine regelmäßigen Updates mehr, doch angesichts der Schwere hat das Sicherheitsteam minimale Sicherheitsupdates im Quelltext für die Versionen 7.4, 8.0 und 8.1 vorbereitet – für alle, die aus dem Quelltext bauen oder keinen Zugang zum Support eines Betreuers haben. Die Meldung empfiehlt dort zugleich, sich an den eigenen Anbieter zu wenden, weil ein Teil der Distributionen und der Anbieter mit langfristigem Support die Sicherheitsupdates überträgt. Läuft Ihre Website auf PHP 7.x, ist das eigentliche Problem nicht diese Woche – das eigentliche Problem ist, dass es beim nächsten Mal auch kein Sicherheitsupdate geben kann. Und PHP 8.2, das diesmal ein Sicherheitsupdate erhielt, erreicht am 31. Dezember 2026 das End of Life.

Wie Sie die Version prüfen, je nachdem, wo die Website liegt

Die Prüfung dauert Minuten, und sie lohnt sich für jede Website einzeln, nicht für jeden Server: auf einem Server liegen oft Websites mit unterschiedlichen PHP-Versionen, und gewöhnlich ist gerade die älteste, die alle vergessen haben, öffentlich erreichbar.

Webhosting (Shared Hosting) mit cPanel: Die Version zeigt der Bereich MultiPHP Manager, in dem jede Domain eine eigene Zeile hat; Plesk verwendet dafür PHP-Einstellungen innerhalb jedes Abonnements. In beiden Fällen lohnt es sich zu prüfen, dass Sie die Domain ansehen, um die es geht, und nicht den Server-Standard.

Eigener Server oder VPS: Auf der Kommandozeile zeigt php -v die Version, mit einer wesentlichen Einschränkung: das PHP der Kommandozeile ist oft eine ganz andere Version als die, die Webanfragen beantwortet. Die verlässlichste Antwort gibt derselbe Weg, über den die Website arbeitet – die ausführbare Datei, die im Abschnitt pool der PHP-FPM-Konfiguration genannt ist.

Container: Läuft die Website in Docker, bestimmt das Image die Version, nicht das Hostsystem, deshalb sind es zwei Schritte: das Image mit einem aktualisierten Basis-Image neu bauen und danach die Container neu starten. Ein Image, das vor dem 21. Oktober gebaut wurde, enthält das Sicherheitsupdate nicht, unabhängig davon, wie oft der Container neu gestartet wurde.

Wenn Sie zu keinem davon Zugang haben, geht die Frage an den Hosting-Anbieter, und diese Woche ist das eine völlig normale Frage, auf die dort bereits eine Antwort vorbereitet ist. Die Formulierung, die den Schriftwechsel spart: „Welche PHP-Version läuft für meine Domain, ist das Sicherheitsupdate gegen PHP2Shell enthalten, und falls noch nicht, an welchem Datum wird es das sein?“

Was Sie heute tun

Die Reihenfolge für heute ist diese: zuerst PHP aktualisieren und alles neu starten, was es ausführt, dann sicherstellen, dass die Besucher wirklich die neue Version bekommen, danach prüfen, ob das verwendete Paket-Repository das Sicherheitsupdate überhaupt veröffentlicht hat, und erst danach nach Spuren suchen. Der erste Schritt dauert Minuten, der letzte kann Tage dauern, und genau deshalb lohnt es sich nicht, sie zu vertauschen.

Erstens, aktualisieren Sie: Beim Managed Hosting tut das der Anbieter, und Ihre Arbeit ist, die Frage zu stellen und ein Datum zu erhalten. Verwalten Sie den Server selbst, ist nach der Aktualisierung der Pakete neu zu starten, was PHP ausführt: Apache, PHP-FPM oder LSAPI. Dieser Schritt wird erstaunlich oft ausgelassen – das Paket ist ausgetauscht, die alten Prozesse arbeiten aber mit dem alten Code weiter, sodass die Prüfung die neue Version zeigt, während die Besucher noch die alte bekommen.

Zweitens, prüfen Sie, dass das Sicherheitsupdate wirklich angewendet ist – auf demselben Weg, über den die Website arbeitet, nicht über die Kommandozeile.

Drittens, wenn Sie ein freiwillig gepflegtes Paket-Repository verwenden, prüfen Sie, ob es das Sicherheitsupdate veröffentlicht hat. In der PHP-Meldung steht eine gesonderte Warnung zu rpms.remirepo.net: dessen Nutzern wird geraten, auf die Pakete der Distribution zu wechseln oder aus dem Quelltext zu bauen.

Viertens, erst danach prüfen Sie, ob auf der Website Spuren sind; die Aktualisierung schließt die Tür, beantwortet aber nicht die Frage, ob schon jemand hindurchgekommen ist.

Wenn Sie nicht sofort aktualisieren können

Diesen Abschnitt sollten Sie mit dem klaren Bewusstsein lesen, dass keiner der hier genannten Schritte das Sicherheitsupdate ersetzt – die PHP-Meldung sagt das ausdrücklich.

Gegen CVE-2026-109618 nennt die Meldung das Aufheben der Speicherobergrenze: memory_limit=-1, und zwar so, dass die Anwendung es nicht überschreiben kann – zum Beispiel mit php_admin_value in der Konfiguration von PHP-FPM oder Apache, wobei sichergestellt sein muss, dass keine andere Einstellung wieder eine endliche Grenze setzt. Sie müssen verstehen, was diese Wahl kostet: auf einem Server im Webhosting tauscht sie ein Risiko gegen ein anderes, denn eine Anfrage kann jetzt den gesamten verfügbaren Speicher aufbrauchen. In der Beschreibung der Sicherheitslücke steht auch die Warnung, RLIMIT_AS und RLIMIT_DATA nicht zu verwenden, weil sie die Speicherzuweisung fehlschlagen lassen und damit genau auf den anfälligen Weg führen können.

Gegen CVE-2026-109619 nennt die Meldung session.upload_progress.enabled=0 und, bei PHP 8.5, fatal_error_backtraces=0 – in beiden Fällen mit dem Hinweis, danach alle Prozesse neu zu starten. In der Beschreibung der Sicherheitslücke selbst steht auch pm.max_requests=1, das PHP-FPM zwingt, den PHP-FPM-Worker nach jeder Anfrage auszutauschen; das ist eine Einstellung des PHP-FPM-Pools, und dort ist sie mit der Einschränkung genannt, „wenn die Leistung kein Faktor ist“. Dort steht auch, was diese Maßnahme in den richtigen Grenzen hält: der Austausch der Worker senkt die Chance pro Anfrage, beseitigt die Bedingung selbst aber nicht.

Nützlich ist auch, was keine Umgehung ist, aber die Angriffsfläche verkleinert: ein konservatives post_max_size, eine vernünftige Verschachtelungstiefe der Eingabe und ein begrenztes Upload-Volumen; das sind in jeder Woche gute Werte, nicht nur in dieser.

Woran Sie erkennen, ob Sie bereits betroffen sind

Nach der Aktualisierung lohnt es sich, die Protokolle des Webservers der letzten Tage durchzusehen. Zu suchen ist eine ungewöhnlich große Zahl von Multipart-Anfragen an ein und dieselbe Adresse – und hier sucht man leicht falsch: sie sind oft klein und liegen innerhalb der gewöhnlichen Grenzen, deshalb findet man sie nicht über das Volumen. Aussagekräftiger sind plötzliche Serien von 500-Fehlern, die ohne erkennbaren Grund beginnen und enden: ein Angriff, der darauf beruht, dass der Speicher ausgeht, scheitert viel öfter, als er gelingt, und jeder misslungene Versuch hinterlässt einen Fehler.

Im Dateisystem zählen die Änderungszeiten: eine PHP-Datei, die nachts geändert wurde, als niemand gearbeitet hat, muss erklärt werden. Zu prüfen sind auch die geplanten Aufgaben und die Einträge, die einen automatischen Start nach dem Neustart sicherstellen – für einen Angreifer mit Ausführung von Code ist die erste Arbeit, sich festzusetzen, damit der Zugang genau das Sicherheitsupdate überlebt, das Sie gerade eingespielt haben.

Gesondert lohnt es sich, die Liste der Administratorkonten und die Passwörter und Schlüssel der Anwendungen zu prüfen. Hat eine Ausführung von Code stattgefunden, ist alles, was der Server kennt, als gelesen zu betrachten – auch die Zugangsdaten der Datenbank und die API-Schlüssel in der Konfigurationsdatei.

Sieht etwas davon nicht richtig aus, ist die Bereinigung eine eigene Arbeit mit eigener Reihenfolge, und sie lohnt sich methodisch, nicht indem verdächtige Dateien einzeln gelöscht werden. Wir haben das gesondert beschrieben – wie die Wiederherstellung einer gehackten Website abläuft, und wenn Sie möchten, dass das jemand anders tut, ist die Wiederherstellung gehackter Websites eine eigene Leistung mit fester Reihenfolge: Isolierung, Bereinigung, Beseitigung der Ursache und Prüfung, dass die Website aus den Warnlisten der Suchmaschinen entfernt ist.

Wann der Vorfall meldepflichtig wird

Gibt es Grund zu der Annahme, dass ein Angreifer Zugang zu personenbezogenen Daten hatte, wird aus der technischen Frage auch eine rechtliche. Die Datenschutz-Grundverordnung sieht eine Frist vor, die nicht mit dem Angriff beginnt, sondern in dem Moment, in dem der Verantwortliche von der Verletzung des Schutzes personenbezogener Daten Kenntnis erlangt hat: möglichst binnen 72 Stunden die Meldung an die Aufsichtsbehörde. Die Pflicht tritt nicht ein, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt, und ist das Risiko hoch, sind auch die betroffenen Personen selbst zu informieren – auch diese Pflicht hat in der Verordnung eigene Ausnahmen.

Die praktische Bedeutung dieses Abschnitts ist eine: der Moment, in dem in den Protokollen etwas Verdächtiges gefunden wurde, ist nicht der Moment, in dem die 72 Stunden zu laufen beginnen – es ist der Moment, in dem zu klären ist, ob eine Verletzung des Schutzes personenbezogener Daten überhaupt stattgefunden hat. Eine einzelne Serie von 500-Fehlern, die, wie oben beschrieben, meist ein misslungener Versuch ist, ist für sich genommen keine solche Verletzung. Gerade deshalb lohnt es sich nicht, diese Klärung auf „wenn weniger zu tun ist“ zu verschieben, und gerade deshalb sind die Protokolle zu sichern, bevor die Rotation sie überschreibt: sie sind der einzige Nachweis sowohl dafür, was geschehen ist, als auch dafür, was nicht geschehen ist.

Wenn mehrere Websites in Ihrer Verantwortung liegen

Für Agenturen und Unternehmen mit mehreren Websites ist diese Woche weniger eine technische als eine organisatorische Aufgabe, und die Reihenfolge, die funktioniert, ist einfach: zuerst die Liste, dann die Versionen, dann die Aktualisierung in der Prioritätsreihenfolge.

Die Priorität bestimmt nicht die Wichtigkeit der Website, sondern die Erreichbarkeit und das, wodurch sie bedient wird. Oben stehen öffentlich erreichbare Websites auf mod_php, denn genau dort sind beide Sicherheitslücken bestätigt; dann das übrige Öffentliche, und erst danach interne Systeme hinter der Firewall. Test- und Entwicklungsumgebungen, die alle vergessen, gehören zwingend auf die Liste – sie laufen oft auf einer älteren PHP-Version und sind oft aus dem Internet erreichbar, weil das einmal bequemer war.

Websites, die jemand anders verwaltet, bleiben auf der Liste, aber mit einer anderen Spalte: wem die Frage geschickt wurde und an welchem Datum die Antwort kam. Diese Spalte erweist sich später als wertvoller als die übrigen, denn genau sie zeigt, welcher Anbieter reagiert und welcher nicht.

Was Managed Hosting in diesem Fall bedeutet hat

Diese Woche zeigt gut, wo die Grenze zwischen Plattform und Anwendung liegt, deshalb ist ehrlich zu sagen, wie das von unserer Seite aussah.

Unsere Server laufen auf CloudLinux, und in ihnen ist Imunify360 eingebaut; als das Angriffsmuster öffentlich zu zirkulieren begann, hielt CloudLinux auf seiner Statusseite fest, dass der Firewall-Regelsatz, der das bekannte Ausnutzungsmuster blockiert, um 9:08 Uhr UTC verteilt war – mehrere Stunden bevor PHP das Sicherheitsupdate selbst um 14:00 Uhr veröffentlichte, und bevor auf derselben Seite der Eintrag erschien, dass Versuche bereits beobachtet werden. Im Lauf des Tages folgten zwei weitere Ergänzungen, von denen die zweite das bereits öffentlich verfügbare Ausnutzungswerkzeug blockiert; all das geschah automatisch, ohne Beteiligung des Kunden. In der Branche heißt eine solche Maßnahme Virtual Patching: eine Regel der Web Application Firewall (WAF) blockiert die Ausnutzung der Sicherheitslücke, ohne den anfälligen Code selbst zu ändern.

Und jetzt das, was ein solcher Satz nicht bedeutet, denn genau an dieser Stelle hat die Branche diese Woche die meisten Übertreibungen verkauft. Eine Firewall-Regel blockiert bekannte Angriffsmuster – dasselbe Wort verwendet auch CloudLinux. Dieselbe Seite nennt diese Maßnahme eine Übergangslösung, nicht eine vollständige Behebung. Das ist keine Unverwundbarkeit, und CloudLinux selbst empfiehlt weiterhin, PHP zu aktualisieren, sobald die Pakete verfügbar sind. Der Unterschied zwischen „geschützt“ und „repariert“ ist diese Woche ganz konkret, und das eine als das andere zu verkaufen wäre unredlich.

Wie das Sicherheitsupdate selbst aussieht, ist eine gute Illustration dessen, wovor oben gewarnt wurde. Unsere Server erhielten am Abend desselben Tages einen neuen Build von ea-php84, einige Stunden nach der PHP-Veröffentlichung. Die Versionsnummer änderte sich nicht – php -v schreibt weiterhin 8.4.26, nicht 8.4.27, und das Einzige, was von außen auf die Änderung hinweist, ist das Build-Datum, das vom 9. auf den 21. Oktober sprang. Genau so sieht ein übertragenes Sicherheitsupdate aus, und genau deshalb ist die Frage an den Hosting-Anbieter mehr wert als die Zahl auf dem Bildschirm.

Der Wert, den Managed Hosting hier gekauft hat, ist deshalb nicht Unverwundbarkeit, sondern ein engeres Zeitfenster: die Stunden, in denen das Angriffsmuster bereits zirkulierte und Versuche bereits stattfanden, wurden durch das Blockieren der bekannten Muster abgedeckt und nicht ausgesessen. Und danach – dass jemand die Pakete verfolgt und die Prozesse neu startet, statt zu warten, bis der Kunde es bemerkt. Unser Managed Hosting beginnt ab 45 € im Monat, und genau solche Wochen sind das, wofür man in dieser Summe zahlt.

Wenn Ihre Website derzeit irgendwo läuft, wo auf die Frage nach der PHP-Version und dem Datum der Aktualisierung keine Antwort zu bekommen ist, ist das selbst schon eine Antwort. Sprechen wir über die Migration – sie lässt sich gewöhnlich ohne Ausfallzeit durchführen.

Nach der Aktualisierung ist mehr neu zu starten, als es scheint

Ein Prozess, der zwischen den Anfragen am Leben bleibt, ist nichts Exotisches – genau so arbeiten ein gewöhnlicher PHP-FPM-Pool und mod_php, und genau gegen sie ist die Ausführung von Code bestätigt. CVE-2026-109619 ist deshalb keine Gefahr besonderer Konfigurationen; es ist ein Problem der gewöhnlichen Konfiguration.

Daraus folgt der Schritt, der am häufigsten ausgelassen wird: der Austausch des Pakets berührt den Prozess nicht, der bereits läuft. Nach der Aktualisierung ist jeder Prozess neu zu starten, der PHP ausführt, und das gilt auch für die, die gewöhnlich niemand anfasst. Lange laufende PHP-Prozesse werden oft wochenlang nicht neu gestartet, deshalb lohnt es sich, sie nach der Aktualisierung gesondert aufzuzählen und sich zu vergewissern, dass jeder von ihnen neu hochgefahren wurde.

Die richtige Prüffrage ist deshalb nicht „was zeigt php -v“, sondern „ist jeder Prozess, der PHP ausführt, gestartet worden, nachdem das Paket ausgetauscht wurde“.

Warum „wir laden doch gar nichts hoch“ nicht reicht

Ein verbreiteter Einwand klingt ungefähr so: unsere Website ist eine Visitenkarte, auf ihr gibt es weder ein Upload-Formular noch Benutzerkonten, also betrifft uns das nicht. Leider betrifft es Sie doch, und der Grund ist genau das, was oben beschrieben ist: der Angriff braucht keine hochgeladene Datei, eine entsprechend präparierte Multipart-Anfrage reicht, und die lässt sich an jede Adresse schicken, die mit PHP antwortet. Dass auf der Seite ein Formular vorhanden ist, ist keine Voraussetzung, denn der Angreifer füllt kein Formular aus.

Ebenso spielt es keine Rolle, ob die Website klein ist; Angriffe auf solche Sicherheitslücken laufen in einem weiten Netz und automatisch, und eine Auswahl nach der Zahl der Besucher nimmt niemand vor. Die Einheit Unit 42 von Palo Alto Networks berichtete am Tag der Veröffentlichung von mehr als 22,6 Millionen im Internet erreichbaren PHP-Instanzen, die potenziell betroffen sind; keine davon ist besonders ausgewählt.

Der zweite Einwand gilt WordPress und Plugins; auch der trägt diesmal nicht, nur in der entgegengesetzten Richtung: die Sicherheitslücke liegt in PHP selbst, nicht in WordPress, Laravel oder einem Plugin. Das heißt, ein Plugin-Update löst dieses Problem nicht, und zugleich ist jede PHP-Website betroffen, unabhängig davon, worauf sie gebaut ist.

Was von dieser Woche bleiben sollte

Wo alles in Ordnung war, lag das nicht an einer schnellen Reaktion, sondern an drei Dingen, die früher geordnet waren: es war bekannt, welche Website auf welcher PHP-Version läuft, es war bekannt, wer für die Aktualisierung verantwortlich ist, und es gab Backups, an denen tatsächlich geprüft wurde, dass sich die Website daraus wiederherstellen lässt. Keines davon lässt sich an dem Tag erledigen, an dem die Warnung schon veröffentlicht ist, und genau deshalb war diese Woche für die einen Teams eine halbe Stunde Arbeit und für die anderen zwei Tage Arbeit.

Wenn aus dieser Woche eine Aufgabe mitzunehmen ist, damit es beim nächsten Mal leichter wird, dann ist es die Liste: jede Website, ihre PHP-Version, die Art, wie sie ausgeführt wird, ihr Hosting-Anbieter und die Person, die „aktualisieren“ drücken darf. Die nächste solche Warnung wird kommen, und die einzige Frage ist, wie lange es dann dauert, die Frage „betrifft uns das“ zu beantworten.