PHP2Shell: Warum der Patch nur die halbe Arbeit ist
PHP2Shell als ungeplanter Live-Test für ISO 27001, TISAX und das eigene Informationssicherheitsmanagement
Stand: 23.10.2026
In den vergangenen Tagen ging es für viele Administratoren, Hosting-Anbieter, Behörden und Unternehmen plötzlich sehr schnell.
PHP-Versionen wurden geprüft. Server wurden aktualisiert. Webseiten teilweise vorsorglich vom Netz genommen. Dienstleister wurden kontaktiert. Logs wurden untersucht. Entscheidungen mussten innerhalb weniger Stunden getroffen werden.
Der Grund: Zwei kritische Schwachstellen im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, zusammen häufig als PHP2Shell bezeichnet.
PHP veröffentlichte am 21. Oktober 2026 die Sicherheitsupdates PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Nach Angaben des PHP-Projekts können die Schwachstellen eine nicht authentifizierte Remote Code Execution ermöglichen. Betroffen sind grundsätzlich PHP-Installationen, die Webanfragen verarbeiten – darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Für mod_php bewertet das PHP-Projekt das Risiko besonders hoch.
Für mich ist PHP2Shell aber nicht nur ein technisches Patch-Thema.
Es ist gleichzeitig ein ungeplanter Live-Test für das Informationssicherheitsmanagement eines Unternehmens.
Denn wenn das technische Problem in einigen Tagen erledigt ist, bleibt eine andere Frage bestehen:
Kann das Unternehmen anschließend noch nachvollziehbar zeigen, wie es mit der Situation umgegangen ist?
Was ist PHP2Shell technisch?
Die beiden Schwachstellen liegen nicht in WordPress, Joomla, Drupal oder einem bestimmten Plugin, sondern im PHP-Kern selbst.
Das ist ein entscheidender Unterschied.
Ein Unternehmen kann WordPress vollständig aktuell halten, alle Plugins aktualisieren und trotzdem eine verwundbare PHP-Version darunter betreiben. Ein CMS-Update ersetzt daher nicht automatisch ein notwendiges Update der PHP-Runtime.
Bei CVE-2026-109618 können Fehler im Umgang mit Out-of-Memory-Situationen dazu führen, dass PHP teilweise initialisierte interne Daten beim Aufräumen fälschlicherweise als gültig behandelt. Bei CVE-2026-109619 kann interner Zustand eines Requests bestehen bleiben, obwohl der zugrunde liegende Speicher bereits freigegeben wurde. Unter bestimmten Bedingungen lassen sich diese Speicherfehler bis hin zur Ausführung von Code ausnutzen.
Wiz Research demonstrierte nicht authentifizierte Codeausführung unter anderem in Umgebungen mit WordPress, Drupal und Joomla. Die Forscher betonen ausdrücklich, dass diese Systeme lediglich Demonstrationsziele waren – die eigentliche Schwachstelle befindet sich in PHP. Zusätzlich wurde die Möglichkeit gezeigt, Speicherinhalte eines PHP-Prozesses auszulesen, in denen sich beispielsweise Passwörter, Tokens oder API-Schlüssel befinden können.
Das PHP-Projekt formuliert die Konsequenz deutlich: Die veröffentlichten Updates sind die vollständige Lösung. Temporäre Schutzmaßnahmen können das Risiko reduzieren, machen ein ungepatchtes System aber nicht vollständig sicher.
Und Angriffe?
Hier ist eine saubere Trennung wichtig.
Dass funktionierende Exploit-Techniken demonstriert wurden, ist bestätigt. Ebenso berichtet Cloudflare über beobachteten Angriffstraffic gegen Kunden. Dabei wurden auch veränderte Payloads beobachtet, mit denen versucht wurde, Schutzmechanismen zu umgehen.
Das bedeutet aber nicht automatisch, dass jedes erreichbare verwundbare PHP-System kompromittiert wurde.
Eine flächendeckend erfolgreiche Kompromittierung lässt sich zum derzeitigen Stand nicht bestätigen.
Genau diese Unterscheidung ist auch für Unternehmen wichtig: Eine vorhandene Schwachstelle, ein erkannter Angriffsversuch, ein Verdachtsfall und ein bestätigter Informationssicherheitsvorfall sind nicht dasselbe.
Schwachstelle entdeckt – und jetzt?
Stellen wir uns einen typischen Mittwochmorgen in einem Unternehmen vor.
Eine Warnung über eine kritische PHP-Schwachstelle erreicht die IT.
Und jetzt?
Ist überhaupt bekannt, auf welchen Systemen PHP eingesetzt wird?
Welche Versionen laufen dort?
Welche Systeme sind aus dem Internet erreichbar?
Welche Anwendung ist geschäftskritisch?
Welche Systeme werden selbst betrieben und welche durch einen Hosting- oder IT-Dienstleister?
Wer bewertet die Schwachstelle?
Wer entscheidet über die Priorisierung?
Wer darf einen produktiven Webserver aktualisieren oder im Zweifel abschalten?
Wer informiert die Geschäftsführung?
Und wer dokumentiert das Ganze?
Das britische NCSC empfiehlt ausdrücklich, zunächst sämtliche PHP-Systeme zu identifizieren und internetseitig erreichbare Systeme zu priorisieren. Kann nicht zeitnah gepatcht oder ausreichend mitigiert werden, soll sogar eine vorübergehende Abschaltung erwogen werden. Außerdem wird eine Prüfung auf Hinweise einer Kompromittierung empfohlen, insbesondere wenn ein System nicht unmittelbar aktualisiert oder deaktiviert werden konnte.
Das ist technisch sinnvoll.
Aus Sicht eines ISMS ist es aber noch etwas anderes:
Es ist ein Test der organisatorischen Handlungsfähigkeit.
Der für mich spannendste Punkt: die Dokumentation
Viele Administratoren haben in den letzten Stunden vermutlich genau das Richtige getan.
Sie haben Systeme identifiziert, Versionen geprüft, Dienstleister angerufen, Updates eingespielt, Dienste neu gestartet, Logs geprüft oder Webanwendungen getestet.
Sehr gut.
Aber jetzt kommt die nächste Frage:
Ist davon auch etwas nachvollziehbar dokumentiert worden?
In sechs Monaten erinnert sich niemand zuverlässig daran:
„Ich glaube, Thomas hatte damals morgens PHP aktualisiert.“
Oder:
„Unser Provider hatte gesagt, das wäre erledigt.“
Ein belastbarer Prozess sollte später beispielsweise nachvollziehbar machen können:
Wann die Information zur Schwachstelle eingegangen ist.
Aus welcher Quelle sie stammt.
Welche CVEs betrachtet wurden.
Wer die Bewertung übernommen hat.
Welche Systeme geprüft wurden.
Welche Systeme betroffen waren.
Welche Systeme nicht betroffen waren und warum.
Welche Priorisierung vorgenommen wurde.
Welche Entscheidungen getroffen wurden.
Wann Dienstleister kontaktiert wurden.
Welche Sofortmaßnahmen durchgeführt wurden.
Wann der Patch installiert wurde.
Welche Version anschließend eingesetzt wurde.
Welche Funktionsprüfung erfolgte.
Ob Logs beziehungsweise Hinweise auf eine mögliche Kompromittierung geprüft wurden.
Wer die Wiederfreigabe erteilt hat.
Wann der Vorgang abgeschlossen wurde.
Und welche Lessons Learned daraus entstanden sind.
Genau hier wird aus einer technischen Tätigkeit ein nachvollziehbarer Informationssicherheitsprozess.
ISO 27001: Das nächste Audit kommt bestimmt
Ich würde mich nicht darauf verlassen, dass beim nächsten Audit lediglich gefragt wird:
„Ist PHP aktuell?“
Viel interessanter wäre eine Frage wie:
„Wie sind Sie mit PHP2Shell umgegangen? Zeigen Sie mir bitte den Vorgang.“
Denn ein Ereignis wie PHP2Shell berührt praktisch zahlreiche Themen eines Informationssicherheitsmanagementsystems:
Asset- und Softwaremanagement.
Schwachstellenmanagement.
Patch- und Change-Management.
Risikomanagement.
Logging und Monitoring.
Incident Management.
Lieferantenmanagement.
Kommunikation.
Business Continuity.
Nachweisführung.
Ein Unternehmen kann mit einem solchen realen Beispiel sehr überzeugend zeigen, dass seine Prozesse funktionieren.
Oder eben das Gegenteil.
Vielleicht stellte sich beispielsweise heraus, dass niemand wusste, welche PHP-Version beim Webhoster eingesetzt wird.
Vielleicht war unklar, wer den Dienstleister kontaktieren darf.
Vielleicht gab es drei Ansprechpartner, aber keiner fühlte sich verantwortlich.
Vielleicht funktionierte der technische Prozess hervorragend – aber niemand dokumentierte die Entscheidung.
Auch das sind Erkenntnisse.
Ein ISMS sollte nicht nur Sicherheitsmaßnahmen beschreiben. Es sollte ermöglichen, solche Situationen beherrscht, nachvollziehbar und wiederholbar zu behandeln.
TISAX: Richtlinie geschrieben – Prozess auch gelebt?
Im TISAX- beziehungsweise VDA-ISA-Umfeld ist der Gedanke sehr ähnlich.
Ein Unternehmen kann hervorragende Richtlinien vorlegen.
Es kann darin geregelt haben, wie Sicherheitsvorfälle behandelt werden.
Es kann Eskalationswege definiert, Ansprechpartner benannt und ein Lieferantenmanagement aufgebaut haben.
Aber PHP2Shell stellt wesentlich unbequemere Fragen:
Funktioniert das auch am Mittwochmorgen?
Erreicht die Information die richtige Person?
Gibt es eine Vertretung?
Kann kurzfristig entschieden werden?
Ist bekannt, welche Systeme betroffen sein könnten?
Kann ein externes System kurzfristig abgeschaltet werden?
Sind Ansprechpartner beim Provider bekannt?
Werden Änderungen kontrolliert durchgeführt?
Kann anschließend nachvollzogen werden, was wann passiert ist?
Eine kritische Schwachstelle kann damit unbeabsichtigt zu einer sehr realen Wirksamkeitsprüfung des eigenen ISMS werden.
Das ist für mich einer der wichtigsten Punkte an der aktuellen Situation.
Nicht jede Schwachstelle ist automatisch ein Incident
Dabei sollte man sprachlich und organisatorisch sauber bleiben.
Eine Schwachstelle bedeutet zunächst, dass eine technische Verwundbarkeit vorhanden ist.
Ein beobachteter verdächtiger Request kann ein Security Event darstellen.
Auffälligkeiten im System können einen Verdachtsfall begründen.
Erst nach einer entsprechenden Bewertung kann daraus ein Informationssicherheitsvorfall werden.
Es wäre deshalb falsch, pauschal zu behaupten:
„Wir hatten PHP2Shell, also hatten wir einen Security Incident.“
Interessanter ist vielmehr die dokumentierte Entscheidung:
Wie wurde die Situation klassifiziert und warum?
Ein Unternehmen, das dies nachvollziehbar beantworten kann, zeigt bereits einen gewissen Reifegrad seines Sicherheitsprozesses.
Und wenn der Server beim Dienstleister steht?
Gerade bei Unternehmenswebseiten liegt der Webserver häufig nicht im eigenen Serverraum.
Managed Hosting, Agenturen, Webhoster, Rechenzentren und Cloudanbieter übernehmen große Teile des technischen Betriebs.
Aber dadurch verschwindet die eigene Verantwortung für die Steuerung des Dienstleisters nicht.
Die Frage lautet deshalb:
Wer ist eigentlich für PHP verantwortlich?
Der Kunde?
Die Webagentur?
Der Hostinganbieter?
Ein Managed-Service-Provider?
Und vor allem: Ist das eindeutig geregelt?
Plesk veröffentlichte für seine Plattform detaillierte Informationen zu betroffenen und gepatchten PHP-Versionen. Für die aktuell unterstützten Zweige werden ebenfalls 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als korrigierte Versionen genannt. Für bestimmte ältere PHP-Zweige gibt es anbieterspezifische Backports beziehungsweise Extended-Lifecycle-Lösungen.
Das zeigt sehr gut, warum die einfache Frage „Welche PHP-Version haben wir?“ manchmal nicht genügt.
Bei paketierten oder gemanagten Systemen muss zusätzlich geklärt werden, ob der Hersteller oder Anbieter einen Sicherheitsfix zurückportiert hat.
„Unser Provider hat das erledigt“ reicht mir nicht
Wenn bei einem Audit die Frage kommt:
„Wie haben Sie auf PHP2Shell reagiert?“
und die Antwort lautet:
„Das macht unser Provider.“
dann drängt sich unmittelbar die nächste Frage auf:
„Woher wissen Sie, dass er es gemacht hat?“
Ein wesentlich belastbarerer Vorgang könnte beispielsweise so aussehen:
Am 21. Oktober wurde die Sicherheitswarnung aufgenommen.
Anschließend wurde geprüft, welche Systeme möglicherweise betroffen sind.
Um 10:15 Uhr wurde beim Hosting-Dienstleister ein Security-Ticket eröffnet.
Der Dienstleister bestätigte die eingesetzte PHP-Version.
Um 14:30 Uhr wurde das Update durchgeführt.
Die aktualisierte Version wurde anschließend bestätigt.
Die Webanwendung wurde getestet.
Relevante Logs wurden geprüft.
Der Dienstleister bestätigte das Ergebnis schriftlich.
Danach wurde der Vorgang geschlossen.
Das Unternehmen muss dafür nicht sämtliche technischen Interna des Providers besitzen.
Es sollte aber seine eigene Dienstleistersteuerung belegen können.
Tier III oder Tier IV hilft hier nur begrenzt
Auch die Bezeichnung eines Rechenzentrums als Tier I, II, III oder IV sollte nicht mit Informationssicherheitszertifizierungen vermischt werden.
Die Tier-Klassifikation des Uptime Institute beschreibt Eigenschaften der Rechenzentrumsinfrastruktur. Tier III steht beispielsweise für „Concurrently Maintainable“, Tier IV für „Fault Tolerant“. Im Mittelpunkt stehen insbesondere Redundanz, Wartbarkeit und Ausfallsicherheit der Standortinfrastruktur.
Das ist wichtig.
Aber:
Ein hochverfügbares Rechenzentrum beantwortet noch nicht die Frage, wie schnell eine kritische PHP-Schwachstelle erkannt, bewertet und auf einem dort betriebenen Server behoben wird.
Auch ein Tier-IV-Rechenzentrum ersetzt deshalb kein Vulnerability Management, kein Patchmanagement und keine geregelte Dienstleistersteuerung.
Patch installiert – Vorgang beendet?
Nicht unbedingt.
Genau hier liegt ein weiterer wichtiger Punkt.
Wenn ein Server bereits öffentlich erreichbar und verwundbar war, muss abhängig von Risiko und Exposition auch gefragt werden:
War möglicherweise jemand schneller als wir?
Das NCSC empfiehlt ausdrücklich, bei Systemen, die nicht unmittelbar aktualisiert oder deaktiviert werden konnten, nach Hinweisen auf eine Kompromittierung und mögliche Backdoors zu suchen.
Je nach Umgebung können dabei beispielsweise Webserver-Logs, PHP-Logs, WAF-Daten, EDR-/XDR-Meldungen, Authentifizierungsereignisse, auffällige Dateiänderungen oder ungewöhnliche Netzwerkverbindungen betrachtet werden.
Wiz weist darauf hin, dass Angriffe teilweise unterhalb der eigentlichen Anwendungsschicht stattfinden können. Deshalb können reine Anwendungslogs unter Umständen nur begrenzte Hinweise liefern. Als mögliche Untersuchungssignale nennen die Forscher unter anderem ungewöhnliche Multipart-Requests, Memory-Limit-Fehler, wiederholte HTTP-500-Antworten oder auffälliges Verhalten von PHP-Workern.
Das bedeutet nicht, dass bei jedem einzelnen PHP-System sofort eine vollständige forensische Untersuchung notwendig ist.
Die Entscheidung sollte risikobasiert erfolgen.
Aber sie sollte getroffen – und dokumentiert – werden.
Und dann ist da noch der Datenschutz
Eine verwundbare PHP-Version ist nicht automatisch eine Datenschutzverletzung.
Auch ein erfolgreicher Patch bedeutet umgekehrt nicht automatisch, dass vorher kein unbefugter Zugriff stattgefunden hat.
Wenn Hinweise auf eine tatsächliche oder mögliche Kompromittierung vorliegen, muss deshalb gegebenenfalls zusätzlich bewertet werden:
Wurden personenbezogene Daten über das System verarbeitet?
Konnte auf diese Daten zugegriffen werden?
Welche Datenarten waren betroffen?
Welche Protokolldaten stehen zur Verfügung?
Welche Folgen könnten sich für betroffene Personen ergeben?
Und ist aufgrund der konkreten Erkenntnisse eine Bewertung nach Art. 33 DSGVO erforderlich?
Die reine Existenz von PHP2Shell löst nicht automatisch eine Meldung an die Datenschutzaufsichtsbehörde aus.
Ein möglicher oder bestätigter Zugriff auf personenbezogene Daten kann allerdings eine entsprechende Prüfung erforderlich machen.
PHP2Shell als Feueralarm ohne Vorwarnung
Bei einer geplanten Notfallübung steht der Termin im Kalender.
Teilnehmer sind informiert.
Das Szenario wurde möglicherweise vorbereitet.
Vielleicht weiß sogar jemand, welche Ergebnisse erwartet werden.
Eine reale kritische Schwachstelle funktioniert anders.
Sie taucht plötzlich in einem Security-Feed, einer Herstellerwarnung oder einer E-Mail auf.
Und dann muss die Organisation funktionieren.
PHP kündigte die kritischen Sicherheitsupdates am 20. Oktober zunächst für den Folgetag an. Am 21. Oktober wurden die Patches veröffentlicht. ENISA, die Europäische Kommission, CERT-EU, Europol EC3 und das europäische CSIRT-Netzwerk riefen Organisationen gemeinsam zu sofortigem Handeln auf.
Cloudflare meldete parallel bereits Angriffstraffic gegen Kunden.
Viel realistischer kann eine ungeplante Übung kaum werden.
PHP2Shell war keine geplante Übung. Für viele Informationssicherheitsmanagementsysteme war es trotzdem ein sehr realer Funktionstest.
Was würde ich jetzt dokumentieren?
Wenn ich für einen solchen Vorgang verantwortlich wäre, würde ich nach der technischen Bearbeitung noch einmal prüfen, ob mindestens folgende Punkte nachvollziehbar dokumentiert sind:
1. Zeitpunkt und Quelle der ersten Information über PHP2Shell.
2. Verantwortliche Person für die Bewertung.
3. Identifizierte PHP-Systeme und eingesetzte Versionen.
4. Öffentlich erreichbare beziehungsweise besonders kritische Systeme.
5. Festgestellte Betroffenheit beziehungsweise begründete Nichtbetroffenheit.
6. Risikobewertung und Priorisierung.
7. Getroffene Sofortmaßnahmen.
8. Kontakt zu Hosting- und IT-Dienstleistern.
9. Zeitpunkt und Art des Updates.
10. Anschließend eingesetzte PHP-Version beziehungsweise Hersteller-Patchstand.
11. Durchführung und Ergebnis der Funktionsprüfung.
12. Entscheidung über eine notwendige Kompromittierungsprüfung.
13. Ergebnis der Log- oder Security-Prüfung.
14. Zeitpunkt und Verantwortlicher der Wiederfreigabe.
15. Lessons Learned und daraus abgeleitete Verbesserungen.
Damit entsteht aus dem hektischen technischen Vorgang ein nachvollziehbarer Sicherheitsprozess.
Und genau dieser Nachweis kann beim nächsten Audit wesentlich interessanter sein als ein Screenshot, der lediglich zeigt, dass heute die aktuelle PHP-Version installiert ist.
Mein Fazit
Vielleicht ist PHP2Shell technisch schon in wenigen Tagen für viele Unternehmen erledigt.
Die Systeme sind aktualisiert.
Die Webseiten laufen wieder.
Die Tickets werden geschlossen.
Für das Informationssicherheitsmanagement sollte der Vorgang damit aber nicht einfach verschwinden.
Denn genau solche ungeplanten Situationen zeigen, ob Sicherheitsprozesse lediglich in Richtlinien beschrieben wurden oder ob sie tatsächlich funktionieren.
Wusste die Organisation, welche Systeme betroffen sind?
Gab es klare Verantwortlichkeiten?
Konnten Entscheidungen schnell getroffen werden?
Funktionierte die Kommunikation mit Dienstleistern?
Wurde nicht nur gepatcht, sondern anschließend auch geprüft?
Und vor allem:
Kann das Unternehmen dies heute noch nachvollziehbar dokumentieren?
Dann kann PHP2Shell trotz des erheblichen Risikos noch einen positiven Nebeneffekt haben: Der Vorgang liefert einen echten Wirksamkeitsnachweis für das eigene Informationssicherheitsmanagement – und gleichzeitig Hinweise darauf, was bis zum nächsten Ernstfall verbessert werden sollte.
Die Frage beim nächsten Audit lautet dann möglicherweise nicht nur: „Haben Sie gepatcht?“
Sondern: „Können Sie zeigen, wie Ihr Unternehmen damit umgegangen ist?“
Quellen und weiterführende Informationen
PHP Project – Sicherheitsinformationen und Releases
Bundesamt für Sicherheit in der Informationstechnik – Cybersicherheitswarnung zu PHP
ENISA – Joint Statement on Critical PHP Vulnerabilities
UK National Cyber Security Centre – Critical Security Issue Affecting PHP
Cloudflare – PHP2Shell WAF Protections
Wiz Research – PHP2Shell Technical Analysis
Plesk – PHP2Shell Advisory
Uptime Institute – Tier Certification
Hinweis: Dieser Beitrag stellt meine persönliche fachliche Einschätzung und allgemeine Information dar. Er ersetzt keine individuelle Prüfung oder Beratung für eine konkrete technische oder rechtliche Situation.