PHP2Shell: Die große PHP-Lücke und warum Updates Pflicht sind

Am 21. Oktober hat das PHP-Team ein Notfall-Update veröffentlicht. Es schließt zwei Lücken, über die Angreifer ohne Passwort eigenen Code auf einem fremden Webserver ausführen können. In der Fachpresse heißen sie „PHP2Shell“. Das BSI hat gewarnt, die US-Behörde CISA ebenfalls.

Das betrifft sehr viele Seiten. PHP läuft laut W3Techs auf knapp 70 Prozent aller Websites, deren Technik sich erkennen lässt. WordPress gehört dazu, Shopware auch, dazu unzählige selbst entwickelte Lösungen.

Was passiert ist

Beide Fehler stecken in PHP selbst. Vereinfacht: Geht einer Anfrage der Speicher aus, bricht PHP sie hart ab. Dabei bleibt manchmal Speicher in einem kaputten Zustand zurück, halb beschrieben oder schon wieder freigegeben. Wer das gezielt auslöst, kann eine spätere Anfrage dazu bringen, seinen Code auszuführen. Das PHP-Team bewertet beide Lücken mit 9,2 von 10 Punkten. (PHP-Hinweis)

• August: Die Sicherheitsfirma Calif und OpenAI melden unabhängig voneinander denselben Fehler an das PHP-Team. Die Forscher von Wiz finden weitere Angriffswege.
• 17. Oktober: Amazon sieht auf seinen Köder-Servern einen ersten Angriffsversuch, vier Tage vor der Veröffentlichung.
• 20. Oktober: Die Kennungen der Lücken sickern in sozialen Netzwerken durch. PHP zieht das Update deshalb um einen Tag vor.
• 21. Oktober: Die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen. Hoster patchen über Nacht, manche nehmen Server vorsorglich vom Netz. (Tenable, Borns IT-Blog)

Inzwischen berichten Amazon und die Sicherheitsfirma watchTowr von laufenden Angriffen.

Vierzehn Jahre unentdeckt

Der fehlerhafte Code ist alt. Betroffen ist PHP bis zurück zur Version 5.4 aus dem Jahr 2012. Millionen Server haben ihn jeden Tag ausgeführt, und niemand hat ihn als gefährlich erkannt.

Überraschend ist das eigentlich nicht. PHP ist in C geschrieben, und in C verwalten Entwickler den Speicher von Hand. Ein kleiner Denkfehler fällt nicht auf, solange er an einer Stelle sitzt, die fast nie durchlaufen wird. „Der Speicher ist voll“ ist so eine Stelle. In Tests kommt sie kaum vor.

Unangenehmer ist ein anderer Teil der Geschichte. Laut PHP Foundation fiel das Problem schon 2024 bei einer externen Sicherheitsprüfung auf. Repariert wurde es damals nicht, weil sich das Team nicht auf einen Weg einigen konnte und zu wenig Leute hatte. Die Foundation nennt das selbst ein strukturelles Versagen. (The Next Web) Wir finden es gut, dass sie das so offen sagt. Es zeigt aber auch, wie viel vom Internet an kleinen Teams hängt, die das oft nebenbei machen.

Neu ist das Tempo. OpenAI hat den Fehler mit einem eigenen Werkzeug gefunden, Calif und Wiz haben nach eigenen Angaben ebenfalls KI eingesetzt. Das hilft allen, die PHP sicherer machen wollen. Angreifer haben aber dieselben Werkzeuge. Wir rechnen deshalb damit, dass solche Meldungen in den nächsten Jahren häufiger kommen.

Ein Fix hilft erst, wenn er installiert ist

Am 21. Oktober war die Reparatur fertig. Auf einem einzelnen Server ändert das erst etwas, wenn jemand das Update einspielt und PHP neu startet.

Bei vielen Seiten wird das dauern. Laut W3Techs läuft gut ein Drittel aller PHP-Websites noch auf PHP 7 oder sogar PHP 5. Für diese Versionen gibt es seit Jahren keine regulären Sicherheitsupdates mehr. Für 7.4 bis 8.1 hat das PHP-Team diesmal immerhin Korrekturen im Quellcode bereitgestellt, aber keine fertigen Versionen. Ältere Versionen bekommen gar nichts. Schätzungen gehen von rund 884.000 Servern im Netz aus, für die kein offizieller Fix mehr kommt.

Wer seine Seite seit Jahren nicht angefasst hat, steht jetzt vor mehr als einem Update. Erst muss die Seite auf eine aktuelle PHP-Version umziehen, und dabei passen oft Plugins, Themes oder eigener Code nicht mehr. Das dauert Tage, manchmal Wochen. Die Angriffe laufen schon.

Der Unterschied ist groß: Von 8.3.35 auf 8.3.36 geht es in ein paar Minuten. Von 7.2 auf 8.4 ist es ein eigenes Projekt.

Was wir Kunden raten

Wer eine Website mit PHP betreibt, sollte heute prüfen, welche Version wirklich läuft. Ein WordPress-Update allein reicht nicht, die Lücke steckt in PHP. Bei gemietetem Hosting fragt man am besten direkt beim Anbieter nach. Auf die angezeigte Versionsnummer ist dabei nicht immer Verlass: Manche Linux-Systeme spielen Fixes ein, ohne die Nummer zu ändern. Ubuntu zeigt zum Beispiel weiter 8.3.6 an. Seiten aus reinem HTML ohne PHP sind nicht betroffen.

Auf Dauer gehören Updates zum Betrieb einer Website. PHP, CMS und Plugins sollten in festen Abständen aktualisiert werden, und eine Person sollte dafür zuständig sein. Bevor eine PHP-Version ausläuft, sollte der Umstieg geplant sein. PHP 8.2 bekommt zum Beispiel nach dem 31. Dezember 2026 keine Sicherheitsupdates mehr.

Fazit

PHP2Shell zeigt, dass eine Website kein fertiges Ding ist, das einfach liegen bleibt. PHP entwickelt sich weiter, Lücken werden gefunden, alte Versionen laufen aus, und die Website muss mit. Falsch gemacht hat diesmal kein Betreiber etwas, handeln mussten trotzdem alle. Wer regelmäßig aktualisiert, war nach ein paar Minuten fertig. Für alle anderen fängt die Arbeit jetzt erst an.