»Patch erledigt« ist eine Statusmeldung – noch kein Nachweis für einen abgesicherten Geschäftsbetrieb. Die Diskussion um PHP2Shell rückt deshalb mehr als die Laufzeitumgebung in den Blick: Softwarebestand, Dienstleisterverantwortung, Vorfallsprüfung und Wiederherstellung. 14 Experten ordnen die Herausforderungen ein. Für CIOs und Geschäftsführungen steht dabei die Frage im Mittelpunkt: Was ist geprüft, was bleibt offen und wer entscheidet über die nächsten Schritte?

Management Summary

Bestand vor Statusmeldung: Die Statements empfehlen, PHP-Laufzeiten je Dienst, Betriebsumgebung und Betreiber zu erfassen. Unbekannte Versionen und ungeklärte Zuständigkeiten gehören als offene Prüfpositionen ins Reporting.
Updates nachweisen: Eine aktualisierte Anwendung ist nach den zitierten Einschätzungen kein Beleg für eine korrigierte Laufzeit. CIOs sollten dienstbezogene Nachweise der aktiven Version sowie klare Verantwortlichkeiten mit Hostern und Dienstleistern einfordern.
Priorisieren, Ausnahmen verantworten: Exponierte Dienste stehen im Fokus der Empfehlungen; interne Systeme und OT bleiben Teil der Bewertung. Betriebliche Einschränkungen erfordern abgestimmte Übergangsmaßnahmen mit Verantwortlichem und erneutem Prüftermin.
Patch und Vorfall getrennt bewerten: Die Sprecher unterscheiden zwischen technischer Korrektur und der Untersuchung möglicher früherer Eingriffe. Das Management sollte beide Statusangaben sowie Grenzen der verfügbaren Nachweise kennen.
Geschäftsbetrieb im Test belegen: Die Wiederherstellung kritischer Prozesse sollte unter definierten Bedingungen geprüft werden. Entscheidungsrelevant sind dokumentierte Ergebnisse, offene Abhängigkeiten und verbleibende Aufgaben – nicht allein erfolgreiche Backup-Meldungen.

Illustration Absmeier foto ki designer

Bild: Bestandsaufnahme, Prüfung der Laufzeit und Wiederherstellung als symbolische Ebenen der Cyberresilienz. KI-generierte Illustration, keine Darstellung einer konkreten Systemarchitektur.

Ist die Website aktualisiert – oder auch die Laufzeit darunter? An dieser Unterscheidung setzt die Diskussion um PHP2Shell an. Für CIOs und Geschäftsführungen führt sie über den nächsten Update-Auftrag hinaus: Welche Dienste sind betroffen, wer verantwortet ihre Aktualisierung und wie wird deren Umsetzung belegt? Die 14 vorliegenden Expertenstatements beleuchten diese Fragen aus unterschiedlichen Perspektiven. Im Mittelpunkt stehen Softwareabhängigkeiten, Dienstleistersteuerung, betriebliche Grenzen und die Fähigkeit, kritische Geschäftsprozesse nach einem Vorfall wiederherzustellen.

Aktuelles CMS ist noch kein Laufzeitnachweis

Justin Moore, Director of Adversary Operations bei Arctic Wolf, beschreibt die technische Einordnung so: »Diese Schwachstellen sind besonders kritisch, da sie sich direkt in der PHP-Laufzeitumgebung befinden, also unterhalb von Anwendungen wie WordPress, WooCommerce, Magento, Drupal und anderen weit verbreiteten Webplattformen. Eine manipulierte Webanfrage kann eine unsichere Speicherverarbeitung auslösen, noch bevor die anwendungseigenen Authentifizierungs- oder Sicherheitsmechanismen reagieren können. Dadurch könnten Angreifer ohne vorherige Authentifizierung Code mit den Berechtigungen des Webservers ausführen.«

Joe Connolly, Lead of Content Delivery & Security bei bunny.net, richtet den Fokus auf den Betriebsnachweis: »Die gefährliche Annahme ist, dass eine aktualisierte Website automatisch auch eine aktualisierte PHP-Laufzeitumgebung bedeutet. PHP hat gezeigt, dass ein mod_php-Angriff ausgelöst werden kann, bevor der Anwendungscode überhaupt ausgeführt wird. Ein CMS-Update allein kann dieses Problem daher nicht beheben. Betreiber sollten prüfen, welche PHP-Version tatsächlich für jede Website eingesetzt wird, alle exponierten Ursprungsserver patchen und verifizieren, dass die korrigierte Version aktiv läuft.«

Der Prüfauftrag lautet damit nicht nur: Ist die Anwendung aktuell? Sondern: Welche Laufzeit bedient den konkreten Dienst? Für das Management sollte eine pauschale Aktualisierungsmeldung deshalb durch einen dienstbezogenen Nachweis ergänzt werden. Die Verbreitung von PHP allein beantwortet weder die Frage nach der Betroffenheit noch nach einer bereits erfolgten Kompromittierung; die genannten Verbreitungszahlen werden hier nicht als aktuelle Messwerte übernommen.

Wer den Bestand nicht kennt, kann nicht gezielt reagieren

Don Smith, VP Threat Intelligence der Sophos Counter Threat Unit, stellt die Suche nach Installationen vor den eigentlichen Update-Auftrag: »Die unmittelbare Herausforderung besteht nicht einfach darin, einen Patch einzuspielen, sondern jede Instanz zu finden und zu verwalten, auf der PHP läuft. PHP ist allgegenwärtig: Es kann unter öffentlichen Websites, Content-Management-Systemen, Hosting-Plattformen und Produkten von Drittanbietern liegen, manchmal ohne dass es dem Unternehmen, das es nutzt, überhaupt bewusst ist.«

Maxime Thiebaut, Digital Forensics & Incident Response Expert bei NVISO, betont die Abhängigkeiten: »Heute wird erneut deutlich, dass viele Unternehmen immer noch keinen vollständigen Überblick darüber haben, was in ihren Umgebungen läuft. Doch diese Transparenz ist entscheidend, besonders jetzt, wo auch Künstliche Intelligenz ins Spiel kommt. Die Zeitspanne zwischen der Entdeckung einer Schwachstelle und ihrer Ausnutzung durch Angreifer wird immer kürzer. Unternehmen müssen dringend ihre Denkweise ändern. Heutzutage kann man es sich nicht leisten, nicht zu wissen, was in der eigenen Umgebung läuft oder wo die größten technologischen Abhängigkeiten liegen.« Seine Aussage zur zeitlichen Entwicklung bleibt hier eine zugeschriebene Einschätzung, keine unabhängig bestätigte Messreihe.

Felix Kuhlenkamp, Leiter Sicherheit beim Digitalverband Bitkom, formuliert die Bestandsfrage ebenfalls ausdrücklich: »Das gilt besonders für Hoster und IT-Dienstleister, die Systeme für viele Kunden betreiben. Unternehmen sollten zudem prüfen, wo PHP in ihrer IT überall steckt, auch in älteren Versionen, die keine Updates mehr erhalten.« An anderer Stelle ergänzt er: »Viele wissen nicht genau, welche Komponenten in ihrer Software enthalten sind. Ein solcher Überblick ist aber die Voraussetzung, um in solchen Lagen schnell reagieren zu können.«

Für CIOs ergibt sich daraus eine konkrete organisatorische Empfehlung: Softwarebestand, aktive Laufzeit und Betreiberverantwortung je Dienst zusammenführen. Eine Komponentenliste ist der Ausgangspunkt, nicht der Abschluss der Prüfung. Unbekannte Versionen, ausgelagerte Testsysteme und ungeklärte Zuständigkeiten gehören als offene Positionen ins Reporting – statt hinter einem pauschalen Status »geprüft« zu verschwinden.

Updates delegieren, Umsetzung nachweisen

Gunnar Hellekson, Vice President und General Manager Lightwell bei Red Hat, setzt auf nachvollziehbare Softwarequellen: »Die Auswirkungen von Sicherheitslücken in grundlegender Software wie PHP können sich auf ganze Branchen ausweiten. Daher ist es von entscheidender Bedeutung, über eine vertrauenswürdige Softwarequelle zu verfügen, die dabei hilft, dieses Risiko zu bewältigen, und die im Idealfall schnell auf neue Bedrohungen reagiert, sobald diese auftreten.« Die konkrete Empfehlung seines Unternehmens lautet: »Angesichts der potenziellen Auswirkungen dieser Sicherheitslücken empfiehlt Red Hat seinen Kunden, validierte und getestete Patches zu installieren, sobald diese von vertrauenswürdigen Quellen verfügbar sind – auch außerhalb der üblichen Patch-Fenster.«

Olaf Pursche, Leiter der Kompetenzgruppe Sicherheit im eco, verbindet die technische Aufgabe mit der Dienstleistersteuerung: »Für Betreiber zählt jetzt: Patches einspielen, und zwar überall, und prüfen, dass sie tatsächlich wirken. Viele Unternehmen wissen nicht, wo PHP bei ihnen im Hintergrund läuft, etwa in Verwaltungsoberflächen von Routern, Speichersystemen oder Sicherheitsprodukten. Wer IT auslagert, lagert nicht die Verantwortung aus: Unternehmen müssen mit Hostern und Dienstleistern verbindlich klären, wer Updates einspielt und deren Umsetzung bestätigt.«

Geschwindigkeit und betriebliche Sorgfalt sind hier gemeinsam zu organisieren. Ein vorgezogenes Update sollte mit klarer Zuständigkeit, Prüfung der aktiven Laufzeit und angemessenen Funktionstests verbunden werden. Bei extern betriebenen Diensten ist eine Bestätigung je Instanz aussagekräftiger als eine allgemeine Zusicherung des Anbieters. Die im ursprünglichen Material erwähnten Update-Ankündigungen bleiben zeitgebundene Aussagen und werden nicht als aktueller Veröffentlichungsstand übernommen.

Hinter der Firewall endet der Prüfauftrag nicht

Richard Werner, Security Advisor bei TrendAI, beschreibt Übergangsmaßnahmen ausdrücklich als Ergänzung: »Unternehmen sollten jetzt priorisiert ihre aus dem Internet erreichbaren PHP-Installationen umgehend patchen, überprüfen, ob die aktualisierten Laufzeitumgebungen tatsächlich im Einsatz sind, und potenziell kompromittierte Systeme untersuchen. Technologien wie Virtual Patching können ihnen dabei einen entscheidenden Zeitvorteil verschaffen, auch wenn sie keinen vollständigen Ersatz für das Ausrollen von Patches darstellen.« Er fügt hinzu: »Darüber hinaus dürfen aber auch Schwachstellen, die nur aus internen Netzwerken erreichbar sind, nicht vergessen werden!«

Létitia Combes, Geschäftsführerin und Co-Gründerin von BxC Security, betont die betrieblichen Einschränkungen industrieller Umgebungen: »In der OT ist dies jedoch nicht immer ohne Weiteres möglich. Die Abschaltung einzelner Komponenten kann den Produktionsbetrieb beeinträchtigen. Zudem sind Unternehmen bei vielen industriellen Geräten auf Firmware-Updates der Hersteller angewiesen, die möglicherweise erst nach mehreren Wochen verfügbar sind.« Ihr Handlungsvorschlag lautet: »Industrieunternehmen sollten daher zunächst prüfen, welche Systeme betroffen sind, und insbesondere Komponenten an der Schnittstelle zwischen IT und OT absichern. Wo Sicherheitsupdates nicht unmittelbar verfügbar sind, müssen zusätzliche Schutzmaßnahmen greifen. Dazu gehören eingeschränkte Zugriffsrechte, eine konsequente Netzwerksegmentierung sowie die kontinuierliche Überwachung auf verdächtige Aktivitäten.«

Gerade in der Produktion sollte aus Dringlichkeit kein unkoordinierter Eingriff werden. Für industrielle Komponenten empfiehlt sich eine gemeinsame Entscheidung von Betrieb, Sicherheitsverantwortlichen und Hersteller. Übergangsmaßnahmen brauchen einen dokumentierten Zweck, ausgewiesene Restunsicherheiten und einen erneuten Prüftermin. Ihre Einführung ist weder ein Nachweis vollständigen Schutzes noch ein Beleg für die Wirksamkeit eines späteren Updates.

Patch eingespielt – Vorfallsprüfung noch offen

Sebastian Schreiber, Gründer und Geschäftsführer der SySS GmbH, warnt vor einem zu engen Abschlusskriterium: »Das klassische Patchmanagement gerät dadurch massiv unter Druck. Unternehmen müssen Sicherheitsupdates schneller einspielen, dürfen sich aber nicht darauf beschränken. Besonders problematisch sind vergessene Testsysteme, Altanwendungen und Fremdprodukte: Wer nicht weiß, wo verwundbare Software eingesetzt wird, kann sie auch nicht zuverlässig aktualisieren. Ein Patch schließt außerdem nur eine bekannte Schwachstelle, macht eine bereits erfolgte Kompromittierung jedoch nicht rückgängig. Angreifer könnten längst Schadcode eingeschleust, Zugangsdaten gestohlen oder sich von einem kompromittierten Webserver Zugang zu weiteren Systemen verschafft haben. Deshalb müssen Unternehmen nach kritischen Sicherheitsmeldungen auch überprüfen, ob ihre Systeme bereits angegriffen wurden.«

Benny Lakunishok, CEO und Gründer von Zero Networks, richtet den Blick auf mögliche Folgeschritte: »Die eigentliche Gefahr beschränkt sich nicht auf die ursprüngliche Kompromittierung. Es geht vielmehr darum, worauf Angreifer im nächsten Schritt zugreifen können: Datenbanken, Zugangsdaten, interne Anwendungen und letztlich das gesamte Unternehmen.« Sein formuliertes Ziel lautet: »Ziel muss es sein, Angriffe und deren Folgen bestmöglich einzudämmen, und hierfür gibt es durchaus probate Mittel, die ohne KI auskommen.«

Für das Reporting empfiehlt sich deshalb eine klare Trennung: Ist die technische Korrektur umgesetzt, und ist die Vorfallsbewertung abgeschlossen? Eine Untersuchung hat einen definierten Umfang – und Grenzen, etwa bei fehlenden Protokollen. Keine Auffälligkeit im geprüften Material bedeutet keine allgemeine Entwarnung; ein einzelnes Warnsignal ist umgekehrt noch kein Angriffsbeweis. Weitergehende Untersuchungen und Änderungen gehören in die Hände qualifizierter Sicherheits- und Betriebsverantwortlicher.

KI-Prognosen ersetzen keine Risikoprüfung

Ismael Valenzuela, Vice President, Labs, Threat Research and Intelligence bei Arctic Wolf, schränkt die Schlussfolgerung aus der großen Verbreitung von PHP selbst ein: »Das bedeutet zwar nicht, dass all diese Websites tatsächlich betroffen oder angreifbar sind. Es verdeutlicht jedoch, wie weit verbreitet diese Technologie ist und warum Unternehmen schnellstmöglich prüfen müssen, inwieweit ihre Systeme betroffen sind.«

Valenzuela verbindet diese Abgrenzung mit einem breiteren Verständnis des Schwachstellenmanagements: »Wir müssen uns von der Vorstellung verabschieden, dass Schwachstellenmanagement lediglich darin besteht, eine Sicherheitslücke zu identifizieren, ihren Schweregrad zu bewerten und auf einen Patch zu warten. Entscheidend ist vielmehr, wie schnell wir erkennen können, welche Systeme betroffen sind, wie hoch das damit verbundene Risiko ist und wie sich verhindern lässt, dass die Kompromittierung eines einzelnen Systems zu einem weitaus größeren Sicherheitsvorfall führt.« [Inference] Mehrere Sprecher erwarten, dass KI Schwachstellenanalyse und Angriffsentwicklung beschleunigt. Ihre Prognosen beruhen auf den von ihnen beschriebenen beobachteten Mustern; das Verhalten einzelner Modelle wurde für diesen Artikel nicht unabhängig geprüft. Für die Priorisierung bleibt deshalb die konkrete Installation entscheidend: Version, Betriebsart und Erreichbarkeit statt einer pauschalen KI-Prognose. Der zusätzlich erwähnte Zertifizierungsstellen-Vorfall wird nicht vertieft, weil seine Einzelheiten hier nicht unabhängig überprüft wurden.

Cyberresilienz beginnt vor dem Vorfall

Norbert Pohlmann, Vorstand IT-Sicherheit im eco – Verband der Internetwirtschaft e.V., spricht die Ressourcenfrage an: »Außerdem gilt: Open-Source-Software wie PHP ist das Fundament des Internets. Wer wirtschaftlich davon profitiert, sollte ihre Sicherheit als Teil der eigenen Resilienz verstehen und nachhaltig unterstützen. Kritische Software braucht ausreichend Entwickler und verlässliche Ressourcen für Wartung und Sicherheitsprüfung, nicht nur Einzelprojekte.« Damit legt er den Schwerpunkt auf die längerfristige Pflege der eingesetzten Grundlagen statt allein auf die Reaktion auf eine einzelne Meldung.

Mark Molyneux, Field CTO bei Commvault, stellt die Wiederherstellung in den Mittelpunkt: »Entscheidend ist nicht, wie selbstsicher ein Unternehmen behauptet, Angriffe abwehren zu können, sondern wie überzeugend es seine Wiederherstellungsfähigkeit nachweist. Geschützte Backups, klare Wiederherstellungsprioritäten und regelmäßige Tests machen Cyberresilienz zu mehr als einem Versprechen: zu einer nachweisbaren Fähigkeit. Wenn die Prävention versagt, kommt es auf diese Fähigkeit an.«

Unter dem von ihm verwendeten Begriff »ResOps« beschreibt Molyneux ein gemeinsames organisatorisches Ziel: »Die Disziplin bringt Teams aus den Bereichen Sicherheit, Infrastruktur, Business und Betrieb rund um ein gemeinsames Ziel zusammen: das „Minimum Viable Business“ der Organisation zu identifizieren – jene kritischen Systeme, Daten und Prozesse, die für den Geschäftsbetrieb unverzichtbar sind – und sicherzustellen, dass diese Dienste nach einer Störung schnell und sauber betrieben und wiederhergestellt werden können.« Der Begriff wird hier als seine Bezeichnung wiedergegeben, nicht als unabhängig bestätigter Branchenstandard. Ein bestimmtes Produkt oder Organisationsmodell wird daraus nicht als notwendige Lösung abgeleitet.

Fazit: Nachweise statt Entwarnung

Der Management-Auftrag lautet: Nicht nur Updates melden, sondern ihren Einsatz nachweisen. Installationen erfassen, Betroffenheit bewerten, Korrekturen abgestimmt umsetzen und die aktive Laufzeit prüfen. Frühere Eingriffe, Zugriffswege und Wiederherstellungspläne bleiben eigene Prüfaufträge. Für die Geschäftsführung zählen drei Fragen: Welche Dienste sind geprüft – und wo sind die Belege? Welche Risiken bleiben offen – wer verantwortet sie, bis wann? Welche kritischen Geschäftsprozesse wurden im Test wiederhergestellt – unter welchen Bedingungen? Der Maßstab ist nicht »Patch erledigt«, sondern: Was ist nachgewiesen, was bleibt unklar, welche Entscheidung steht an? Auch belastbare Nachweise sind keine Zusicherung vollständigen Schutzes.

Albert Absmeier & KI

Originalstatements: Vollständiges Hintergrundmaterial

Cyberresilienz: Wiederherstellung zählt, nicht das Versprechen

Statement von Mark Molyneux, Field CTO, Commvault

»KI wird helfen, Software sicherer zu gestalten, aber erst mal wird sie die IT-Risikolage erhöhen. Denn die kritischen PHP-Lücken beweisen: KI deckt Fehler in Kerndiensten auf, die Millionen von Systemen weltweit angreifbar machen. Da kann die Abwehrmauer noch so hoch sein. Daher ist es heute wichtiger denn je, sich darauf zu konzentrieren, die Folgen erfolgreicher Attacken einzudämmen. Weitere kritische Lücken sind zu erwarten.

Für die Internetwelt ist es gut und wichtig, dass diese Fehler gefunden wurden, und es sind Patches verfügbar, die diese Lücken schließen. Jedem User ist zu empfehlen, diese kritischen Updates so schnell es geht aufzuspielen. Denn die KI hilft den Aggressoren, Angriffe gegen diese Lücken schnell und qualitativ hochwertig zu entwickeln. Das Sicherheitsrisiko ist dementsprechend hoch.

Angriffsflächen werden größer

Aber dieser Fall beleuchtet ein Kernproblem. Durch die jüngsten Errungenschaften der Frontier AI wird es den Herstellern massiv erleichtert, den digitalen Arm ihrer Produkte auf Schwachstellen hin zu durchleuchten. Ob Claude, Mythos oder MDash von Microsoft: Jeder KI-Pionier hat ein Tool entwickelt – und deren Ergebnisse sind beeindruckend. Hier Zahlen einiger Software-Riesen als Beleg: Microsoft 421, Oracle 1449 und Apple 210 Schwachstellen nebst Patches. Die KI-Modelle wirken sich bereits jetzt auf die Menge der gemeldeten Schwachstellen und Patches aus.

Auf die IT-Teams weltweit kommt viel Arbeit zu. Sie werden bei einer gleichzeitigen Flut von Vorfällen Patches testen, priorisieren und ausrollen müssen. Eine mögliche Konsequenz wird sein, manche Lücken für eine Weile akzeptieren zu müssen, weil andere gravierender sind und es wichtiger ist, diese zuerst zu schließen.

Das Risiko erfolgreicher Attacken ist dadurch erhöht. Dieses Phänomen wird andauern, denn durch KI werden neue Lücken in weltweit millionenfach genutzten Software-Lösungen und Diensten gefunden werden. Angriffsprävention allein wird dem nicht gerecht. Denn Angreifer werden Wege finden, durch Lücken an den Abwehrmauern vorbei in Firmennetze einzudringen.

Kluge Automatismen als Antwort

Die IT-Teams müssen in dieser KI-getriebenen Welt akzeptieren, dass ihre Abwehr versagt und sie erfolgreich angegriffen werden. Sie müssen sich auf diese Situation vorbereiten. Es wird essenziell sein, diesen Automatismen ebenfalls Workflows gegenüberzustellen, welche die Folgen einer erfolgreichen Attacke eindämmen und die IT-Systeme strukturiert wiederherstellen.

Diese Prozesse für mehr Cyberresilienz heißen ResOps. Diese organisatorische Disziplin verankert Resilienz fest in den täglichen operativen Betrieb. Sie führt Organisationen weg von passiven, reaktiven Backup-Strategien hin zu einem aktiven, kontinuierlichen Modell. ResOps folgt dabei einer zentralen Frage: Können die Teams jeden kritischen Dienst genau jetzt wiederherstellen – mit voller Gewissheit und nachweislich?

Die Disziplin bringt Teams aus den Bereichen Sicherheit, Infrastruktur, Business und Betrieb rund um ein gemeinsames Ziel zusammen: das „Minimum Viable Business“ der Organisation zu identifizieren – jene kritischen Systeme, Daten und Prozesse, die für den Geschäftsbetrieb unverzichtbar sind – und sicherzustellen, dass diese Dienste nach einer Störung schnell und sauber betrieben und wiederhergestellt werden können.

Die KI wird auch im guten Sinne diese Abläufe automatisieren helfen und so das Gleichgewicht zu den Angriffsfähigkeiten wiederherstellen. Allerdings sollten sich die IT-Verantwortlichen auf diese ResOps-Strategie einlassen. Eine rein defensive Strategie ist für sich genommen keine tragfähige Option mehr und hat sich – vielfach und öffentlich – als fehleranfällig erwiesen; ResOps, die Hand in Hand mit einer starken Verteidigung agieren, sind der Schlüssel für den künftigen Erfolg des Geschäftsbetriebs.

Entscheidend ist nicht, wie selbstsicher ein Unternehmen behauptet, Angriffe abwehren zu können, sondern wie überzeugend es seine Wiederherstellungsfähigkeit nachweist. Geschützte Backups, klare Wiederherstellungsprioritäten und regelmäßige Tests machen Cyberresilienz zu mehr als einem Versprechen: zu einer nachweisbaren Fähigkeit. Wenn die Prävention versagt, kommt es auf diese Fähigkeit an.

Aktuelles CMS, verwundbare Laufzeit

Expertenkommentar von Joe Connolly, Lead of Content Delivery & Security bei bunny.net

»Die gefährliche Annahme ist, dass eine aktualisierte Website automatisch auch eine aktualisierte PHP-Laufzeitumgebung bedeutet. PHP hat gezeigt, dass ein mod_php-Angriff ausgelöst werden kann, bevor der Anwendungscode überhaupt ausgeführt wird. Ein CMS-Update allein kann dieses Problem daher nicht beheben. Betreiber sollten prüfen, welche PHP-Version tatsächlich für jede Website eingesetzt wird, alle exponierten Ursprungsserver patchen und verifizieren, dass die korrigierte Version aktiv läuft. Eine WAF kann während der Einführung der Updates helfen, die Angriffsfläche gegenüber bekannten Angriffsmustern zu reduzieren. Die Aktualisierung von PHP selbst beseitigt jedoch die zugrunde liegenden Sicherheitslücken.«

Ein kompromittierter Server darf nicht das ganze Unternehmen treffen

Benny Lakunishok, CEO und Gründer von Zero Networks erklärt:

»Dies ist ein potenziell schwerwiegender Sicherheitsvorfall, da PHP tief in der Infrastruktur des Internets verankert ist. Es geht um Schwachstellen, die es Angreifern ermöglichen könnten, die Kontrolle über betroffene Server zu erlangen – ganz ohne Passwort. In den kommenden 48 Stunden dürfte ein Wettlauf zwischen Organisationen, die Patches einspielen, und Angreifern, die versuchen, weiterhin anfällige Systeme auszunutzen, entbrennen. Künstliche Intelligenz könnte diesen Wettlauf noch beschleunigen, indem sie Angreifer dabei unterstützt, Exploits zu entwickeln und in großem Maßstab einzusetzen.

Die eigentliche Gefahr beschränkt sich nicht auf die ursprüngliche Kompromittierung. Es geht vielmehr darum, worauf Angreifer im nächsten Schritt zugreifen können: Datenbanken, Zugangsdaten, interne Anwendungen und letztlich das gesamte Unternehmen.

Es ist noch nie jemandem gelungen, Angreifer allein durch das Einspielen von Patches dauerhaft in Schach zu halten. Wir müssen aufhören, die Fehlerbehebung als alleinige Lösung zu betrachten, und stattdessen auf kompensierende Maßnahmen setzen: Zwar müssen Schwachstellen gepatcht werden, doch gleichzeitig sind Kontrollmechanismen erforderlich, die verhindern, dass ein einzelner kompromittierter Server zu einer Katastrophe für das gesamte Unternehmen führt. Ziel muss es sein, Angriffe und deren Folgen bestmöglich einzudämmen, und hierfür gibt es durchaus probate Mittel, die ohne KI auskommen.«

Kritische Updates gehören nicht in die Warteschleife

Gunnar Hellekson, Vice President und General Manager Lightwell, Red Hat:

»Ein Großteil der kritischen Software, die die Welt am Laufen hält, ist zugleich am wenigsten sichtbar. Stabiler Produktionscode, ‚der einfach funktioniert‘, ist aufgrund der hohen Geschwindigkeit und des großen Umfangs neuer Schwachstellen, die durch KI-gestützte Erkennung aufgedeckt werden, mittlerweile gefährdet. Die Probleme, mit denen PHP zu kämpfen hat, verdeutlichen, wie stark Open-Source-Software in die Systeme integriert ist, die das globale Geschäftsleben am Laufen halten.

Die Auswirkungen von Sicherheitslücken in grundlegender Software wie PHP können sich auf ganze Branchen ausweiten. Daher ist es von entscheidender Bedeutung, über eine vertrauenswürdige Softwarequelle zu verfügen, die dabei hilft, dieses Risiko zu bewältigen, und die im Idealfall schnell auf neue Bedrohungen reagiert, sobald diese auftreten.

Angesichts der potenziellen Auswirkungen dieser Sicherheitslücken empfiehlt Red Hat seinen Kunden, validierte und getestete Patches zu installieren, sobald diese von vertrauenswürdigen Quellen verfügbar sind – auch außerhalb der üblichen Patch-Fenster.«

Restrisiken hinterfragen, Angriffsketten prüfen

Sebastian Schreiber, Gründer und Geschäftsführer der SySS GmbH, über die kritischen PHP-Sicherheitslücken und die veränderte Bedrohungslage durch KI.

»PHP2Shell zeigt, dass Unternehmen ihre bisherige Risikokalkulation überdenken müssen. Die kritischen PHP-Sicherheitslücken blieben jahrelang unentdeckt, bis sie mithilfe künstlicher Intelligenz aufgespürt wurden. Dass sogar staatliche Webangebote in mehreren europäischen Ländern vorsorglich vom Netz genommen wurden, verdeutlicht die Tragweite solcher Sicherheitslücken. Der Fall zeigt zugleich, dass selbst seit vielen Jahren eingesetzter und vermeintlich bewährter Programmcode nicht zwangsläufig ausreichend auf Sicherheitslücken untersucht wurde. Nun haben Angreifer mit KI aus den veröffentlichten Sicherheitsupdates innerhalb kürzester Zeit funktionierende Exploits abgeleitet. Das Zeitfenster, in dem Unternehmen reagieren können, wird damit immer kleiner.

Noch gravierender ist, dass KI die Wirtschaftlichkeit von Cyberangriffen verändert. Bislang haben Unternehmen bestimmte Restrisiken oftmals akzeptiert, weil die Suche nach schwer auffindbaren Schwachstellen für gewöhnliche Cyberkriminelle zu aufwändig und teuer erschien. Diese Rechnung geht aber nicht mehr auf. KI automatisiert aufwändige Analysen und senkt die Kosten. KI-gestützte Tools unterstützen zudem auch Angreifer ohne tiefgreifende technische Kenntnisse dabei, Exploits zu entwickeln, anzupassen und gegen zahlreiche Ziele einzusetzen. Was gestern noch als unwahrscheinlicher Angriff galt, kann heute bereits wirtschaftlich attraktiv sein.

Das klassische Patchmanagement gerät dadurch massiv unter Druck. Unternehmen müssen Sicherheitsupdates schneller einspielen, dürfen sich aber nicht darauf beschränken. Besonders problematisch sind vergessene Testsysteme, Altanwendungen und Fremdprodukte: Wer nicht weiß, wo verwundbare Software eingesetzt wird, kann sie auch nicht zuverlässig aktualisieren. Ein Patch schließt außerdem nur eine bekannte Schwachstelle, macht eine bereits erfolgte Kompromittierung jedoch nicht rückgängig. Angreifer könnten längst Schadcode eingeschleust, Zugangsdaten gestohlen oder sich von einem kompromittierten Webserver Zugang zu weiteren Systemen verschafft haben. Deshalb müssen Unternehmen nach kritischen Sicherheitsmeldungen auch überprüfen, ob ihre Systeme bereits angegriffen wurden.

Gleichzeitig reicht es nicht, sich auf Firewalls und Schwachstellenscanner zu verlassen. Diese erkennen nicht zwangsläufig komplexe Angriffsketten. Unternehmen müssen ihre IT deshalb kontinuierlich aus der Angreiferperspektive überprüfen lassen. Gezielte Penetrationstests zeigen, welche Schwachstellen tatsächlich ausnutzbar sind, wie sie sich kombinieren lassen und wie weit ein Angreifer vordringen könnte. KI-gestützte Verfahren beschleunigen und skalieren diese Prüfungen, während erfahrene Sicherheitsexperten die Ergebnisse bewerten und Gegenmaßnahmen priorisieren.

PHP2Shell ist deshalb mehr als eine weitere kritische Sicherheitslücke. Der Fall zeigt, dass der bisherige Sicherheitsabstand zwischen Angreifern und Verteidigern durch KI extrem schrumpft. Unternehmen müssen nicht nur schneller patchen, sondern ihre tatsächliche Angreifbarkeit auch mit KI kontinuierlich überprüfen und mögliche Kompromittierungen frühzeitig erkennen. Denn wenn KI bislang unwirtschaftliche Angriffe rentabel macht, ist die vermeintliche Unwahrscheinlichkeit eines Angriffs kein verlässliches Sicherheitsargument mehr.«

Hinter der Firewall ist das Patchen nicht zu Ende

Richard Werner, Security Advisor bei TrendAI, warnt davor, interne Systeme zu vernachlässigen.

»Unternehmen sollten jetzt priorisiert ihre aus dem Internet erreichbaren PHP-Installationen umgehend patchen, überprüfen, ob die aktualisierten Laufzeitumgebungen tatsächlich im Einsatz sind, und potenziell kompromittierte Systeme untersuchen. Technologien wie Virtual Patching können ihnen dabei einen entscheidenden Zeitvorteil verschaffen, auch wenn sie keinen vollständigen Ersatz für das Ausrollen von Patches darstellen.

Darüber hinaus dürfen aber auch Schwachstellen, die nur aus internen Netzwerken erreichbar sind, nicht vergessen werden! Die Erfahrung zeigt, dass solche Lücken in internen Systemen oft monatelang bestehen. Gelingt es Cyberangreifern dann, in das Netzwerk einzudringen – beispielsweise über Phishing – und sich darin lateral weiterzubewegen, können sie diese Lücken nutzen, beispielsweise um Serversysteme zu übernehmen. Auch hier gilt: Wer nicht sofort patchen kann, sollte zumindest mit virtuellen Patches einen vorübergehenden Workaround bereitstellen und das Risiko mit einer Cyberrisikomanagement-Lösung überwachen.«

OT-Sicherheit: Schutzmaßnahmen mit der Produktion abstimmen

Was Industrieunternehmen jetzt tun sollten und warum es keine schnellen Lösungen gibt, erklärt Létitia Combes, Geschäftsführerin und Co-Gründerin von BxC Security

»Die beiden kritischen PHP-Sicherheitslücken stellen nicht nur für klassische IT-Systeme, sondern auch für industrielle Produktionsumgebungen ein erhebliches Risiko dar. Denn PHP kommt auch in der Operational Technology (OT) zum Einsatz, etwa in Managementoberflächen von Firewalls, industriellen Steuerungen, Fernwartungsportalen oder Monitoring-Systemen.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt, betroffene Systeme schnellstmöglich zu aktualisieren oder gegebenenfalls vorübergehend vom Netz zu nehmen. In der OT ist dies jedoch nicht immer ohne Weiteres möglich. Die Abschaltung einzelner Komponenten kann den Produktionsbetrieb beeinträchtigen. Zudem sind Unternehmen bei vielen industriellen Geräten auf Firmware-Updates der Hersteller angewiesen, die möglicherweise erst nach mehreren Wochen verfügbar sind.

Industrieunternehmen sollten daher zunächst prüfen, welche Systeme betroffen sind, und insbesondere Komponenten an der Schnittstelle zwischen IT und OT absichern. Wo Sicherheitsupdates nicht unmittelbar verfügbar sind, müssen zusätzliche Schutzmaßnahmen greifen. Dazu gehören eingeschränkte Zugriffsrechte, eine konsequente Netzwerksegmentierung sowie die kontinuierliche Überwachung auf verdächtige Aktivitäten.«

Open Source nutzen heißt Wartung mittragen

Norbert Pohlmann, Vorstand IT-Sicherheit im eco – Verband der Internetwirtschaft e.V.:

»PHP2Shell ist mehr als ein weiterer Patch-Day. Wenn ein Baustein, der hinter einem Großteil aller Websites steckt, eine kritische Lücke hat, wackelt ein Teil der digitalen Infrastruktur. KI hilft heute nicht nur Verteidigern beim Finden von Schwachstellen. Sie ermöglicht Angreifern auch, aus Updates in kürzester Zeit funktionierende Exploits zu bauen. Das Zeitfenster zwischen Patch und erstem Angriff schrumpft. Hersteller, Hoster und Betreiber brauchen deshalb belastbare Schwachstellenprozesse und eine koordinierte Offenlegung, die auf dieses Tempo ausgelegt ist. Außerdem gilt: Open-Source-Software wie PHP ist das Fundament des Internets. Wer wirtschaftlich davon profitiert, sollte ihre Sicherheit als Teil der eigenen Resilienz verstehen und nachhaltig unterstützen. Kritische Software braucht ausreichend Entwickler und verlässliche Ressourcen für Wartung und Sicherheitsprüfung, nicht nur Einzelprojekte.«

IT auslagern, Sicherheitsverantwortung behalten

Olaf Pursche, Leiter der Kompetenzgruppe Sicherheit im eco:

»Für Betreiber zählt jetzt: Patches einspielen, und zwar überall, und prüfen, dass sie tatsächlich wirken. Viele Unternehmen wissen nicht, wo PHP bei ihnen im Hintergrund läuft, etwa in Verwaltungsoberflächen von Routern, Speichersystemen oder Sicherheitsprodukten. Wer IT auslagert, lagert nicht die Verantwortung aus: Unternehmen müssen mit Hostern und Dienstleistern verbindlich klären, wer Updates einspielt und deren Umsetzung bestätigt. Der Fall zeigt auch, warum klassische Prävention allein nicht mehr genügt. Wenn Angriffe mit KI immer schneller werden, ist Cyberresilienz entscheidend: Angriffe früh erkennen, Auswirkungen begrenzen und den Betrieb schnell wiederherstellen. Dazu gehört auch, nach dem Patch zu prüfen, ob Systeme bereits kompromittiert wurden.«

PHP2Shell: Das Risiko steckt im Fundament

Justin Moore, Director of Adversary Operations bei Arctic Wolf

»Diese Schwachstellen sind besonders kritisch, da sie sich direkt in der PHP-Laufzeitumgebung befinden, also unterhalb von Anwendungen wie WordPress, WooCommerce, Magento, Drupal und anderen weit verbreiteten Webplattformen. Eine manipulierte Webanfrage kann eine unsichere Speicherverarbeitung auslösen, noch bevor die anwendungseigenen Authentifizierungs- oder Sicherheitsmechanismen reagieren können. Dadurch könnten Angreifer ohne vorherige Authentifizierung Code mit den Berechtigungen des Webservers ausführen.

Die potenzielle Reichweite ist enorm: Laut W3Techs kommt PHP auf rund 69 Prozent aller Websites zum Einsatz, bei denen die serverseitige Programmiersprache bekannt ist. Allein WooCommerce wird von etwa 7,8 Prozent aller Websites und 47 Prozent der von W3Techs erfassten E-Commerce-Systeme genutzt. Damit geht das Risiko weit über einzelne Websites hinaus. Vielmehr handelt es sich um eine potenziell erhebliche Bedrohung für Unternehmen, den Einzelhandel und die Internetinfrastruktur, die eine umgehende Installation von Sicherheitsupdates und eine sorgfältige Untersuchung erfordert.«

Digitale Abhängigkeiten brauchen überprüftes Vertrauen

Ismael Valenzuela, Vice President, Labs, Threat Research and Intelligence bei Arctic Wolf

»Eine der wichtigsten Erkenntnisse aus PHP2Shell ist, dass KI unsere Vorstellung davon verändert, welche Schwachstellen sich tatsächlich ausnutzen lassen. Einige dieser Schwachstellen existierten bereits seit mehr als einem Jahrzehnt. Verändert hat sich nicht der zugrunde liegende Code, sondern die Fähigkeit, diese Schwachstellen aufzuspüren und daraus funktionsfähige Exploits zu entwickeln.

Die potenziellen Auswirkungen sind enorm. PHP kommt auf rund 70 Prozent aller Websites zum Einsatz, bei denen die serverseitige Programmiersprache bekannt ist. Damit ist ein erheblicher Teil der geschäftlichen und kommerziellen Infrastruktur des Internets potenziell gefährdet, was sofortiges Handeln erfordert. Das bedeutet zwar nicht, dass all diese Websites tatsächlich betroffen oder angreifbar sind. Es verdeutlicht jedoch, wie weit verbreitet diese Technologie ist und warum Unternehmen schnellstmöglich prüfen müssen, inwieweit ihre Systeme betroffen sind.

KI macht anspruchsvolle Sicherheitsforschung für einen größeren Personenkreis zugänglich. Das ist eine gute Nachricht für die Verteidigerseite. Allerdings müssen wir davon ausgehen, dass auch Angreifer von diesen Möglichkeiten profitieren werden. Wir müssen uns von der Vorstellung verabschieden, dass Schwachstellenmanagement lediglich darin besteht, eine Sicherheitslücke zu identifizieren, ihren Schweregrad zu bewerten und auf einen Patch zu warten. Entscheidend ist vielmehr, wie schnell wir erkennen können, welche Systeme betroffen sind, wie hoch das damit verbundene Risiko ist und wie sich verhindern lässt, dass die Kompromittierung eines einzelnen Systems zu einem weitaus größeren Sicherheitsvorfall führt.

Während sich derzeit die Aufmerksamkeit auf PHP2Shell richtet, wäre es ein Fehler, einen weiteren alarmierenden Sicherheitsvorfall zu übersehen: den jüngsten Vorfall bei einer Zertifizierungsstelle, bei dem einer der privaten Schlüssel tatsächlich nur aus der Zahl „4“ bestand. Dabei sprechen wir von einer Infrastruktur, die für die Herstellung von Vertrauen im gesamten Internet verantwortlich ist. Gelingt es Angreifern, den privaten Schlüssel einer Zertifizierungsstelle zu erlangen oder zu reproduzieren, könnten sie gefälschte Zertifikate ausstellen, sich als vertrauenswürdige Websites oder Dienste ausgeben und unter bestimmten Umständen verschlüsselten Datenverkehr abfangen. Selbst wenn die Möglichkeiten zur Ausnutzung begrenzt sind, wirft dies ernsthafte Fragen darüber auf, welchen Systemen und Verbindungen weiterhin vertraut werden kann.

Im nächsten Schritt müssen Sicherheitsverantwortliche sämtliche Abhängigkeiten von der betroffenen Zertifizierungsstelle identifizieren, eine Bestandsaufnahme der Zertifikate und Vertrauensspeicher durchführen und prüfen, ob ausgestellte Zertifikate für kritische Dienste verwendet werden. Zudem müssen sie darauf vorbereitet sein, diese Zertifikate bei Bedarf zu widerrufen und zu ersetzen. Wir müssen die Vertrauenswürdigkeit der Dienste und Systeme, auf die wir uns verlassen, kontinuierlich überprüfen und sicherstellen, dass unsere Sicherheitsmaßnahmen auch dann wirksam bleiben, wenn dieses Vertrauen erschüttert wird.«

Was im Softwarebestand fehlt, fehlt in der Risikobewertung

Statement zur aktuellen PHP-Sicherheitslücke – Von Maxime Thiebaut, Digital Forensics & Incident Response Expert beim europäischer Cybersicherheitsspezialisten NVISO

»Die PHP-Sicherheitslücke macht deutlich, wie wichtig es für Unternehmen ist, Schwachstellen schnell zu erkennen, zu wissen, wo sie liegen, und zu verstehen, wie man darauf reagiert. Das haben wir auch schon vor ein paar Jahren bei den Log4Shell- und React2Shell-Schwachstellen gesehen, die erhebliche Auswirkungen hatten.

Heute wird erneut deutlich, dass viele Unternehmen immer noch keinen vollständigen Überblick darüber haben, was in ihren Umgebungen läuft. Doch diese Transparenz ist entscheidend, besonders jetzt, wo auch Künstliche Intelligenz ins Spiel kommt. Die Zeitspanne zwischen der Entdeckung einer Schwachstelle und ihrer Ausnutzung durch Angreifer wird immer kürzer. Unternehmen müssen dringend ihre Denkweise ändern. Heutzutage kann man es sich nicht leisten, nicht zu wissen, was in der eigenen Umgebung läuft oder wo die größten technologischen Abhängigkeiten liegen.

Deshalb sollte jedes Unternehmen die folgenden drei Dinge umgesetzt haben: Erstens ein Vulnerability Management Programme: Welche Software läuft, wo läuft sie und welche Version wird verwendet? Zweitens ein External Attack Software Management: Wie sieht die Organisation von außen aus? Welche Legacy-Systeme werden vielleicht übersehen? Drittens eine Software Bill of Materials: Haben wir eine Bestandsaufnahme aller Software und all ihrer internen Komponenten?

Unternehmen nutzen oft Software, von der sie nichts wissen, auch durch indirekte Abhängigkeiten. Der heutige Tag erinnert daran, dass es hier keine Kompromisse geben kann: Sie müssen hier jederzeit den Überblick behalten.«

Der erste Auftrag: Jede PHP-Instanz aufspüren

Statement von Don Smith, VP Threat Intelligence, Sophos Counter Threat Unit

»Die unmittelbare Herausforderung besteht nicht einfach darin, einen Patch einzuspielen, sondern jede Instanz zu finden und zu verwalten, auf der PHP läuft. PHP ist allgegenwärtig: Es kann unter öffentlichen Websites, Content-Management-Systemen, Hosting-Plattformen und Produkten von Drittanbietern liegen, manchmal ohne dass es dem Unternehmen, das es nutzt, überhaupt bewusst ist.

Sicherheitsteams sollten Systeme priorisieren, die aus dem Internet erreichbar sind, prüfen, welche Versionen betroffen sind, sobald der offizielle Sicherheitshinweis veröffentlicht ist, und die Updates unverzüglich einspielen. Im Einklang mit der Empfehlung des NCSC sollten anfällige Systeme, die sich nicht patchen lassen, vom Internet getrennt werden, bis sie abgesichert sind.

Angreifer handeln schnell, besonders mit Unterstützung von KI. Diese Schwachstelle dürfte in den kommenden Stunden und Tagen ein vorrangiges Ziel für sie sein. Deshalb ist es entscheidend, dass Unternehmen PHP- und Webserver-Prozesse auf ungewöhnliche Prozesse, Befehlsausführungen oder andere Anzeichen überwachen, dass ein Angreifer bereits Fuß gefasst haben könnte.«

Komponenten kennen, im Ernstfall schneller handeln

Felix Kuhlenkamp, Leiter Sicherheit beim Digitalverband Bitkom:

»In der Programmiersprache PHP sind zwei kritische Sicherheitslücken bekannt geworden, über die Angreifer aus der Ferne Schadcode auf Webservern ausführen könnten. Diese Sicherheitslücken sind sehr ernst, denn PHP läuft auf einem großen Teil der Webserver weltweit, von Online-Shops über Unternehmenswebsites bis zu Portalen der Verwaltung. Wer Online-Anwendungen betreibt, sollte daher unbedingt prüfen, ob diese PHP verwenden und in diesem Fall die in Kürze zur Verfügung stehenden Sicherheitsupdates ohne Verzögerung einspielen. Das gilt besonders für Hoster und IT-Dienstleister, die Systeme für viele Kunden betreiben. Unternehmen sollten zudem prüfen, wo PHP in ihrer IT überall steckt, auch in älteren Versionen, die keine Updates mehr erhalten.

Viele wissen nicht genau, welche Komponenten in ihrer Software enthalten sind. Ein solcher Überblick ist aber die Voraussetzung, um in solchen Lagen schnell reagieren zu können. Wie schnell Kriminelle solche Lücken ausnutzen, hat das Jahr 2021 gezeigt. Damals wurden Schwachstellen im weit verbreiteten E-Mail-Server Microsoft Exchange bekannt, und gegen Jahresende die Lücke Log4Shell in einem Software-Baustein, der in unzähligen Anwendungen steckte. In beiden Fällen suchten Kriminelle binnen Stunden weltweit nach verwundbaren Systemen. Heute dürfte das Auffinden von verwundbaren Systemen mit Hilfe von KI noch um ein Vielfaches schneller gehen.«

Ausführliche Tipps mit Praxisbeispielen

Die folgenden Ausführungen konkretisieren die acht Handlungsempfehlungen. Sämtliche Praxisbeispiele sind fiktive, illustrative Szenarien, keine recherchierten Unternehmensfälle und keine Aussagen über die Systeme eines bestimmten Unternehmens. Die vorgeschlagenen Nachweise und Abläufe sind an die eigene Architektur, Betriebsanforderungen und Herstellerfreigaben anzupassen. Änderungen an produktiven oder industriellen Systemen sind mit den zuständigen Verantwortlichen abzustimmen.

1. Bestand erfassen: Vom Softwareverzeichnis zur Dienstlandkarte

Umsetzung: Erstellen Sie für jeden relevanten Dienst einen Datensatz mit Anwendung, Betriebsumgebung, tatsächlicher PHP-Laufzeit, Paketquelle, Erreichbarkeit, zuständigem Betreiber und geschäftlicher Bedeutung. Beziehen Sie Produktiv-, Test- und Ausweichumgebungen sowie Container und eingebettete Komponenten ein. Gleichen Sie die Angaben mit Deployment-Unterlagen, Hosting-Verträgen und Herstellerinformationen ab. Unbekannte Versionen oder Zuständigkeiten sollten als offene Prüfaufträge erscheinen, nicht als unkritische Systeme. Die vorhandenen Tipps verweisen für eingebettete Laufzeiten auf [2].
Fiktives Praxisbeispiel: Ein Handelsunternehmen führt zunächst nur seinen Onlineshop als PHP-Anwendung. Bei der abgestimmten Bestandsaufnahme kommen ein älteres Reklamationsportal und eine beim Dienstleister betriebene Testinstanz hinzu. Für jedes System wird ein Verantwortlicher benannt; die unbekannte Laufzeit der Testinstanz bleibt bis zur Bestätigung als offene Position in der Liste.
Nachweis für das Management: Eine dienstbezogene Bestandsliste mit Datum der letzten Prüfung, geklärten Zuständigkeiten und gesondert ausgewiesenen Informationslücken. Vollständigkeit sollte nicht behauptet werden, solange relevante Umgebungen ungeprüft sind.

2. Patches priorisieren: Technisches Risiko mit Geschäftswirkung verbinden

Umsetzung: Führen Sie Sicherheits- und Betriebsverantwortliche für eine gemeinsame Priorisierung zusammen. Bewerten Sie bestätigte Betroffenheit, externe Erreichbarkeit, mögliche Folgesysteme, Hinweise auf Angriffe und die Bedeutung des Dienstes. Legen Sie für Änderungen eine verantwortliche Person, erforderliche Funktionstests und ein betrieblich abgestimmtes Vorgehen bei Problemen fest. Ein Aufschub braucht eine dokumentierte Begründung, Übergangsmaßnahmen und einen erneuten Entscheidungstermin; er sollte nicht ohne Nachverfolgung ins nächste reguläre Wartungsfenster wandern. Der bestehende Quellenbezug für die priorisierte Reaktion ist [1].
Fiktives Praxisbeispiel: Ein Hersteller muss ein öffentliches Kundenportal und ein internes Archivsystem prüfen. Die bestätigte Betroffenheit des Portals führt zu einer vorgezogenen, abgestimmten Aktualisierung. Beim Archiv fehlt zunächst die Herstellerbestätigung. Das Team dokumentiert diese Unsicherheit, prüft zulässige Zugangsbeschränkungen und verfolgt die Herstellerantwort als eigenen Auftrag.
Nachweis für das Management: Eine priorisierte Maßnahmenliste mit Begründung, Umsetzungsstatus und freigegebenen Ausnahmen. Ein hoher Bearbeitungsstand allein sagt noch nichts über verbleibende geschäftskritische Risiken aus.

3. Wirksamkeit prüfen: Installiert ist nicht gleich aktiv

Umsetzung: Prüfen Sie aus der tatsächlich genutzten Betriebsumgebung heraus, welcher PHP-Prozess den jeweiligen Dienst bedient und aus welcher korrigierten Paket- oder Image-Version er stammt. Eine Prüfung der Kommandozeileninstallation sollte nicht stellvertretend für sämtliche Webdienste gelten. Berücksichtigen Sie mehrere Laufzeiten auf einem Host, getrennte Anwendungspools und noch aktive ältere Container. Bewerten Sie Backports anhand des einschlägigen Herstellerhinweises. Sensible Diagnoseinformationen gehören in kontrollierte interne Prüfverfahren, nicht in öffentlich erreichbare Informationsseiten. Der vorhandene Tipp verweist hierzu auf [2].
Fiktives Praxisbeispiel: Ein IT-Team aktualisiert das Standardpaket eines Servers. Die anschließende dienstbezogene Prüfung zeigt, dass das Kundenportal weiterhin einen separat verwalteten Anwendungspool nutzt. Dieser wird im abgestimmten Änderungsverfahren ebenfalls aktualisiert; danach werden aktive Laufzeit und zentrale Anwendungsfunktionen erneut geprüft.
Nachweis für das Management: Je Dienst ein Prüfprotokoll mit Paketquelle, Korrekturbezug, aktiver Laufzeit, Prüfzeitpunkt und Ergebnis des Funktionstests. Der Status »erledigt« sollte auf diesem Nachweis beruhen, nicht allein auf einem erfolgreichen Installationsauftrag.

4. Dienstleister steuern: Verantwortung und Beleg konkret vereinbaren

Umsetzung: Fordern Sie eine dienstbezogene Auskunft statt einer pauschalen Aussage wie »unsere Plattform ist aktuell«. Die Rückmeldung sollte betroffene Instanzen, eingesetzte Laufzeiten, Herstellerkorrekturen, Aktivierung der Änderungen und verbleibende Ausnahmen nennen. Klären Sie auch Produktiv-, Test- und Wiederherstellungsumgebungen. Halten Sie fest, wer Anwendungstests durchführt, wer die Hosting-Laufzeit verantwortet und wie im Verdachtsfall Protokolle bereitgestellt werden. Die Unterscheidung zwischen Anwendungs- und Laufzeitupdate ist bereits mit [2][3] belegt.
Fiktives Praxisbeispiel: Eine Unternehmenswebsite wird von einer Agentur betreut, das Hosting übernimmt ein weiterer Anbieter. Die Agentur bestätigt ein CMS-Update, kann aber die PHP-Laufzeit nicht nachweisen. Das Unternehmen fordert deshalb die Bestätigung vom Plattformbetreiber an und koordiniert anschließend mit der Agentur den Funktionstest der Website.
Nachweis für das Management: Eine klare Zuständigkeitsübersicht und eine schriftliche Bestätigung pro relevantem Dienst. Nicht beantwortete Anfragen bleiben als offene Abhängigkeiten sichtbar; eine Vertragsbeziehung allein ist kein Umsetzungsnachweis.

5. Übergangsmaßnahmen begrenzen: Zeit gewinnen, Ausnahmen nachverfolgen

Umsetzung: Kann ein betroffenes System noch nicht aktualisiert werden, dokumentieren Sie eine befristete Ausnahme mit Risiko, Verantwortlichem, zulässigen Übergangsmaßnahmen und Prüftermin. Bewerten Sie im zuständigen Team, ob eine zeitweilige Isolation, enger begrenzte Zugangswege oder geeignete Filter betrieblich vertretbar sind. Prüfen Sie auch notwendige Kunden- und Wartungszugriffe, damit die Maßnahme nicht unbeabsichtigt kritische Abläufe unterbricht. Bei Firmware und OT-Komponenten sind Herstellerfreigaben und Produktionsanforderungen einzubeziehen. Die bestehenden Quellenbezüge für solche Übergangsmaßnahmen sind [1][6].
Fiktives Praxisbeispiel: Für eine Management-Appliance liegt noch keine freigegebene Firmware vor. IT, Produktion und Hersteller stimmen eine zeitweise Beschränkung des Verwaltungszugangs ab. Die Fernwartung wird auf den vereinbarten Zugang umgestellt. Die Ausnahme erhält einen festen Überprüfungstermin und bleibt bis zum nachgewiesenen Update offen.
Nachweis für das Management: Ein Ausnahmeregister mit Umfang, Freigabe, Funktionsprüfung, Restunsicherheit und geplantem Ablösungsschritt. Die Einführung eines Filters sollte nicht mit dem Abschluss des eigentlichen Update-Auftrags gleichgesetzt werden.

6. Vorfälle prüfen: Aktualisierung und Untersuchung getrennt verfolgen

Umsetzung: Organisieren Sie neben dem Update eine risikogerechte Prüfung auf bereits erfolgte Eingriffe. Sicherheitsverantwortliche sollten den relevanten Zeitraum, verfügbare Protokolle, auffällige Prozessaktivitäten und mögliche Veränderungen an Systemen bewerten. Einzelne Fehlermeldungen sind Untersuchungssignale, nicht automatisch Beweise eines Angriffs. Bei begründetem Verdacht sind der Incident-Response-Prozess und fachgerechte Beweissicherung maßgeblich; unkoordinierte Bereinigungen können die spätere Untersuchung erschweren. Fehlende Protokolle sollten ausdrücklich als Sichtbarkeitslücke dokumentiert werden. Die vorhandene Tippsliste verweist auf [4][6].
Fiktives Praxisbeispiel: Nach der Aktualisierung eines Portals entdeckt das interne Sicherheitsteam eine ungewöhnliche Prozessaktivität aus dem Zeitraum vor dem Update. Es sichert die verfügbaren Informationen, lässt den Befund untersuchen und bewertet mit dem Betrieb die nächsten Schritte. Das Portal erhält getrennte Statusangaben für »Laufzeit korrigiert« und »Vorfallsprüfung noch offen«.
Nachweis für das Management: Ein dokumentierter Untersuchungsumfang mit Ergebnissen und Grenzen. »Keine Auffälligkeiten im geprüften Zeitraum« ist präziser als eine pauschale Aussage, das System sei nachweislich nie kompromittiert gewesen.

7. Zugriffswege begrenzen: Geschäftsbedarf statt Netzvertrauen

Umsetzung: Erfassen Sie, welche Verbindungen ein Webdienst tatsächlich benötigt: etwa zum zugehörigen Datenbankdienst, zu internen Schnittstellen oder zu einem festgelegten Verwaltungszugang. Gleichen Sie bestehende Berechtigungen und Netzwerkfreigaben mit diesem Bedarf ab. Prüfen Sie insbesondere, ob Webdienstkonten unnötige Verwaltungsrechte oder Zugriff auf Backup-Steuerung besitzen. Änderungen sollten mit Funktionstests und abgestimmten Freigaben erfolgen; bei IT-/OT-Verbindungen sind Betriebsanforderungen gesondert zu berücksichtigen. Die vorhandenen Tipps beziehen sich hierzu auf [2][4].
Fiktives Praxisbeispiel: Ein Kundenportal darf bislang auf mehrere interne Servernetze zugreifen. Das Team dokumentiert die tatsächlich benötigten Verbindungen und schränkt nicht erforderliche Wege nach abgestimmter Prüfung ein. Die Bestellverarbeitung wird getestet; die Backup-Verwaltung erhält einen getrennten administrativen Zugang.
Nachweis für das Management: Eine überprüfte Übersicht notwendiger Kommunikationsbeziehungen, freigegebener Ausnahmen und getesteter Betriebsfunktionen. Entscheidend ist die nachvollziehbare Umsetzung, nicht allein die Existenz eines Segmentierungskonzepts.

8. Wiederanlauf testen: Der Geschäftsprozess ist die Prüfeinheit

Umsetzung: Vereinbaren Sie mit den Fachbereichen, welche Dienste zuerst wieder verfügbar sein müssen, welche Ausfallzeit akzeptabel ist und welcher Datenstand benötigt wird. Dokumentieren Sie Abhängigkeiten wie Identitätsdienste, Datenbanken, Konfigurationen, Zertifikate und externe Schnittstellen. Üben Sie den Wiederanlauf in einer geeigneten, abgestimmten Testumgebung mit geschützten Sicherungen und einer festgelegten Reihenfolge. Lassen Sie die Fachbereiche prüfen, ob der Geschäftsprozess funktioniert – nicht nur, ob der Server startet. Vergleichen Sie gemessene Ergebnisse mit den vereinbarten Zielen. Der bestehende Quellenbezug zur Wiederherstellung ist [4].
Fiktives Praxisbeispiel: Ein Großhändler stellt sein Bestellportal aus einer Sicherung wieder her. Das System startet, doch die Übergabe an die Warenwirtschaft funktioniert im Test zunächst nicht, weil eine erforderliche Schnittstellenkonfiguration fehlt. Das Team ergänzt den Wiederanlaufplan und wiederholt den abgestimmten Test einschließlich einer fachlichen Testbestellung.
Nachweis für das Management: Ein Wiederherstellungsbericht mit tatsächlicher Durchlaufzeit, wiederhergestelltem Datenstand, fachlicher Abnahme und offenen Abhängigkeiten. Offene Testmängel erhalten Verantwortliche und einen erneuten Prüftermin; ein erfolgreiches Backup-Protokoll ersetzt diesen Nachweis nicht.

FAQ: Zehn Fragen zu PHP2Shell und Cyberresilienz

Was ist PHP2Shell?
PHP2Shell bezeichnet die beiden Schwachstellen CVE-2026-109618 und CVE-2026-109619. Nach CERT-EU können beide eine Ausführung von Code aus der Ferne ohne vorherige Authentifizierung ermöglichen. Sie liegen in der Speicher- beziehungsweise Zustandsverwaltung von PHP und sind mit jeweils 9,2 nach CVSS v4.0 als kritisch bewertet. Entscheidend für die Unternehmenspraxis ist: Es handelt sich um ein Risiko der Laufzeitumgebung, nicht lediglich um einen Fehler eines einzelnen CMS-Plugins. [1]
Welche Versionen enthalten die veröffentlichten Korrekturen?
Am 21. Oktober 2026 wurden PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 als korrigierte Versionen veröffentlicht. Betroffen sind die jeweils früheren Versionen dieser Zweige sowie ältere, nicht mehr regulär unterstützte Zweige. Bei Linux-Distributionen und Produkten mit Herstellersupport können Korrekturen als Backports vorliegen. Deshalb ist zusätzlich zur Versionsnummer der Sicherheitshinweis des jeweiligen Paket- oder Produktherstellers maßgeblich. [1][2]
Reicht ein Update von WordPress, Drupal oder einem anderen CMS?
Nein. Eine Aktualisierung der Anwendung aktualisiert nicht zwangsläufig die darunterliegende PHP-Laufzeit. Das Drupal Security Team weist ausdrücklich darauf hin, dass die korrigierte PHP-Version erforderlich ist und Betreiber die Sicherheit der Hosting-Plattform mitverantworten. Unternehmen sollten je Dienst feststellen, wer PHP verwaltet und welcher korrigierte Stand aktiv eingesetzt wird. [2][3]
Sind nur öffentlich erreichbare Websites betroffen?
Nein. Das NCSC-NL nennt neben Webanwendungen auch Netzwerkgeräte, Appliances und Verwaltungsoberflächen mit eingebettetem PHP. Öffentlich erreichbare Systeme verdienen bei der Reaktion besondere Priorität, doch interne Dienste und Drittprodukte gehören ebenfalls in die Bestandsaufnahme. Welche konkrete Installation angreifbar ist, hängt von Laufzeit, Korrekturstand und Einsatzbedingungen ab; die bloße Verwendung von PHP ist noch kein Nachweis einer erfolgreichen Ausnutzung. [1][2]
Welche Rolle spielt die Betriebsart von PHP?
CERT-EU führt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed als zu prüfende webverarbeitende Installationen auf. Das PHP-Team bewertet mod_php als besonders risikoreich: Ein demonstrierter Angriff kann dort vor der Ausführung des Anwendungscodes ansetzen. Daraus folgt keine pauschale Entwarnung für andere Betriebsarten. Die offizielle Betroffenheit und die Herstellerhinweise bleiben maßgeblich. [1][2]
Können WAF oder Virtual Patching das Update ersetzen?
Nein. Vorgeschaltete Filter können bestimmte Anfragen abfangen und damit als Übergangsmaßnahme dienen. Datadog Security Labs weist jedoch darauf hin, dass verbreitete Einzelmaßnahmen keine vollständige Absicherung liefern. CERT-EU empfiehlt, betroffene Systeme unmittelbar zu aktualisieren oder eine vorübergehende Isolation exponierter Anwendungen zu erwägen, bis die Korrektur umgesetzt und überprüft ist. Filter sollten daher einen klaren Zweck und ein dokumentiertes Ende als Ausnahme haben. [1][6]
Ist ein Server nach dem Patch automatisch wieder vertrauenswürdig?
Ein korrigierter Softwarestand sagt zunächst etwas über die bekannte Schwachstelle aus, nicht über bereits erfolgte Eingriffe. Datadog nennt unter anderem auffällige Form-Anfragen, Speicherfehler und unerwartete Shell-Prozesse als Untersuchungssignale. Bei begründetem Verdacht gehören die Sicherung relevanter Beweise, die Eingrenzung des Vorfalls und eine kontrollierte Wiederherstellung in einen Incident-Response-Prozess. Auch Zugänge und erreichbare Folgesysteme sind situationsabhängig zu bewerten. [4][6]
Was ändert KI am Schwachstellenmanagement?
[Inference] Auf Basis beobachteter Entwicklungen bewertet das NCSC, dass KI Teile von Cyberangriffen wirksamer und effizienter machen und die Verbreitung entsprechender Fähigkeiten fördern dürfte. Diese Einschätzung ist eine Prognose mit ausgewiesenen Wahrscheinlichkeiten. Sie belegt weder, dass jeder Angriff KI nutzt, noch dass für jede Schwachstelle dieselbe kurze Reaktionsfrist gilt. Als Handlungsempfehlung sollten Unternehmen ihre Fähigkeit zur Bestandsaufnahme, Priorisierung und verifizierten Aktualisierung prüfen, statt die Priorität allein aus dem Schlagwort »KI« abzuleiten. [5]
Was sollten Unternehmen mit alten PHP-Versionen und eingebetteten Laufzeiten tun?
PHP 8.1 und ältere Zweige befinden sich außerhalb des regulären Supports des PHP-Projekts. Das NCSC-NL verweist auf mögliche Hersteller-Backports sowie veröffentlichte minimale Quellcodekorrekturen für PHP 7.4, 8.0 und 8.1. Diese Ausnahmen sind nicht mit einer regulär unterstützten Plattform gleichzusetzen. Unternehmen sollten konkrete Herstellerkorrekturen prüfen und eine Migration planen; bei Appliances ist häufig ein Produkt- oder Firmware-Update statt eines eigenständigen PHP-Updates erforderlich. [2]
Woran erkennt die Geschäftsführung belastbare Cyberresilienz?
An dokumentierten und erprobten Fähigkeiten statt allein an Produktanschaffungen: einem bekannten Bestand kritischer Dienste, benannten Zuständigkeiten, abgesicherten Sicherungen und nachvollziehbaren Wiederherstellungstests. CISA empfiehlt, Backups zu schützen, Wiederherstellungen regelmäßig zu testen und einen Incident-Response-Plan vorzuhalten. Für ein Management-Reporting bieten sich als Handlungsempfehlung die gemessene Wiederanlaufzeit, der erreichte Datenstand, offene Abhängigkeiten und nicht erfüllte Wiederherstellungsziele an. Der Begriff »ResOps« im Ausgangstext wird hier nicht als unabhängig nachgewiesener Branchenstandard vorausgesetzt. [4]

Quellen und redaktioneller Recherchehinweis

Recherche-Stand: 23. Oktober 2026. Die Bezugszeichen [1] bis [6] beziehen sich auf die neu ergänzten Bausteine. Die vorhandenen Expertenstatements bleiben unverändert; sie wurden nicht insgesamt als Tatsachen bestätigt. Insbesondere die im Ausgangstext genannten Herstellerzahlen, Tool-Bezeichnungen und der separate Zertifizierungsstellen-Vorfall werden in den Ergänzungen nicht als verifizierte Fakten übernommen. Prognosen zum KI-Einfluss sind ausdrücklich als Einschätzung gekennzeichnet.

[1] CERT-EU: Critical Vulnerabilities in PHP, Security Advisory 2026-018, aktualisiert am 21. Oktober 2026. https://cert.europa.eu/publications/security-advisories/2026-018/

[2] NCSC-NL: Operational information regarding the php2shell vulnerabilities, laufend gepflegte Bestands- und Handlungshinweise. https://github.com/NCSC-NL/php2shell

[3] Drupal Security Team: Critical PHP update on Wednesday, October 21, 2026 – PSA-2026-10-20. https://www.drupal.org/psa-2026-10-20

[4] CISA und Partner: #StopRansomware Guide, Leitfaden zu Prävention, Vorfallsreaktion und Wiederherstellung. https://www.cisa.gov/stopransomware/ransomware-guide

[5] National Cyber Security Centre: Impact of AI on cyber threat from now to 2027, behördliche Bedrohungseinschätzung mit probabilistischen Aussagen. https://www.ncsc.gov.uk/report/impact-ai-cyber-threat-now-2027

[6] Datadog Security Labs: PHP2Shell – Critical vulnerabilities in PHP: detection, analysis, and remediation, 21. Oktober 2026. https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/