Das PHP-Sicherheitsteam hat heute, am 21. Oktober, eine Sicherheitskorrektur für zwei Schwachstellen veröffentlicht, beide mit 9,2 von 10 bewertet. Sie war für 10:00 Uhr (US-Ostküstenzeit) geplant und kam früher.
Sicherheitsforschende nennen das Paar PHP2Shell. Die offiziellen Bezeichnungen sind CVE-2026-109618 und CVE-2026-109619.
Wenn Ihre Website auf WordPress oder Drupal läuft, läuft sie auf PHP.
Update, 9:36 Uhr (US-Ostküstenzeit): Die Korrektur ist da
PHP hat die Korrektur vorzeitig veröffentlicht. Wir haben sie um 9:36 Uhr (US-Ostküstenzeit) auf php.net gesehen.
Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. PHP 8.1 und älter erhalten vom PHP-Projekt kein Update. Einige Linux-Distributionen und Supportanbieter portieren die Korrektur zurück, also fragen Sie Ihre, oder wechseln Sie auf eine unterstützte Version.
Mit der Veröffentlichung hat PHP bekannt gegeben, worin das Problem tatsächlich besteht. Vereinfacht gesagt:
- Beide Fehler liegen darin, wie PHP jede Webanfrage vorbereitet und aufräumt. Der eine tritt auf, wenn PHP mitten in der Vorbereitung einer Anfrage der Speicher ausgeht: Das Aufräumen kann dann halbfertige Daten als echt behandeln. Der andere lässt die Daten einer Anfrage zurück, nachdem ihr Speicher freigegeben wurde, sodass die nächste Anfrage auf demselben Worker sie verwenden kann.
- Jeder der beiden kann es einem Fremden ermöglichen, eigenen Code auf Ihrem Server auszuführen, ohne sich anzumelden, indem er speziell präparierte Anfragen sendet.
- Betroffen ist PHP, das Webseiten ausliefert: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Laut PHP ist das Risiko bei Apaches mod_php am höchsten, wofür ein funktionierender Exploit vorliegt.
- Es geschieht, bevor der eigene Code Ihrer Website läuft. Ein Sicherheits-Plugin in WordPress oder Drupal kann es deshalb nicht sehen. Was Sie schützt, sind das Update und Begrenzungen, die vor PHP greifen.
PHP nennt außerdem Einstellungen, die die Angriffsfläche verringern, wenn Sie nicht sofort aktualisieren können, und sagt, dass sie einen Server nicht sicher machen. Sie stehen in der Sicherheitsmitteilung auf php.net.
Warum LFW.com nie betroffen war: Diese Fehler stecken im Code, der läuft, wenn PHP eine Anfrage verarbeitet. Die Seiten von LFW.com sind im Voraus erzeugte Dateien, und auf unseren Servern liest kein PHP irgendeine Anfrage, also gibt es nichts auszulösen. Die schreibgeschützten Kopien, die europäische Regierungen heute Morgen bereitgestellt haben, sind aus demselben Grund sicher.
Wenn Sie eine Website vom Netz genommen haben, kann sie zurückkommen, sobald Ihr Hoster bestätigt, dass sie auf einer der korrigierten Versionen läuft.
Was wir auf unseren eigenen Servern geprüft haben
Wir haben heute Morgen mit unserer eigenen Umgebung angefangen.
- LFW.com: nicht betroffen. Es ist mit Astro gebaut und wird von Node.js ausgeliefert, und auf unseren Servern ist kein PHP installiert.
- Eine WordPress-Demo: Wir haben eine containerisierte WordPress-Demo gefunden, die wir vor etwa drei Wochen gestoppt und nie entfernt hatten. Sie lief nicht und war passwortgeschützt. Wir haben sie trotzdem entfernt, samt Datenbank und Images.
- Unsere Entwicklungsrechner: Die lokalen WordPress-Kopien, mit denen wir entwickeln, sind gestoppt, und keine ist aus dem Internet erreichbar.
Die Demo ist der Teil, den es sich zu teilen lohnt. Heute war nichts mit ihr falsch. Sie war einfach eine PHP-Website, die wir nicht mehr brauchten, und sie war immer noch da.
Die Website, an die sich niemand erinnert
An einem Tag wie diesem wird die Hauptwebsite meist gepatcht. Jemand ist für sie zuständig, und jemand behält sie im Blick.
Das Risiko ist häufiger eine Website, von der niemand mehr weiß, dass sie existiert:
- die Microsite einer abgeschlossenen Kampagne
- die Staging-Kopie, die ein Dienstleister für einen Relaunch eingerichtet hat
- die Veranstaltungswebsite von vor ein paar Jahren
- eine Demo- oder Testinstallation, die nie abgebaut wurde
Diese Websites laufen weiter auf PHP, und niemand wartet auf das Update.
Was wir heute tun würden
In dieser Reihenfolge:
- Prüfen Sie zuerst Ihren Hoster. Bei Managed Hosting schauen Sie auf die Statusseite oder den Blog Ihres Hosters. An einem Tag wie diesem veröffentlichen die meisten ihren Plan, und viele aktualisieren PHP für Sie, sodass Sie sie womöglich nicht kontaktieren müssen.
- Listen Sie jede Website auf, die auf PHP läuft. Auch die vergessenen. Entfernen Sie, was Sie nicht nutzen.
- Patchen Sie den Rest am Tag, an dem die Korrektur erscheint. Bitten Sie die Zuständigen für jede Website, Ihnen Bescheid zu geben, wenn es erledigt ist.
- Halten Sie bis dahin eine Firewall davor. Eine Web Application Firewall hilft nur, wenn der Server Datenverkehr ablehnt, der nicht durch sie kommt, also prüfen Sie auch diese Einstellung.
Den Server abschalten
Das National Cyber Security Centre des Vereinigten Königreichs sagt: Wenn Sie weder aktualisieren noch die vorübergehenden Korrekturen von PHP anwenden können, sollten Sie erwägen, das System vom Netz zu nehmen, bis Sie es können. Angesichts des gemeldeten Schweregrads ist das kein schlechter Rat, auch wenn er übereifrig wirkt.
Den Server abzuschalten muss nicht heißen, die Website abzuschalten. Sie können in der Zwischenzeit eine schreibgeschützte Kopie bereitstellen: statische Seiten, ohne PHP dahinter.
- Bürgerinnen und Bürger können die Seiten weiter lesen und die Telefonnummern finden.
- Formulare, Anmeldungen und Suchen warten, bis der Patch eingespielt ist.
- Die Kopie verschwindet wieder, sobald die gepatchte Website zurück ist.
Für eine öffentliche Website, auf die sich Menschen verlassen, ist das ein besserer Mittelweg als eine leere Seite.
Regierungen haben heute Morgen Websites vom Netz genommen
Mehrere Regierungen haben entschieden, dass ein paar Stunden offline es wert sind.
Das haben wir um 8:50 Uhr (US-Ostküstenzeit) gesehen:
- Das niederländische Nationale Cyber-Sicherheitszentrum hat seine eigene Website, NCSC.nl, vorsorglich vom Netz genommen.
- DigiD und MijnOverheid, die Anmeldung und das Bürgerportal der niederländischen Regierung, zeigten beide Seiten mit „vorübergehend nicht verfügbar“.
- Die Universität Wien hat ihre Websites, Online-Formulare, Webmail und Moodle abgeschaltet.
- Die Website des niederländischen Abgeordnetenhauses hat bei uns gar nicht geladen. NL Times berichtete, dass auch sie vom Netz genommen wurde.
- Das IT-Zentrum der finnischen Regierung, Valtori, hat vorsorglich den eingehenden Internetverkehr zu den öffentlichen Diensten des Staates abgeschaltet und das auf seiner Website mitgeteilt. Es fügte hinzu, dass der Ausfall nicht durch einen Angriff verursacht wurde.
Dafür muss sich niemand schämen. Es sind ein paar Stunden, und das Problem ist so ernst, dass die Behörde, deren Aufgabe die Cybersicherheit ist, diesen Weg für ihre eigene Website gewählt hat.
Was Cybersicherheitsbehörden Organisationen geraten haben
Es war nicht nur Europa. Nationale Cybersicherheitsbehörden auf drei Kontinenten haben am selben Tag Warnungen herausgegeben, und sie sind sich weitgehend einig:
- Vereinigtes Königreich: Das National Cyber Security Centre rät, jedes System zu finden, auf dem PHP läuft, zu aktualisieren und zu erwägen, ein System vom Netz zu nehmen, wenn das nicht möglich ist.
- Europäische Union: CERT-EU, das die eigenen Institutionen der EU schützt, hat empfohlen, aus dem Internet erreichbare Anwendungen zu isolieren, wo nicht sofort gepatcht werden kann.
- Singapur: Die Cyber Security Agency rät, sofort zu patchen und auf jedem Webserver nach PHP zu suchen, auch dort, wo die Hauptwebsite es nicht verwendet.
- Australien: Das Australian Cyber Security Centre hat Organisationen aufgefordert, PHP in ihrer Umgebung zu finden, das Patchen vorzubereiten und auf Anzeichen eines Angriffs zu achten.
Den Punkt aus Singapur würden wir unterstreichen. Eine Website, die auf etwas anderem aufbaut, kann trotzdem PHP auf demselben Server haben: ein altes Verwaltungswerkzeug, eine vergessene Installation, eine Erweiterung eines Dienstleisters.
Was ihre Offline-Seiten richtig gemacht haben
Schauen Sie sich diese Seiten genau an. Sie sind nicht leer, und sie sind keine Fehlermeldungen.
- Sie sagen, warum. Jede nennt die PHP-Schwachstellen als Grund.
- Sie sagen, was abgeschaltet ist. Wien listet jeden Dienst auf, sodass niemand raten muss.
- Sie sagen, wohin man sich wenden kann. Das NCSC verweist auf seine Website mit Sicherheitsmitteilungen, auf LinkedIn und auf eine rund um die Uhr erreichbare E-Mail-Adresse für dringende Hilfe.
- Es sind statische Seiten. Um sie anzuzeigen, braucht es kein PHP, und deshalb sind sie noch online.
Dieser letzte Punkt ist die ganze Idee der schreibgeschützten Kopie. Diese Seiten sind ihre kleinste Form.
Schreiben Sie diese Seite, bevor Sie sie brauchen
Nichts davon ist an einem ruhigen Tag schwer. Schwer ist es um 6 Uhr morgens am Tag eines Sicherheitsreleases.
Deshalb lohnt es sich, ein paar Dinge jetzt zu entscheiden, solange alles in Ordnung ist:
- Wer die Website abschalten darf, und wen diese Person informiert. Ein Name und eine Vertretung.
- Die Offline-Seite selbst, geschrieben und an einem Ort gespeichert, an dem kein PHP läuft: der Grund, was abgeschaltet ist, wo es Neuigkeiten gibt und wie man einen Menschen erreicht.
- Welche Seiten nie dunkel werden dürfen. Notfallmeldungen, Abkochgebote für Trinkwasser, die Telefonnummern. Sie gehören in die schreibgeschützte Kopie.
- Woran Sie erkennen, dass die Rückkehr sicher ist. In der Regel: Ihr Hoster bestätigt die gepatchte Version, und Sie prüfen selbst eine Seite.
Ein paar Stunden offline, geplant, sind ein guter Tag. Ungeplant sind sie eine Schlagzeile.
Wenn Sie Unterstützung möchten
Wir helfen Ihnen gern, all das durchzugehen, ob es darum geht, die vergessenen Websites zu finden oder eine schreibgeschützte Kopie bereitzustellen. Schreiben Sie uns.
Leland Fiegel