PHP-Sicherheitslücke kostenfrei prüfen: Ist Ihre Website von PHP2Shell betroffen?

PHP2Shell bezeichnet zwei kritische Sicherheitslücken in der PHP-Laufzeit: CVE-2026-109618 und CVE-2026-109619. Öffentlich erreichbare, ungepatchte PHP-Installationen erfordern ein dringendes Sicherheitsupdate. PHP führt auf dem Server unter anderem WordPress, Shops und Kundenportale aus. Bei den bestätigten Angriffen benötigt der Angreifer weder ein Benutzerkonto noch die Mitwirkung eines Besuchers.

Die Fehler betreffen den Umgang mit internem Speicher: Eine Schwachstelle hinterlässt nach einem Speicherabbruch unvollständig vorbereitete Daten. Die andere lässt Verweise auf bereits freigegebenen Speicher über das Ende einer Anfrage hinaus bestehen. Daraus können Datenoffenlegung und fremde Codeausführung entstehen. Beide CVEs erreichen 9,2 von 10 Punkten nach CVSS 4.0. Diese Bewertung beschreibt die Schwere, nicht die Wahrscheinlichkeit eines erfolgreichen Angriffs auf Ihre konkrete Website.¹

Ermitteln Sie jetzt den Patchstand der tatsächlich verwendeten Web-PHP-Instanz und veranlassen Sie die Korrektur beider CVEs. Warten Sie bei einem ungeklärten, öffentlich erreichbaren System nicht auf das nächste reguläre Wartungsfenster. Falls der Fix kurzfristig nicht zur Verfügung steht, braucht die Website eine wirksame Zugangsbeschränkung vor der PHP-Verarbeitung. Ein bereits vollständig gepatchtes System erfordert wegen dieser Meldung keine vorsorgliche Abschaltung; ein möglicher früherer Angriff bleibt eine gesonderte Prüfaufgabe.

Ja, sofern die Website eine betroffene PHP-Laufzeit verwendet. Ein aktuelles CMS und eine kleine Website schließen PHP2Shell nicht aus. WordPress-, Plugin- und Theme-Updates ändern den Anwendungscode. Das PHP-Sicherheitsupdate ersetzt beziehungsweise korrigiert den Interpreter darunter. Beide Wartungsaufgaben gehören deshalb getrennt in Ihre Prüfung.

Besucherzahl, Unternehmensgröße und die Bekanntheit Ihrer Domain entscheiden nicht darüber, ob PHP eine präparierte Anfrage verarbeitet. Auch eine Vereinsseite, ein Blog oder eine kaum genutzte Testinstallation kann öffentlich erreichbar sein. Fehlende Kundenkonten oder Bestelldaten begrenzen allenfalls bestimmte mögliche Schäden: Angreifer könnten beispielsweise Inhalte manipulieren, Weiterleitungen einbauen oder die Website für weitere missbräuchliche Aktivitäten verwenden.

Erstellen Sie daher eine Liste aller PHP-Anwendungen in Ihrem Hostingkonto: Hauptdomain, Subdomains, alte Projektordner, Staging, Webmail und zusätzliche Verwaltungsoberflächen. Bei Software, die PHP mitliefert, zählt das Update des jeweiligen Produkts; ein Update des Betriebssystem-PHP erreicht dessen eigene Laufzeit nicht zwangsläufig.²

Eine ausschließlich statische Website ohne erreichbare PHP-Verarbeitung bietet diese serverseitige Angriffsfläche nicht. Ein WordPress-Cache macht eine Installation jedoch nicht automatisch statisch: Anmeldung, Formulare, APIs oder direkte PHP-Dateien können weiterhin den Interpreter erreichen. Entscheidend ist die tatsächliche Verarbeitung der erreichbaren Anfragen.

Ein erfolgreicher Angriff kann Code mit den Rechten des PHP-Webprozesses ausführen. Root-Rechte entstehen dadurch nicht automatisch; für einen erheblichen Schaden reichen die normalen Anwendungsrechte häufig aus. Welche Daten und Systeme erreichbar sind, bestimmen insbesondere Betriebssystemrechte, Datenbankberechtigungen, eingebundene Verzeichnisse und verfügbare Zugangsschlüssel. Die Forschung zeigt außerdem die Offenlegung von Prozessspeicher ohne erreichte Codeausführung. Fehlende Dateiveränderungen schließen deshalb einen Datenabfluss nicht aus.⁷

• Daten lesen: beispielsweise lesbare Konfigurationsdateien, Kundendaten aus erreichbaren Datenbanken oder Zugangsdaten und Tokens, die die Anwendung verwendet.
• Inhalte und Abläufe verändern: etwa beschreibbare PHP-Dateien, Shop-Inhalte, Formulare oder Datenbankeinträge. Bei einer manipulierten Zahlungsseite drohen auch Schäden für Besucher.
• Zugriff aufrechterhalten: etwa durch eine zusätzliche Datei oder ein angelegtes Anwendungskonto, sofern die vorhandenen Rechte dies erlauben.
• Verfügbarkeit stören: durch Prozessabstürze, Ressourcenverbrauch oder Manipulation der Anwendung.

Eine Shell ist dafür keine zwingende Voraussetzung. Die Sperre einzelner PHP-Funktionen wie exec() oder shell_exec() repariert keine Speicherfehler im Interpreter. Auch open_basedir ersetzt keine belastbare Isolation auf Betriebssystemebene. Behandeln Sie solche Einstellungen nicht als Nachweis, dass PHP2Shell keinen relevanten Schaden verursachen kann.³

Umgekehrt belegt eine erfolgreiche Codeausführung im Webprozess noch keine Übernahme des gesamten Hostsystems oder sämtlicher Kunden des Hosters. Dafür braucht der Angreifer weitere Zugriffsrechte, Fehlkonfigurationen oder Schwachstellen. Prüfen Sie den konkret erreichbaren Daten- und Berechtigungsumfang, statt entweder den gesamten Server pauschal abzuschreiben oder fehlende Root-Rechte als Entwarnung zu werten.

Die ersten vollständigen Korrekturen des PHP-Projekts stehen in diesen Releases bereit:

• PHP 8.2: ab 8.2.35
• PHP 8.3: ab 8.3.36
• PHP 8.4: ab 8.4.27
• PHP 8.5: ab 8.5.12

Verwenden Sie mindestens den korrigierten Stand Ihres Zweigs oder dessen neueres Sicherheitsrelease. Ein Wechsel von PHP 8.3 auf 8.5 ist für diese beiden Korrekturen nicht zwingend erforderlich: Ein gepflegtes, vollständig gepatchtes 8.3-Paket erfüllt die Aufgabe ebenfalls. Ein Wechsel auf einen anderen, aber weiterhin ungepatchten Zweig löst sie dagegen nicht. Die bloße Bezeichnung „PHP 8“ reicht als Nachweis nicht aus.¹

PHP 8.1 und ältere Zweige erhalten keine regulären Sicherheitsreleases mehr vom PHP-Projekt. Einige Distributoren und Anbieter mit Langzeitpflege liefern eigene Backports. Das PHP-Team hat wegen der Schwere außerdem minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt. Das ist weder ein fertiges Hostingupdate noch eine Wiederaufnahme der regulären Pflege. Ein Anbieter muss solche Korrekturen fachgerecht integrieren, ausrollen und für sein Paket bestätigen.²

Wenn Ihre Altanwendung keinen unterstützten Zweig verträgt, benötigen Sie kurzfristig einen nachweislich korrigierten Anbieter-Build und parallel einen Migrationsplan. Ohne einen solchen Fix sollte die alte Laufzeit nicht unbeschränkt öffentlich erreichbar bleiben. Ein Backport für PHP2Shell beantwortet außerdem noch nicht, wie der Anbieter andere Sicherheitslücken dieser Altversion behandelt.

„PHP 8.5“ bezeichnet nur den Versionszweig. Die Anzeige unterscheidet die ungepatchte Version 8.5.9 nicht von der korrigierten Version 8.5.12. Der Hoster kann Sicherheitsupdates innerhalb des Zweigs einspielen, ohne den Namen der Auswahl im Kundenmenü zu ändern. Umgekehrt belegt die unveränderte Auswahl keinen aktuellen Patchstand.

Lesen Sie die vollständige Version aus einer tatsächlich über Ihre Domain ausgeführten PHP-Anfrage. In WordPress finden Sie die Serverinformationen unter Werkzeuge → Website-Zustand → Bericht → Server; je nach Übersetzung heißt der Informationsreiter auch „Info“. Notieren Sie Versionsnummer, Datum und betroffene Domain. Bei anderen Anwendungen verwenden Sie deren geschützte Systeminformationen oder lassen sich die Angaben vom zuständigen Administrator geben. Veröffentlichen Sie dafür keinen uneingeschränkt erreichbaren phpinfo()-Bericht.⁴

php -v im Terminal zeigt die Version des dort aufgerufenen Kommandozeilenprogramms. Der Webserver kann ein anderes PHP-Paket oder einen anderen FPM-Pool verwenden. Auch Subdomains und Verzeichnisse können abweichende Zuweisungen besitzen. Prüfen Sie deshalb jede eigenständige Installation und lassen Sie bei mehreren Backends alle Instanzen erfassen.

Eine vollständige Versionsnummer ordnet den regulären PHP-Release ein. Bei einem Anbieter-Backport brauchen Sie zusätzlich dessen Paketnachweis. Ein ausgeblendeter HTTP-Versionsheader sagt dagegen weder „sicher“ noch „verwundbar“ aus; er entfernt nur eine öffentlich sichtbare Information.

Eine ältere PHP-Versionsnummer kann zu einem vollständig korrigierten Anbieterpaket gehören. Bei einem Backport übernimmt der Anbieter die Sicherheitskorrekturen in seinen bestehenden Versionsstand. Linux-Distributionen nutzen dieses Vorgehen, um Sicherheitsfehler zu beheben und andere Verhaltensänderungen möglichst klein zu halten. Die ursprüngliche Upstream-Versionsnummer allein bildet den Korrekturstand dann nicht vollständig ab.⁵

Für eine belastbare Bestätigung müssen drei Angaben zusammenpassen: das Sicherheitsbulletin des Anbieters, die konkrete Paket- oder Buildkennung und die tatsächlich laufende Instanz Ihrer Website. Bitten Sie den Hoster deshalb um eine Antwort auf diese Punkte:

• Behebt das eingesetzte Paket CVE-2026-109618 und CVE-2026-109619 vollständig?
• Welche Paket- oder Buildversion enthält die Korrekturen, und welcher Anbieterhinweis dokumentiert sie?
• Welche Domains, PHP-Pools und Backend-Server umfasst der abgeschlossene Rollout?
• Seit wann laufen dort die korrigierten Prozesse, und hat der Hoster alle alten Worker ersetzt?

Eine nachvollziehbare Anbieterbestätigung mit diesem Bezug kann einen Backport belegen, auch wenn die kurze PHP-Versionskennung unverändert bleibt. Ein beliebiger Versionszusatz, ein allgemeines „alle Systeme aktuell“ oder ein Verweis auf aktive Firewall-Regeln reicht dafür nicht. Ebenso wenig sollten Sie einen dokumentierten Backport allein wegen einer älteren Upstream-Nummer als ungepatcht abweisen.

Bewahren Sie die Auskunft zusammen mit Domain, Zeitpunkt und Paketkennung auf. Wenn der Anbieter nur eine der beiden CVEs oder lediglich einzelne Angriffswege nennt, bleibt die vollständige Behebung offen. Lassen Sie genau diese Lücke in der Aussage klären.

Keine dieser Bezeichnungen liefert für sich eine Entwarnung. Entscheidend sind die verwendete PHP-Laufzeit und der vollständige Fix. nginx verarbeitet PHP normalerweise nicht selbst, sondern übergibt entsprechende Anfragen beispielsweise an PHP-FPM. Ein aktueller nginx vor einem ungepatchten PHP-FPM repariert dessen Sicherheitslücken nicht.

Die technische Einbindung beeinflusst allerdings die Angriffsvoraussetzungen. Apache mit mod_php gilt als besonders kritisch. PHP-FPM beendet einen Worker, wenn bereits der Start der Anfrage fehlschlägt; dadurch überlebt ein bestimmter früher Fehlerablauf dort nicht. Die Herstelleranalyse bestätigt dennoch einen FPM-Angriffsweg nach erfolgreichem Anfragestart, der eine geeignete Anwendungsoperation voraussetzt. „Dieser mod_php-Angriff funktioniert bei uns nicht“ bedeutet deshalb nicht „PHP2Shell betrifft uns nicht“.¹

Auch andere Webeinbindungen, darunter LiteSpeed, FrankenPHP und PHP-CGI, gehören in die Bestandsaufnahme. Das Betriebssystem allein belegt ebenfalls keinen Fix. Fordern Sie für Windows- oder Linux-Pakete den passenden Herstellernachweis an, statt einen Wechsel der Serverplattform als Ersatz für das PHP-Update zu behandeln.

Ein Container kann den erreichbaren Bereich begrenzen, enthält aber weiterhin seine eigene PHP-Laufzeit. Ein Update des Hosts ersetzt diese nicht automatisch. Aktualisieren Sie das passende Image und die daraus gestarteten Container. Prüfen Sie zusätzlich eingebundene Verzeichnisse, Secrets und Datenbankrechte: Genau diese Ressourcen kann auch ein kompromittierter Prozess innerhalb des Containers erreichen, soweit seine Rechte es erlauben.

Ja. Ein fehlendes Uploadformular und der Verzicht auf eigene Session-Aufrufe schließen PHP2Shell nicht aus. Ein Formular ist nur eine Bedienoberfläche für reguläre Besucher. Ein Angreifer kann HTTP-Anfragen selbst erzeugen und an einen erreichbaren PHP-Endpunkt senden, ohne ein entsprechendes Formular auf Ihrer Website zu finden.

PHP übernimmt Teile der Eingabeverarbeitung bereits vor dem eigentlichen Anwendungsskript. Deshalb verhindert beispielsweise eine Prüfung im Skript, die nur bestimmte Methoden zulässt, nicht zwangsläufig die davorliegende Verarbeitung. Eine später ausgegebene Fehlermeldung oder Weiterleitung sagt nichts darüber aus, welche Arbeit PHP vorher erledigt hat.

Die PHP-Funktion für den Upload-Fortschritt kann außerdem Session-Verarbeitung auslösen, obwohl Ihre Anwendung selbst kein session_start() aufruft. Ob eine Datei letztlich dauerhaft im Uploadordner landet, ist dabei eine andere Frage als die Verarbeitung der eingehenden Daten.³

Wenn Sie keine Uploads benötigen, kann die Administration entsprechende Anfragen bereits am Webserver oder vorgeschalteten Proxy ablehnen und unnötige Funktionen abschalten. Das reduziert bestimmte erreichbare Verarbeitungswege. Es beweist jedoch keine vollständige Korrektur beider CVEs. Prüfen Sie dabei auch APIs, Kontaktformulare und Webhooks, damit eine pauschale Sperre regulärer POST-Anfragen nicht unbemerkt wichtige Geschäftsabläufe unterbricht. Die verlässliche Behebung bleibt der korrigierte PHP-Build.

Diese Maßnahmen schützen wichtige andere Ebenen, beheben PHP2Shell aber nicht. Die bestätigten Angriffswege benötigen keine Anmeldung an WordPress oder einer anderen Webanwendung. Deshalb verhindert auch ein starkes Administratorpasswort mit Mehrfaktorauthentifizierung nicht, dass eine öffentliche Anfrage zuvor die verwundbare PHP-Laufzeit erreicht.

HTTPS verschlüsselt die Verbindung. Es prüft nicht, ob der Inhalt einer entschlüsselten Anfrage einen Fehler im PHP-Interpreter auslöst. Ein WordPress-Sicherheitsplugin arbeitet seinerseits als PHP-Anwendung und kann für Verarbeitungsschritte vor seinem Start zu spät kommen. Das Verschieben oder Sperren von wp-login.php schützt zudem nicht automatisch die übrigen PHP-Endpunkte.

Anders einzuordnen ist eine vollständige Zugangssperre, die Webserver, Reverse Proxy oder Firewall vor der Übergabe an PHP durchsetzen: beispielsweise eine eng begrenzte IP-Freigabe oder eine vorgeschaltete Authentifizierung. Sie kann unbekannten Internetnutzern die Erreichbarkeit nehmen. Dafür muss sie sämtliche betroffenen Pfade und Zugänge erfassen, einschließlich Subdomains und direkter Zugriffe auf den Ursprungsserver. Eine in PHP programmierte Passwortabfrage erfüllt diese Voraussetzung gerade nicht.

Behalten Sie MFA, HTTPS und den regulären Anwendungsschutz bei. Veranlassen Sie das PHP-Update zusätzlich. Falls Sie eine vorgeschaltete Sperre als Übergang einsetzen, dokumentieren Sie ihren Umfang und prüfen Sie, dass unerlaubte Anfragen PHP tatsächlich nicht mehr erreichen. Die Sperre begrenzt den Zugang; sie korrigiert den Interpreter nicht.

Eine aktive, passend konfigurierte WAF ist eine zusätzliche Schutzschicht, aber kein Grund, das PHP-Sicherheitsupdate aufzuschieben. Cloudflare beschreibt Schutzregeln gegen PHP2Shell und empfiehlt seinen Kunden ausdrücklich trotzdem das PHP-Update. Ein CDN-Vertrag oder die Nutzung eines DNS-Dienstes allein belegt noch nicht, dass der gesamte relevante Verkehr diese Regeln durchläuft.⁶

Prüfen Sie in der tatsächlich eingesetzten Konfiguration, ob der Proxy aktiv ist, die vorgesehenen Regeln im blockierenden Modus arbeiten und keine Ausnahmen betroffene URLs ausnehmen. Der Ursprungsserver darf öffentlich erreichbare PHP-Anfragen nicht an der WAF vorbei annehmen. Berücksichtigen Sie dafür alternative Hostnamen, direkte Zugänge und weitere Backend-Server. Lassen Sie den Hoster diese Absicherung bestätigen, wenn Sie die Netzkonfiguration nicht selbst verwalten.

Unterscheiden Sie außerdem, was eine Schutzregel blockiert. Eine abgewiesene Anfrage kann den Origin vollständig verfehlen. Eine Regel, die erst die Serverantwort erkennt und zurückhält, trifft ihre Entscheidung dagegen nach einer Verarbeitung am Origin. Ein Eintrag „blockiert“ beweist deshalb ohne Kenntnis des Regeltyps weder eine erfolgreiche Kompromittierung noch deren Ausschluss. Werten Sie relevante Ereignisse zusammen mit den Origin-Protokollen aus.

Halten Sie wirksame Filter während des Updates aktiv und prüfen Sie mögliche Fehlalarme bei Formularen, Zahlungen und Uploads. Dokumentieren Sie anschließend den behobenen PHP-Patchstand gesondert. Die Firewall beantwortet die Frage nach gefiltertem Verkehr; das Update beantwortet die Frage nach den Fehlern in PHP.

Teilmaßnahmen können einzelne Angriffswege unterbrechen. Die erheblichen Risiken durch andere Varianten bleiben jedoch bestehen, solange der vollständige Fix fehlt. Eine ausgeschaltete Funktion ist eine konkrete Verbesserung für den betroffenen Weg; daraus lässt sich weder eine Prozentzahl der Risikoreduktion noch eine allgemeine Freigabe für den öffentlichen Betrieb ableiten.

• session.upload_progress.enabled=0: Diese Einstellung unterbindet die bestätigten frühen Session-Verarbeitungspfade. Sie repariert andere fehlerhafte interne Zustände nicht.
• fatal_error_backtraces=0 unter PHP 8.5: Dies nimmt dem bestätigten Backtrace-Angriffsweg eine Voraussetzung. Andere Fehler- und Erweiterungszustände bleiben ein eigenes Thema.
• Deaktivierter OPcache: Ein Angriff, der dessen fehlerhaften gemeinsamen Zustand benötigt, verliert diese Voraussetzung. Daraus folgt kein Schutz vor den übrigen Varianten. Die Abschaltung kann außerdem Last und Antwortzeiten erhöhen.
• Begrenzte Anfragen: Größen- und Strukturgrenzen am Proxy oder Webserver können belastende Eingaben früher abweisen. Ein kleines post_max_size allein erfasst nicht jeden problematischen Fall.
• memory_limit=-1: Diese offizielle Übergangsmaßnahme beseitigt den gezielt erreichbaren Abbruch am PHP-Speicherlimit. Sie muss verhindern, dass Anwendungscode oder abweichende Einstellungen ein endliches Limit erneut aktivieren. Eine tatsächliche fehlgeschlagene Speicherzuteilung bleibt möglich. Gleichzeitig entfällt eine Ressourcengrenze pro Skript. Die Administration muss deshalb Kapazität und geeignete Container- oder cgroup-Grenzen berücksichtigen; RLIMIT_AS und RLIMIT_DATA eignen sich dafür laut Hersteller nicht.

Für die frühen Session- und Backtrace-Maßnahmen zählen administrativ gesetzte Werte und der Austausch aller Worker. Ein späteres ini_set() im Anwendungsskript genügt nicht; auf FPM-.user.ini sollten Sie für diese frühen Schutzwirkungen ebenfalls nicht vertrauen. Die Unterdrückung von Fehlermeldungen durch display_errors=0 oder error_reporting verhindert den zugrunde liegenden Zugriff auf fehlerhaften Zustand nicht.⁷

Fordern Sie deshalb neben der Liste der aktiven Teilmaßnahmen einen verbindlichen Plan für das vollständige Update an. Lassen Sie Wirkung, Geltungsbereich und Betriebsfolgen prüfen. Übernehmen Sie insbesondere Speicheränderungen nicht ungeprüft in ein produktives Shared-Hosting- oder Shopsystem.

Wenn Ihre öffentlich erreichbare PHP-Laufzeit ungepatcht ist und kurzfristig kein bestätigter Fix bereitsteht, sollten Sie den öffentlichen Zugriff bis zur Behebung sperren oder eng beschränken. Bei einem ungeklärten Patchstand und sensiblen Kunden-, Zahlungs- oder Zugangsdaten ist eine vorläufige Beschränkung ebenfalls die belastbarere Entscheidung als eine unbelegte Entwarnung. CERT-EU empfiehlt, bei fehlender unmittelbarer Patchmöglichkeit die Isolation öffentlich erreichbarer Anwendungen zu prüfen.²

Wirksam ist eine Maßnahme, die vor PHP greift: beispielsweise eine Sperre im Webserver oder Reverse Proxy, eine Netzfreigabe nur für die Administration oder eine statische Ersatzseite ohne Weiterleitung an die verwundbare Laufzeit. Für eine vorübergehende Wartungsantwort eignet sich ein HTTP-Status 503; die konkrete Serverkonfiguration muss sicherstellen, dass auch Fehlerseiten und direkte PHP-Aufrufe nicht doch PHP ausführen.

Ein WordPress-Wartungsplugin, eine versteckte Startseite oder das Entfernen einzelner Links reicht dafür nicht. Auch eine reine DNS-Änderung blockiert bestehende Direktzugänge nicht zuverlässig. Erfassen Sie Subdomains, APIs, Webhooks, alternative Hostnamen und Zugänge zum Ursprungsserver. Beim Shop müssen Sie zusätzlich verhindern, dass Bestellungen oder Zahlungsrückmeldungen unbemerkt verloren gehen; koordinieren Sie die Unterbrechung mit den zuständigen Diensten.

Geben Sie den Zugriff wieder frei, sobald alle relevanten Instanzen den Fix ausführen und die wichtigen Anwendungsfunktionen arbeiten. Bei konkreten Angriffsspuren gehört zuvor auch die Vorfallbehandlung dazu. Eine pauschale Abschaltung sämtlicher bereits gepatchter Websites ist dagegen nicht erforderlich.

Die zuständige Stelle richtet sich danach, wer die PHP-Laufzeit technisch verwaltet. Als Websitebetreiber sollten Sie die Zuständigkeit und den Abschluss aktiv klären. Ein Wartungsvertrag für WordPress umfasst nicht automatisch die PHP-Pakete des Hosters; umgekehrt umfasst ein Serverupdate nicht automatisch die Wartung aller Anwendungen.

• Shared Hosting und verwaltete PHP-Plattformen: Der Hoster stellt die Laufzeit bereit. Sie können häufig den Zweig auswählen, aber keine eigenen Sicherheitskorrekturen in dessen Binärpakete einbauen.
• Eigener VPS oder dedizierter Server: Ohne ausdrücklich vereinbarte Administration liegt die Umsetzung regelmäßig bei Ihnen oder Ihrem beauftragten Administrator. „Server beim Hoster“ bedeutet nicht automatisch „Softwarepflege durch den Hoster“.
• Container und mitgelieferte Laufzeiten: Der Verantwortliche für Image beziehungsweise Produktupdate muss die korrigierte Version bereitstellen; der Betreiber muss deren tatsächlichen Einsatz veranlassen und prüfen.

Eröffnen Sie beim zuständigen Support ein dringendes Sicherheitsticket mit beiden CVE-Nummern, den betroffenen Domains und den ermittelten PHP-Versionen. Fordern Sie einen Zeitpunkt für den vollständigen Rollout und eine Auskunft zu den bis dahin wirksamen Maßnahmen. Eine unverbindliche Zusage ohne Termin oder eine Antwort ausschließlich zu WordPress löst die Laufzeitfrage nicht.

Wenn der Anbieter keinen zeitnahen Fix liefern kann, klären Sie eine vorübergehende Zugangssperre oder den Wechsel auf eine nachweislich korrigierte Laufzeit. Ein kurzfristiger Umzug kann helfen, benötigt aber eine Prüfung von Datenkonsistenz, Konfiguration und Zugangsdaten. Kopieren Sie bei einem Kompromittierungsverdacht nicht einfach den gesamten möglicherweise manipulierten Bestand auf einen neuen Server.

Bevorzugen Sie kurzfristig den vollständigen Sicherheitsfix innerhalb des bereits verwendeten, unterstützten PHP-Zweigs. Ein Patchupdate von 8.5.9 auf 8.5.12 ist eine andere Änderung als ein Wechsel von 7.4 auf 8.5. Ein größerer Versionssprung kann zusätzliche Anpassungen an Anwendung, Erweiterungen und Konfiguration verlangen. Auch ein Patchupdate verdient einen Funktionscheck; vollständige Kompatibilität lässt sich nicht allein aus der Versionsnummer ableiten.

Sichern Sie vor der Änderung Dateien, Datenbank und relevante Konfiguration. Bewahren Sie die Sicherung außerhalb des öffentlich erreichbaren Webverzeichnisses auf und klären Sie die Wiederherstellung. Für Shops und Portale muss der Sicherungsstand zusammenpassen: Neue Bestellungen, Zahlungen und Uploads dürfen bei einer Rücksicherung nicht widersprüchliche Datenstände erzeugen. Halten Sie daher einen gezielten Wartungs- und Rückfallplan bereit.

Prüfen Sie nach Möglichkeit auf einer abgeschirmten Testinstanz die geschäftskritischen Funktionen: Anmeldung, Formulare, Checkout, Zahlungsrückmeldungen, E-Mail-Versand, Uploads sowie zeitgesteuerte Aufgaben. Vergleichen Sie auch benötigte PHP-Erweiterungen und Einstellungen. Ein erfolgreicher Aufruf der Startseite testet diese Abläufe nicht. Bei langer Testdauer sollten Sie den ungepatchten Produktivbetrieb inzwischen wirksam beschränken.

Falls ein Fehler auftritt, untersuchen Sie zuerst die konkrete Ursache und halten Sie die Anwendung geschützt. Ein dauerhafter Rücksprung auf eine öffentlich erreichbare, verwundbare Laufzeit ist keine tragfähige Fehlerbehebung. Für eine Altanwendung kommen ein bestätigter Anbieter-Backport, eine beschleunigte Anpassung oder eine vorübergehende Isolation infrage. Planen Sie den Versionswechsel anschließend so, dass laufende Sicherheitsupdates wieder verlässlich möglich sind.

Die Updateaufgabe endet erst, wenn die korrigierte Laufzeit alle relevanten Webanfragen verarbeitet. Eine erfolgreiche Paketinstallation allein genügt nicht. Bereits laufende Prozesse können weiterhin den alten Programmstand verwenden. Bei PHP-FPM betrifft das die entsprechenden Pools und Worker, bei mod_php die Prozesse, die das PHP-Modul geladen haben.

Die Administration muss den vorgesehenen Neustart oder kontrollierten Prozesswechsel durchführen und prüfen, dass keine alten Worker übrig bleiben. Ein Reload zählt nur dann als Abschluss, wenn er tatsächlich die nötigen Prozesse ersetzt hat. Das Leeren des WordPress-Caches, ein CDN-Purge oder ein bloßer OPcache-Reset ersetzt keine ungepatchte PHP-Binärdatei im laufenden Prozess.

Bei Containern ist das Herunterladen eines neuen Images ebenfalls nur ein Zwischenschritt: docker compose pull startet daraus keine neuen Container. Die Bereitstellung muss die laufenden Instanzen ersetzen. Prüfen Sie auch die Vorlagen für automatische Skalierung und Neustarts, damit später keine alte Image-Version zurückkehrt.⁸

Für den Abschluss brauchen Sie eine Zuordnung aus Domain beziehungsweise Anwendung, Backend oder Pool, Paket-/Imagekennung und Zeitpunkt des Prozesswechsels. Kontrollieren Sie anschließend die Laufzeit über echte Webanfragen und führen Sie den Funktionscheck durch. Ein einzelner erfolgreicher Abruf kann hinter einem Loadbalancer nur einen Server treffen; selbst mehrere identische Antworten beweisen nicht, dass alle anderen Instanzen denselben Stand verwenden. Der Rollout-Nachweis der Administration ergänzt deshalb die Laufzeitmessung. Vorherige Kompromittierungen und andere Schwachstellen bleiben getrennte Prüfaufgaben.

Eine weitere Website kann betroffen sein, wenn der kompromittierte PHP-Prozess auf deren Dateien, Daten oder Zugangsschlüssel zugreifen darf. Eine getrennte Domain ist noch keine Sicherheitsgrenze. In einem gemeinsamen Hostingkonto laufen mehrere Installationen häufig mit denselben Dateirechten oder verwenden Zugangsdaten, die mehr als eine Datenbank beziehungsweise Anwendung erreichen.

Beispiel: Eine alte Testinstallation verwendet ungepatchtes PHP und besitzt Schreibrechte auf das Verzeichnis des produktiven Shops. Ein Angreifer könnte über die Testseite Shop-Dateien verändern, obwohl der Shop selbst bereits eine korrigierte PHP-Laufzeit nutzt. Ebenso können lesbare Konfigurationsdateien den Zugriff auf weitere Datenbanken eröffnen. Das zusätzliche Risiko entsteht hier aus den gemeinsamen Berechtigungen, nicht aus einer automatischen Ausbreitung von PHP2Shell auf jede Nachbarseite.

Erfassen Sie deshalb alle Anwendungen im Konto und überprüfen Sie getrennte Betriebssystembenutzer, Dateirechte, Datenbankkonten, gemeinsam eingebundene Volumes und Secrets. Ein separater FPM-Pool allein belegt keine ausreichende Trennung, wenn beide Pools mit denselben Rechten auf dieselben Daten zugreifen. Stillgelegte Projekte sollten ihre öffentliche Erreichbarkeit und nicht mehr benötigte Berechtigungen verlieren.

Für andere Kunden beim selben Hoster gilt: Ein gemeinsamer physischer Server beweist keine gemeinsame Betroffenheit durch einen erfolgreichen Angriff auf ein einzelnes Konto. Wirksame Mandantentrennung kann den Schaden begrenzen. Lassen Sie den Hoster bei einem Vorfall die tatsächlichen Grenzen untersuchen, statt aus einem Treffer pauschal auf sämtliche Kunden zu schließen. Die allgemeine Updatepflicht für deren eigene betroffene PHP-Laufzeiten bleibt davon unabhängig.

Cloudflare berichtet am 21. Oktober 2026 über beobachteten Angriffsverkehr gegen PHP2Shell. Das belegt eine reale Bedrohung, aber keinen erfolgreichen Angriff auf Ihre Website. Für Ihren eigenen Befund müssen Sie drei Stufen unterscheiden: eine verwundbare Laufzeit, einen Angriffsversuch und nachgewiesene unbefugte Aktivitäten. Eine ältere Versionsnummer begründet zunächst Prüfbedarf. Erst der Abgleich mit dem Paket- und Backportstand klärt die technische Betroffenheit; einen Angriff beweist auch eine bestätigte Verwundbarkeit nicht.⁶

Sichern und korrelieren Sie die verfügbaren Webserver-, Proxy-, WAF-, PHP- und Systemprotokolle. Relevante Untersuchungsansätze sind ungewöhnliche Anfragefolgen zusammen mit Speicherfehlern, gehäufte Prozessabstürze, unerklärliche Änderungen an Dateien oder Konten sowie auffällige ausgehende Verbindungen. Jeder dieser Hinweise kann auch andere Ursachen haben. Eine Meldung „Allowed memory size exhausted“, ein HTTP-Fehler 500 oder ein WAF-Treffer beweist für sich weder PHP2Shell noch eine erfolgreiche Übernahme.

Prüfen Sie zusätzlich Anwendungscode, Datenbankinhalte, Administratorkonten, geplante Aufgaben und Konfiguration gegen vertrauenswürdige Vergleichsstände. Bei WordPress kann eine Prüfsummenkontrolle Abweichungen an offiziellen Core-Dateien erkennen. Sie bewertet damit aber weder sämtliche Plugins und Uploads noch Datenbankinhalte oder reine Speicherzugriffe. Auch ein unauffälliger Malware-Scan schließt einen früheren Datenabfluss nicht aus.⁹

Betrachten Sie den gesamten plausiblen Expositionszeitraum und lassen Sie Protokolle beim Hoster sichern, bevor ihre Aufbewahrungsfrist endet. Die Veröffentlichung einer Lücke markiert nicht zwingend den ersten möglichen Angriff. Wenn Belege fehlen, sollte der Abschlussbericht das präzise sagen: „In den verfügbaren Daten keine Hinweise gefunden“ ist belastbarer als die unbegründete Aussage „Es gab keinen Angriff“.

Nein. Das Update schließt die PHP-Fehler, entfernt aber keine zuvor angelegten Zugänge, manipulierten Dateien oder Datenbankänderungen. Ein bereits kompromittiertes System benötigt zusätzlich eine geordnete Vorfallbehandlung. Beginnen Sie nicht damit, einzelne verdächtige Dateien blind zu löschen und anschließend den Betrieb für bereinigt zu erklären.

1. Zugriff und Schaden begrenzen: Isolieren Sie die betroffene Anwendung beziehungsweise Instanz möglichst vor PHP. Beziehen Sie Hoster und verantwortliche Administration ein und berücksichtigen Sie erreichbare Nachbarsysteme.
2. Spuren sichern: Bewahren Sie Logs, relevante Datenstände und eine Zeitleiste auf. Stimmen Sie bei ernsthaftem Verdacht die Sicherung flüchtiger Informationen vor Neustarts mit Fachleuten ab. Verschieben Sie eine notwendige Eindämmung nicht, nur um eine perfekte Beweissicherung abzuwarten.
3. Umfang bestimmen: Untersuchen Sie Einstieg, Veränderungen, erreichbare Geheimnisse und mögliche Folgezugriffe. Ein gefundener Schadcode kann nur ein Teil des Vorfalls sein.
4. Vertrauenswürdigen Zustand herstellen: Bauen Sie betroffene Komponenten aus sauberen Quellen neu auf oder stellen Sie einen geprüften Stand wieder her. Kontrollieren Sie auch Datenbank, Konten, Uploads, Konfiguration und geplante Aufgaben. Schließen Sie den ursprünglichen Zugang vor der erneuten Freigabe.
5. Zugänge erneuern und Betrieb kontrollieren: Widerrufen Sie betroffene Tokens und Sessions, ersetzen Sie gefährdete Schlüssel und überwachen Sie das wiederhergestellte System.

Ein Backup ist nur dann hilfreich, wenn sein Zustand und seine Herkunft belastbar sind. Ein vermeintlich „frühes“ Backup kann bereits Manipulationen enthalten. Die Wiederherstellung auf dieselbe ungepatchte Laufzeit öffnet zudem den ursprünglichen Angriffsweg erneut. Trennen Sie daher Wiederherstellung, PHP-Korrektur und Ursachenanalyse als überprüfbare Aufgaben.⁹

Ein nachgewiesener oder begründet vermuteter unbefugter Zugriff erfordert die Prüfung und Erneuerung der dabei erreichbaren Geheimnisse. Eine nur festgestellte alte PHP-Version beweist dagegen noch keinen Passwortdiebstahl. Entscheidend ist, was der betroffene Prozess lesen, aus dem Speicher offenlegen oder über vorhandene Rechte erreichen konnte.

Prüfen Sie insbesondere Datenbankkennwörter, SMTP-Zugänge, Zahlungs- und sonstige API-Schlüssel, Cloud- oder Speichertokens, Anwendungspasswörter und Signaturschlüssel. Erfassen Sie auch Secrets in Umgebungsvariablen, eingebundenen Dateien und anderen Installationen desselben Kontos. Ändern Sie wiederverwendete Zugangsdaten auch an den weiteren betroffenen Stellen. Ein Angreifer kann einen entwendeten Schlüssel nach dem PHP-Update weiterhin außerhalb Ihres Webservers benutzen.

Führen Sie den Austausch von einer vertrauenswürdigen Verwaltungsumgebung aus durch. Sperren oder widerrufen Sie gefährdete Zugänge kurzfristig, wenn weiterer Missbrauch droht. Hinterlegen Sie die neuen Geheimnisse anschließend nur in einer bereinigten und gepatchten Umgebung; sonst kann ein noch aktiver Angreifer sie erneut erlangen. Stimmen Sie die Reihenfolge mit den abhängigen Diensten ab, damit beispielsweise Datenbank- und Zahlungszugänge nach dem Wechsel zusammenpassen.

Bei WordPress betrifft die Prüfung neben Administratorpasswörtern auch aktive Sitzungen, Anwendungspasswörter und die Schlüssel beziehungsweise Salts für Anmeldecookies. Für Kundenkonten zählt, ob Kontodaten, Passwort-Hashes oder aktive Sitzungen betroffen sein können. Hashes sind keine Klartextpasswörter, können aber je nach Verfahren und Passwortstärke Offline-Angriffe erlauben. Wenn Angreifer solche Anmeldedaten erlangt haben oder Sie deren Zugriff nach einer bestätigten Übernahme nicht belastbar eingrenzen können, setzen Sie die betroffenen Passwörter zurück und widerrufen Sie die Sitzungen. Informieren Sie Kunden über die nötigen Schritte und mögliche Risiken wiederverwendeter Kennwörter. Ein isolierter Wechsel des eigenen Adminpassworts reicht bei umfassender Kompromittierung nicht.

Eine verwundbare PHP-Version allein löst noch keine Datenpannenmeldung aus. Sobald eine Verletzung des Schutzes personenbezogener Daten bekannt wird, müssen Sie deren Risiken und die Meldepflichten prüfen. Dazu zählen nicht nur gestohlene Kundendaten, sondern auch unbefugte Veränderungen oder ein sicherheitsbedingter Verlust ihrer Verfügbarkeit. Beziehen Sie die zuständige Datenschutzverantwortung früh ein.

Nach Artikel 33 DSGVO meldet der Verantwortliche eine solche Verletzung der zuständigen Aufsichtsbehörde unverzüglich und möglichst innerhalb von 72 Stunden nach Bekanntwerden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten betroffener Personen. Die Frist beginnt nicht erst mit einem fertigen Forensikbericht. Wenn noch Angaben fehlen, erlaubt die DSGVO eine schrittweise Ergänzung ohne unangemessene weitere Verzögerung. Dokumentieren Sie auch eine begründete Entscheidung gegen eine Meldung.

Artikel 34 verlangt grundsätzlich zusätzlich die unverzügliche Benachrichtigung betroffener Personen, wenn voraussichtlich ein hohes Risiko für ihre Rechte und Freiheiten besteht; die dort geregelten Ausnahmen müssen im konkreten Fall greifen. Ein allgemeiner Hinweis „Wir haben PHP aktualisiert“ ersetzt eine erforderliche Benachrichtigung nicht. Diese sollte verständlich erklären, was geschehen ist, welche Folgen drohen, was Sie unternehmen, welche Schritte Betroffene ergreifen können und wer Auskunft gibt.¹⁰

Ein Hoster als Auftragsverarbeiter muss dem Verantwortlichen bekannt gewordene Datenschutzverletzungen unverzüglich melden. Seine technische Untersuchung nimmt Ihnen die eigene Bewertung nicht ab. Prüfen Sie bei einem tatsächlichen Vorfall außerdem vertragliche und gegebenenfalls branchenspezifische Meldepflichten. Eine rechtliche Einzelfallprüfung muss den konkreten Sachverhalt berücksichtigen; die bloße Bezeichnung „PHP2Shell“ entscheidet weder automatisch für noch gegen eine Meldung.