PHP-Sicherheitslücke vom 21. Oktober: Was geschah und wie der aktuelle Stand ist

Am Mittwoch, den 21. Oktober, wurden zwei schwerwiegende Sicherheitslücken in PHP bekannt, der Programmiersprache, auf der der Großteil aller Websites läuft, darunter WordPress. Möglicherweise haben Sie davon etwas bemerkt, denn einen Teil des Tages waren die Websites bei uns offline. In diesem Artikel fassen wir zusammen, was passiert ist, wie wir gehandelt haben und wie der aktuelle Stand ist.

Was war los?

Die Sicherheitslücken (CVE-2026-109618 und CVE-2026-109619) ermöglichten es Unbefugten, Code auf einem Webserver auszuführen. Das ist so ziemlich die schlimmste Art von Sicherheitslücke, die es gibt: Ein Angreifer benötigt dafür kein Passwort, und sie betrifft nahezu das gesamte Internet.

Wie wir gehandelt haben

1. Vorläufige MaßnahmeMittwoch, 21. Oktober, 10:00 Uhr

   Zu diesem Zeitpunkt war nur bekannt, dass es in allen PHP-Versionen zwei schwerwiegende Sicherheitslücken gab, mit einem CVE-Score von 9,2. Details gab es noch nicht, und es waren noch keine erfolgreichen Hacks bekannt, obwohl beispielsweise Cloudflare immer mehr Versuche beobachtete. Weil die Details der Sicherheitslücke nicht bekannt waren, wusste niemand genau, wie die Situation aussah und was getan werden konnte, um das Risiko zu begrenzen. Es wurden jedoch immer mehr Abhilfemaßnahmen und mögliche Schritte zur Risikobegrenzung bekannt. Diese haben wir stets direkt umgesetzt, wie das Deaktivieren bestimmter PHP-Funktionen und das mehrfache Aktualisieren der Firewall.
   Ab 10:00 Uhr haben wir außerdem fortlaufend sehr strenge Malware-Scans durchführen lassen, damit wir sofort sehen würden, falls irgendwo ein Skript auf unseren Servern oder in den Konten unserer Kunden platziert wurde. Das ist nicht passiert.

2. Websites offlineMittwoch, 21. Oktober, 15:15 Uhr

   Obwohl wir auf unseren Servern keine Missbrauchsversuche feststellten, entschieden wir uns für die sicherste Option: alles offline nehmen. Der Hauptgrund dafür war, dass wir Zweifel an der Wirksamkeit der im Internet kursierenden Abhilfemaßnahmen (vorläufigen Lösungen) hatten, da niemand bestätigen konnte, dass diese ausreichend Schutz bieten würden.
   In einer Situation mit so vielen Unklarheiten und potenziell enormen Folgen ist einige Stunden Ausfallzeit vertretbar, das Risiko einzugehen hingegen nicht.

3. Offizielle LösungMittwoch, 21. Oktober, 16:00 Uhr

   Die Entwickler von PHP veröffentlichten das offizielle Update mit der Behebung für die Versionen 8.3, 8.4 und 8.5. Danach hieß es warten auf aktualisierte Pakete von CloudLinux, dem Anbieter der PHP-Versionen auf unseren Servern.
   Mit der Veröffentlichung des Updates wurden auch die Details der Schwachstellen bekannt, und das bestätigte unsere Vermutung: Die bekannten Abhilfemaßnahmen und zusätzlichen Firewall-Regeln verringerten zwar das Risiko eines Hacks, reichten jedoch nicht aus, um den Server zu schützen.

4. Vorläufige LösungMittwoch, 21. Oktober, 19:00 Uhr

   Leider dauerte es deutlich länger als wir gehofft und erwartet hatten, bis CloudLinux die Updates fertig hatte. Aus unserem Kontakt mit anderen Providern ging hervor, dass wir nicht die Einzigen waren, die überrascht wurden. Da wir sahen, dass sie bereits mehrfach ihre selbst gesetzten Fristen nicht eingehalten hatten, arbeiteten wir an einer vorläufigen Lösung.
   Wir installierten selbst PHP-Version 8.3.36 auf allen unseren Servern und setzten alle unsere Kunden vorübergehend auf diese Version. 90 % der Websites waren zwischen 19:00 und 20:30 Uhr wieder online. Die einzigen Websites, die nicht wieder online kamen, waren veraltet und konnten nicht mit einer modernen PHP-Version umgehen.

5. AktualisierungDonnerstag, 22. Oktober, 00:30 Uhr

   Die Updates wurden verfügbar, und wir haben sofort mit der Installation und Kontrolle begonnen, Server für Server.

6. BehobenDonnerstag, 22. Oktober, 02:30 Uhr

   Alle Server waren aktualisiert, und alle Websites waren wieder online, auf der PHP-Version, die sie zuvor ebenfalls verwendet hatten.

Wir verstehen gut, dass es ärgerlich ist, wenn Ihre Website einen Nachmittag und Abend lang nicht erreichbar ist. Diese Unannehmlichkeit wiegt jedoch weniger schwer als die möglichen Folgen. Wir mussten noch nie zuvor entscheiden, aus Vorsicht alles offline zu nehmen, aber sollte sich dieselbe Situation erneut ergeben, würden wir genau dasselbe tun.

Wie ist der aktuelle Stand?

• Alle PHP-Versionen, die wir anbieten, von 5.2 bis einschließlich 8.5, enthalten die Sicherheitskorrekturen für beide Sicherheitslücken.
• Die wenigen Websites, die auf einer noch älteren PHP-Version liefen, für die keine Korrektur existiert, haben wir auf eine korrigierte Version umgestellt.
• Wir haben die Server während und nach der Sicherheitslücke auf Spuren von Missbrauch überprüft, wie hängende PHP-Prozesse, verdächtige Prozesse, hochgeladene Dateien und Anfragen, die zu dem bekannten Angriff passen. Wir haben keine Hinweise darauf gefunden, dass die Sicherheitslücke auf unseren Servern ausgenutzt wurde, und auch bevor wir offline gingen, wurden keine entsprechenden Versuche festgestellt.

Ist meine Website von denen anderer getrennt?

Ja. Jedes Hostingpaket läuft bei uns in einer eigenen, abgeschirmten Umgebung. PHP läuft unter dem Benutzer Ihres Pakets, ohne Verwaltungsrechte auf dem Server, und hat keinen Zugriff auf die Dateien oder Datenbanken anderer Kunden. Auch die Nutzung von Prozessor und Arbeitsspeicher ist pro Paket begrenzt. Weitere Details zu unserer Sicherheit teilen wir bewusst nicht öffentlich: Je weniger ein Angreifer weiß, desto besser.