Für einen Sysadmin der „alten Schule“ wie mich war das fast wie „früher“: bis in die Nacht hinein noch Server patchen. Nur: Man patcht keine Server mehr. Man patcht auch nicht mehr selbst. Es läuft alles automatisiert. Das Einzige, was noch händisch gemacht wurde, ist die Webseiten wieder freizuschalten.
Das funktioniert allerdings nur, wenn die Systeme gewartet und damit auf dem letzten Sicherheitsstand gehalten werden. Darüber hinaus benötigt es ein starkes Team, das schnell reagieren kann.
Hat es STRG.AT auch betroffen?
STRG.AT hat sich 2021 bewusst von PHP verabschiedet. Neue Projekte entstehen seither in modernen Sprachen wie TypeScript und Python bzw. Frameworks wie Vue.js und Nuxt.
Diese Projekte waren von PHP2Shell nicht betroffen. Ältere Projekte, die noch aus der PHP-Zeit stammen, sehr wohl. Hier mussten auch wir gestern schnell reagieren.
So naheliegend es wäre, auf PHP „hinzuhauen“: PHP2Shell ist kein Beweis, dass PHP als Sprache unsicher ist.
Was ist bei PHP2Shell eigentlich passiert?
PHP, eine Skriptsprache, die gerne im Webbereich eingesetzt wird, hat zwei schwerwiegende Sicherheitslücken, die unter dem Namen „PHP2Shell“ zusammengefasst wurden. Diese Lücken erlauben, noch bevor eine Codezeile ausgeführt wird, fremden Code auf den Webservern auszuführen.
Dieser fremde Code kann für „Defacing“, das Ausspionieren von Nutzerdaten bis hin zu Datendiebstahl benutzt werden, oder um die Rechenleistung für ein Botnet zu verwenden. Potenziell kann dies zu einem enormen wirtschaftlichen Schaden führen. Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Patches für die noch aktiv betreuten Versionen und später auch für die älteren Versionen geliefert.
Warum diese mediale Aufregung?
Bei kritischen Lücken ist es gute Praxis, Anbieter und Distributoren vorab zu informieren, bevor der Fehler öffentlich wird. So hat es OpenSSL 2015 vorgemacht: Das Projekt kündigte kritische Updates einige Tage vorher an, ohne Details zu nennen, und gab Distributoren Zeit, gepatchte Pakete vorzubereiten. Zum Zeitpunkt der Veröffentlichung ist also alles vorbereitet, um die „Time-to-Fix“ so gering wie möglich zu halten, und man muss dank der automatisierten Prozesse auch keine Seite offline nehmen.
Auch das PHP-Team hatte diesen Weg gewählt: Distributoren und Anbieter zuerst. Doch geleakte CVE-Nummern, ein versehentlich veröffentlichtes Exploit-Video und ein vorzeitig ausgelieferter Patch eines Anbieters brachten den Zeitplan durcheinander, sodass Betreiber unter Zeitdruck reagieren mussten.
Das führt zu schwierigen Entscheidungen in Unternehmen und Organisationen bei der Risikoeinschätzung: online bleiben und hoffen, dass nichts passiert, oder die Seiten offline nehmen und dabei einen wirtschaftlichen Schaden riskieren.
Ist das ein reines PHP-Problem?
Die zwei Sicherheitslücken sind Fehler im C-Code von PHP, also in manueller Speicherverwaltung, nicht in der Syntax oder dem Konzept von PHP. Solche Fehler können in jeder Laufzeitumgebung, jeder Bibliothek und jedem Framework stecken.
Die letzten Jahre zeigen das deutlich:
Heartbleed (2014): ein Speicherfehler in OpenSSL, der weltweit Server-Speicher auslesbar machte.
Log4Shell (2021): eine Remote-Code-Lücke in der Java-Logging-Bibliothek Log4j, die praktisch jede Branche traf.
Next.js (2025): Eine Lücke in der Middleware erlaubte es, Autorisierungsprüfungen zu umgehen (CVE-2025-29927).
React2Shell (2025): eine kritische Remote-Code-Lücke in den React Server Components (CVE-2025-55182).
Auch moderne Stacks, wie wir sie einsetzen, sind davon nicht ausgenommen. Sicherheit entsteht nicht durch die Wahl der „richtigen“ Sprache. Sie entsteht durch Prozesse: aktuelle Versionen, schnelles Patch-Management, Monitoring der Abhängigkeiten, automatisierte Erneuerungs- und Releaseprozesse. Und ein Team, das im Ernstfall rasch reagieren kann.
Der Blogbeitrag der PHP Foundation stützt dieses Argument: Das eigentliche Problem war nicht die Sprache, sondern ein kleines, unterfinanziertes Team, das an einer Infrastruktur arbeitet, auf der ein Großteil des Webs läuft. Das gilt für viele Open-Source-Projekte, egal in welcher Sprache. Bemerkenswert ist die Offenheit, mit der die Foundation eigene Fehler benennt. Genau so sollte ein Open-Source-Projekt mit einer solchen Lage umgehen.
Fazit
Wer PHP einsetzt, muss heute patchen und nicht morgen. Wer glaubt, eine Software- und Systemwartung sei überflüssig und teuer, wird in diesen Tagen ins Grübeln kommen und sich möglicherweise wünschen, in Wartung investiert zu haben. Und wer glaubt, mit einem anderen Stack vor solchen Lücken sicher zu sein, sollte die nächste Schlagzeile abwarten. Die beste Verteidigung ist ein Team, das seine Systeme kennt und schnell handeln kann.