Das bekannte Ablaufdatum: Wenn die PHP-Version zum Sicherheitsrisiko wird

Zwischen Urlaubsbildern und Hundevideos taucht im Instagram-Feed derzeit eine Anzeige auf, die aussieht wie der Blick in ein fremdes Hosting-Kontrollpanel: Speicherplatz, SSL-Zertifikat, PHP-Version. Die PHP-Version, 7.4, ist rot eingekreist, daneben der Hinweis, dass sie seit November 2022 keine Sicherheitsupdates mehr erhält, darunter in nachgeahmter Handschrift die Vermutung, die eigene Seite laufe vermutlich noch darauf. Der Begleittext liefert die Pointe gleich mit: „Das sehe ich von außen, ich brauche dafür keine Zugangsdaten."

Stimmt das? Zum Teil. Wie viel Speicherplatz ein Hostingpaket belegt, verrät ein Webserver normalerweise nicht, HTTP überträgt solche Interna schlicht nicht. Das SSL-Zertifikat dagegen ist öffentlich einsehbar, seine Gültigkeit prüft jeder Browser bei jedem Aufruf. Und die PHP-Version steht, je nach Konfiguration, tatsächlich für jeden lesbar in der Antwort des Servers. Die Anzeige übertreibt im Detail. Ihr Prinzip aber beschreibt sie korrekt: Eine Website erzählt ungefragt von ihrem Alter.

Eine PHP-Installation kann im Auslieferungszustand eine Zeile mitsenden, die für den Betrieb der Website keinen Nutzen hat: den HTTP-Header X-Powered-By, der die genaue PHP-Version im Klartext nennt. Ob er ankommt, hängt von der Konfiguration ab; viele Hosting-Pakete, Reverse Proxys und Content Delivery Networks entfernen ihn inzwischen, andere lassen ihn stehen, weil die zuständige Einstellung expose_php standardmäßig aktiv ist (1) – niemand hat sie böswillig eingeschaltet, sie war nur nie ausgeschaltet. Sicherheitsforscher zählen den Header zu den ersten Dingen, die bei einer Fingerprinting-Analyse geprüft werden, weil er die Auswahl möglicher Angriffe eingrenzt (2).

PHP selbst empfiehlt, die Einstellung abzuschalten, und schränkt im selben Atemzug ein, dass solche Verschleierung zu den schwächsten Formen von Sicherheit gehört. Ein Angriff, der eine bekannte Schwachstelle ausnutzt, funktioniert schließlich auch dann, wenn die Versionsnummer vorher nicht sichtbar war – der Header verkürzt Angreifern lediglich die Zielauswahl. Verstecken ersetzt kein Update. Der Header ist keine Sicherheitslücke. Wenn er gesetzt ist, ist er eine Wegbeschreibung zu einer.

Was diese Wegbeschreibung so brauchbar macht: Ihr Ziel ist öffentlich dokumentiert. PHP-Versionen laufen nach einem festen Rhythmus ab, zwei Jahre aktive Pflege, danach zwei weitere Jahre, in denen ausschließlich Sicherheitslücken geschlossen werden, dann Ende (3). PHP 7.4 erreichte dieses Ende am 28. November 2022; seither erscheint für diesen Zweig vom PHP-Projekt grundsätzlich nichts mehr, gleich wie schwer eine neu gefundene Lücke wiegt. Und der Kalender reicht weiter: PHP 8.2 endet am 31. Dezember 2026, 8.3 Ende 2027, 8.4 Ende 2028, 8.5 Ende 2029. Termine, die feststehen, Jahre bevor sie eintreten.

Wie viel an einem einzigen verpassten Termin hängen kann, zeigte 2024 die Schwachstelle CVE-2024-4577 in der PHP-CGI-Anbindung unter Windows, mit einem CVSS-Wert von 9,8 von 10 als kritisch bewertet (4). Für die damals gepflegten Zweige erschien der Patch binnen weniger Tage. Für einen Zweig, der zu diesem Zeitpunkt als beendet galt, erscheint bei einer vergleichbaren Lücke vom PHP-Projekt keiner mehr.

Das ließe sich als Randerscheinung abtun, beträfe es nur vereinzelte, vergessene Websites. Die Zahlen sprechen dagegen: PHP treibt weiterhin mehr als 70 Prozent aller Websites mit einer erkannten Server-Sprache an, und fast drei von zehn dieser PHP-Installationen entfallen noch immer auf einen 7er-Zweig, der seit Jahren keine Sicherheitsupdates des PHP-Projekts mehr erhält (5). Von einem Ausreißer einzelner Nachlässiger lässt sich da kaum noch sprechen. So wird das Web tatsächlich betrieben.

Was die Anzeige als Vertriebsargument nutzt, unterscheidet sich technisch übrigens nicht von dem, was automatisierte Scanner ohnehin ständig prüfen. Der Unterschied liegt im Ton: Der Scanner meldet sich nicht, die Anzeige schon. Beide lesen nichts, was nicht bereits offenlag.

Der Sicherheitsanbieter Sucuri fand in seiner Auswertung kompromittierter Websites, dass 39 Prozent der betroffenen Content-Management-Systeme zum Infektionszeitpunkt veraltet waren (6). Die Zahl will vorsichtig gelesen werden: Sie stammt aus Sucuris eigenen Kundenumgebungen, keiner repräsentativen Stichprobe, und sie beweist keine Ursache. Sie zeigt aber, wie häufig veraltete Software unter den untersuchten kompromittierten Systemen anzutreffen war – häufig genug, um sie nicht als Einzelfall zu verbuchen.

Das Ende eines Support-Zeitraums ist immer auch ein Auftrag: Die Software muss weiterlaufen, auf einer Version, die sie noch trägt. Dass so viele Websites noch immer auf PHP 7 verharren, hat dabei einen handfesten Grund. Der Sprung auf PHP 8 war ein erheblicher Kompatibilitätsschnitt. Version 8.0 entfernte lange abgekündigte Funktionen, verschärfte den Umgang mit Typvergleichen – ein Vergleich wie 0 == "foo", der zuvor wahr war, ist seither falsch – und ließ Fehlerfälle, die zuvor noch als Warnung durchgingen, nun die Ausführung abbrechen (7). Änderungen, die sauber gepflegten Code kaum berühren, historisch gewachsenen aber sehr wohl. Wer eine Anwendung aus den Zehnerjahren betreibt, deren Entwickler nicht mehr erreichbar ist, konnte nicht einfach umschalten. Das Update der Laufzeit wurde zum Softwareprojekt.

Derselbe Mechanismus wiederholt sich mit jedem Versionssprung, nur unter anderen Namen: mal ein Plugin, das seit Jahren niemand mehr pflegt, mal ein Modul aus einer Agentur, die es nicht mehr gibt, mal schlicht kein Staging-Server, auf dem sich die Umstellung gefahrlos proben ließe. Technisch ist eine PHP-Version in Minuten umgestellt. Ein verantwortbares Update braucht länger: Wissen, was demnächst ausläuft, ob die eigene Anwendung kompatibel ist, wer das testet und wer die Migration verantwortet. Und die Aussicht, dass am Montagmorgen ausgerechnet das Mitgliederportal nicht mehr lädt, wiegt für die meisten schwerer als ein abstraktes Sicherheitsrisiko.

Cloud ist keine Wartungsstrategie. Auch eine Cloud-Umgebung serviert jahrelang denselben veralteten Container, solange niemand seinen Lebenszyklus verwaltet – und umgekehrt kann klassisches Shared-Hosting PHP-Versionen durchaus automatisch migrieren. Worauf es ankommt, ist die Zuständigkeit: Hat jemand diesen einen Punkt übernommen? Ob dahinter eine Cloud oder ein klassischer Server steht, ist dann zweitrangig.

Verfügbarkeit fragt, ob das System heute läuft. Resilienz fragt, ob es in einem Jahr noch sicher läuft. Zwischen beiden Fragen liegt unspektakuläre Arbeit: ein Inventar der eingesetzten Versionen etwa, und ein Testlauf vor dem Termin statt einer Krisensitzung danach. Digitale Infrastruktur wird nicht unsicher, weil ihr Ablaufdatum unbekannt wäre. Sie wird unsicher, weil bekannte Ablaufdaten niemandem gehören.