Kritische PHP-Lücke: Warum Website und Kundenportal am 21. Oktober offline waren

Am 21. Oktober waren unsere Website und das Kundenportal dash rund fünf Stunden lang nicht erreichbar. Grund waren zwei kritische Sicherheitslücken in PHP, der Programmiersprache, mit der beide Seiten laufen. Wir haben sie vorsorglich vom Netz genommen, bis die Korrektur eingespielt war. Ihre Server, Backups und Postfächer bei uns liefen die ganze Zeit weiter.

Was passiert ist

Am Abend des 20. Oktober kündigte das PHP-Projekt für den nächsten Tag eine außerplanmäßige Sicherheitsaktualisierung an. Sie sollte zwei kritische Lücken schließen, CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 Punkten bewertet. In der Fachpresse laufen die beiden Lücken unter dem Namen „PHP2Shell“. Am 21. Oktober erschienen die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Laut PHP-Projekt können die Lücken es Angreifern ermöglichen, ohne Anmeldung eigenen Programmcode auf dem Server auszuführen. Betroffen ist jede PHP-Installation, die Anfragen aus dem Internet beantwortet.

Das PHP-Projekt nannte zwar Notmaßnahmen für den Fall, dass man nicht sofort aktualisieren kann, schrieb aber selbst dazu, dass sie eine Installation nicht sicher machen. Wir sind deshalb auf Nummer sicher gegangen: Unsere potenziell betroffenen Systeme sollten bis zum Update gar nicht erreichbar sein.

Was wir getan haben

Gegen Mittag war keine unserer PHP-Installationen mehr aus dem Internet erreichbar. Wer die Website oder das Kundenportal aufrief, sah eine kurze Hinweisseite. Dahinter lief kein Programmcode, sie konnte also auch nicht angegriffen werden.

Sobald die korrigierten Pakete verfügbar waren, haben wir sie eingespielt: um 15:45 Uhr auf dem Kundenportal, um 15:54 Uhr auf der Website. Danach haben wir alle PHP-Prozesse neu gestartet und geprüft, dass keiner mehr mit der alten Version läuft. Um 16:30 Uhr waren Website und Kundenportal wieder normal erreichbar.

Ihre Cloud-Server, Ressourcen-Pools, Backups und Postfächer waren von der Wartung nicht betroffen. Sie liefen ohne Unterbrechung weiter. Während der Wartung konnten Sie allerdings Ihre Dienste nicht über das Kundenportal verwalten und keine Bestellungen aufgeben.

Betreiben Sie PHP auf Ihrem eigenen Server bei uns?

Ihre Cloud-Server verwalten Sie selbst, wir greifen nicht auf sie zu. Läuft darauf eine Website, ein Shop oder eine andere Anwendung mit PHP, sollten Sie jetzt handeln. Vier Schritte:

1. Version prüfen. php -v zeigt die Version für die Kommandozeile. Prüfen Sie aber auch die Version, die Ihre Webseiten tatsächlich ausliefert, etwa mit php-fpm8.3 -v für PHP 8.3. Sicher sind 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder neuer.
2. Aktualisieren. Spielen Sie das Update über Ihre Paketquelle ein. Achten Sie darauf, welche Version danach wirklich installiert ist. Debian 12 und Debian 13 liefern die Korrektur inzwischen über ihre Sicherheitsaktualisierungen (Stand 22. Oktober). PHP 8.1 und ältere Versionen bekommen vom PHP-Projekt keine Korrekturen mehr. Hier hilft nur ein Anbieter mit Langzeitpflege oder ein Umstieg auf eine aktuelle Version.
3. Neu starten. Ein Update allein reicht nicht. Laufende PHP-Prozesse arbeiten so lange mit dem alten Programmcode weiter, bis sie neu gestartet werden. Starten Sie also den PHP-Dienst (php-fpm) bzw. den Apache-Webserver neu, oder gleich den ganzen Server.
4. Im Zweifel abschalten. Können Sie nicht sofort aktualisieren, ist es am sichersten, die Anwendung vorübergehend nicht erreichbar zu machen. Genau das haben wir auch getan. Die Notmaßnahmen des PHP-Projekts senken das Risiko nur, sie beseitigen es nicht.

Wenn Sie unsicher sind, ob Ihr Server betroffen ist, oder Unterstützung beim Aktualisieren möchten, melden Sie sich bei unserem Support. Wollen Sie sich um solche Fragen künftig gar nicht mehr kümmern, übernehmen wir das im Rahmen unserer Managed Services.

Beitragsbild: Calif (calif.io)