PHP2Shell: Ist Ihre PHP-Website sicher? Jetzt patchen

PHP2Shell ist die Bezeichnung für kritische PHP-Sicherheitslücken, die am 21. Oktober 2026 offengelegt wurden. Wenn Ihre Website PHP verwendet, ist zunächst entscheidend, ob die Laufzeitumgebung für Ihre Besucher die Sicherheitskorrekturen enthält. Ein aktualisiertes Plugin oder ein grünes Firewall-Dashboard beantwortet diese Frage nicht.

PHP2Shell betrifft die PHP-Laufzeit unterhalb der Websites und kann die Ausführung von Code aus der Ferne ohne Authentifizierung ermöglichen. PHP hat Korrekturen in 8.2.35, 8.3.36, 8.4.27 und 8.5.12 veröffentlicht, und Sie sollten eine korrigierte Version oder einen dokumentierten Hersteller-Backport in der tatsächlich für Webanfragen verwendeten Umgebung bestätigen. Lassen Sie Schutzmaßnahmen aktiviert, betrachten Sie einen WAF oder eine vorübergehende Konfigurationsänderung aber nicht als Ersatz für das Patchen.

Stand geprüft: 21. Oktober 2026, 17:15 UTC. Dieser Leitfaden berücksichtigt die veröffentlichten Korrekturen und nicht die frühere Ankündigung einer noch ausstehenden Veröffentlichung. Prüfen Sie die verlinkten Hinweise vor Änderungen erneut, da sich Herstellerpakete und Handlungsempfehlungen schnell weiterentwickeln können.

PHP2Shell: Was wurde tatsächlich bestätigt?

Das PHP-Sicherheitsteam benennt zwei Schwachstellen, die eine entfernte Codeausführung ohne Anmeldung ermöglichen können. Sein offizieller Sicherheitshinweis stuft PHP-Installationen für Webanfragen als gefährdet ein und hebt Apache mit mod_php als Konfiguration mit dem höchsten Risiko hervor. Laufzeit, Build und Umgebung der Anfrageverarbeitung beeinflussen die Ausnutzbarkeit.

Beide Sicherheitshinweise nennen einen CVSS-v4.0-Wert von 9.2. Lesen Sie die Primärberichte zu CVE-2026-109618 und CVE-2026-109619 , statt sich auf einen vorgeschlagenen Workaround in sozialen Medien zu verlassen.

Das ist ein Grund für zügiges Handeln, aber kein Beleg dafür, dass jede PHP-Website bereits kompromittiert wurde. Eine kritische Schwachstelle, ein Angriffsversuch und ein bestätigter Einbruch sind unterschiedliche Befunde. Ihre Reaktion sollte klären, welche davon für Ihre eigenen Systeme gelten.

Welche PHP-Versionen beheben PHP2Shell?

Die heute veröffentlichten Sicherheitsversionen für unterstützte Entwicklungszweige stehen in der folgenden Tabelle. Sie ist ein Ausgangspunkt für die Prüfung einer Installation aus dem PHP-Projekt. Distributionspakete können die Korrekturen unter einer anderen Paketrevision enthalten.

Die Versionen werden in den PHP-Veröffentlichungsankündigungen bestätigt. Wenn Ihre Distribution oder Ihr Hoster Backports verwendet, verlangen Sie dessen Sicherheitshinweis und die genaue installierte Paketrevision. Eine Versionszeichenfolge allein kann ein korrigiertes Herstellerpaket oder eine veraltete eingebettete Laufzeit falsch einordnen.

PHP 8.1 und ältere Versionen erhalten keine regulären Aktualisierungen des ursprünglichen Projekts mehr. PHP hat außerdem minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt, damit aber keine fortlaufende Unterstützung wiederhergestellt. Klären Sie eine Korrektur mit verantwortlichem Hersteller-Support oder planen Sie ein Upgrade. Die PHP-Übersicht zum Support erläutert den aktuellen Status der Zweige.

Prüfen Sie Container, eingebettete PHP-Installationen und Appliances separat. Die operativen Empfehlungen des NCSC-NL warnen ausdrücklich davor, dass ein Update von PHP auf dem Host diese Laufzeiten nicht zwangsläufig aktualisiert.

Sind WordPress, Laravel und andere PHP-Websites betroffen?

Beginnen Sie beim Interpreter, der die Anwendung ausführt. Eine WordPress-Website, eine Laravel-Anwendung und ein individuelles PHP-Portal können dieselbe veraltete Laufzeit verwenden, obwohl ihr Anwendungscode völlig unterschiedlich ist. Das neueste Theme, Plugin oder Framework installiert keine Sicherheitskorrektur für die PHP-Laufzeit.

Fragen Sie bei verwaltetem Hosting, welche PHP-Version oder welches korrigierte Paket jede Website bedient, ob die Änderung alle Knoten erreicht hat und ob erforderliche Worker-Neustarts erfolgt sind. Verlangen Sie Nachweise aus der Hosting-Plattform, statt eine Benachrichtigung über ein Anwendungsupdate als Bestätigung zu deuten.

Erfassen Sie bei selbst verwalteten Systemen auch weitere Websites, Verwaltungsoberflächen, alte virtuelle Hosts und Vorschauumgebungen. Eine Produktionsanwendung kann aktualisiert sein, während eine ältere Website auf derselben Infrastruktur weiterhin öffentlich erreichbar ist. Halten Sie für jede exponierte Umgebung eine verantwortliche Person und eine Behebungsentscheidung fest.

Schließen Sie nicht aus einem ungenutzten Uploadformular, dass die Bereitstellung sicher ist. Die PHP-Sicherheitshinweise beschreiben die Anfrageverarbeitung der Laufzeit. Die für Besucher sichtbaren Anwendungsfunktionen sind keine vollständige Bewertung der Exposition.

Die Laufzeit für Besucher patchen und überprüfen

Feststellen, was tatsächlich ausgeführt wird

Ermitteln Sie die Webserver-Anbindung, das Laufzeitpaket oder Container-Image, die Konfigurationsquelle und den Serviceverantwortlichen. Ordnen Sie diese Bestandsaufnahme dem von Kunden verwendeten Hostnamen zu. Eine Prüfung des falschen Hosts kann einen überzeugenden, aber unmaßgeblichen Versionsbericht ergeben.

Diese rein lesenden Befehle ermitteln die Kommandozeileninstallation und deren Konfiguration:

1php -v
2php --ini

Sie belegen nicht, was PHP-FPM, Apache oder eine andere Webserver-Anbindung ausführt. Nutzen Sie authentifizierte Hosting-Informationen oder eine kontrollierte administrative Prüfung, um die tatsächlich verwendete Laufzeit festzustellen. Lassen Sie keine öffentliche Diagnoseseite zurück, die Konfiguration und Umgebungsdetails preisgibt.

Prüfen Sie bei Containern das Image und die Anwendungsinstanz, die tatsächlich den Verkehr erhalten, nicht nur das Ersatz-Image in einer Registry. Nehmen Sie alle Instanzen hinter dem Load Balancer und gegebenenfalls getrennte Worker-Dienste in den Änderungsnachweis auf.

Die unterstützte Korrektur anwenden und die Anwendung testen

Verwenden Sie das dokumentierte Updateverfahren der gepflegten Paketquelle oder des Image-Anbieters. Dokumentieren Sie die installierte Revision und den Herstellerhinweis zu beiden CVEs. Planen Sie Service-Neustarts oder den Austausch von Instanzen passend zur Bereitstellung, statt anzunehmen, dass ein heruntergeladenes Paket laufende Prozesse verändert.

Sichern Sie relevante Protokolle vor störenden Änderungen. Halten Sie ein geprüftes Backup und einen Wiederherstellungsplan bereit und testen Sie nach dem Update repräsentative Anwendungsabläufe. Anmeldung, Sitzungen, Kasse, Uploads und Hintergrundverarbeitung sind sinnvolle Kandidaten, sofern die Anwendung sie verwendet.

Schließen Sie die Änderung mit einer erneuten Prüfung der tatsächlich anfrageverarbeitenden Laufzeit ab. Bewahren Sie Nachweise darüber auf, welche Instanzen aktualisiert wurden, wann der Verkehr umgestellt wurde und wer die Anwendungstests abgenommen hat. Ein erfolgreich markierter Deployment-Job ist nützlich, aber nicht die gesamte Verifikation.

Schützt Cloudflare WAF vor PHP2Shell?

Cloudflare berichtet über bereitgestellte PHP2Shell-WAF-Schutzmaßnahmen für kostenlose und kostenpflichtige WAF-Kunden sowie beobachteten Angriffsverkehr. Die Ankündigung beschreibt Schutzmaßnahmen, die Anfrage- und Antwortinformationen berücksichtigen. Sie fordert Kunden ausdrücklich auf, PHP trotz dieses Schutzes zu patchen.

Prüfen Sie für die einzelne Website, ob der betreffende Verkehr tatsächlich durch den geschützten Dienst läuft und die anwendbaren Regeln aktiviert sind. Kontrollieren Sie Ausnahmen, Umgehungsregeln und jeden separat erreichbaren Ursprungsserver. Das sind Bereitstellungsprüfungen und keine Behauptung, Cloudflares Ankündigung garantiere Schutz für jeden denkbaren Zugangsweg zu Ihrer Anwendung.

Bewahren Sie WAF-Ereignisse als Teil der Untersuchung auf. Eine blockierte Anfrage kann belegen, dass eine Regel diese Anfrage erkannt hat. Sie kann nicht bestätigen, dass der Ursprung niemals anders erreicht wurde oder zuvor kein Einbruch stattgefunden hat.

Verwenden Sie den WAF als zusätzliche Schutzschicht, während Sie die PHP-Laufzeit aktualisieren. Verschieben Sie die PHP-Korrektur nicht allein deshalb, weil das Dashboard blockierte Versuche aufzeichnet.

Vorübergehende Maßnahmen sind keine vollständige PHP2Shell-Korrektur

Wenn das Patchen vorübergehend nicht möglich ist, folgen Sie gemeinsam mit dem zuständigen Techniker oder Anbieter den aktuellen PHP-Hinweisen. Der Hinweis zum veralteten Zustand erklärt, warum session.upload_progress.enabled vor dem Parsen der Anfrage deaktiviert werden muss und Worker-Neustarts erforderlich sind. Er warnt ausdrücklich davor, dafür auf ini_set() oder bei FPM auf .user.ini zu vertrauen.

Diese Änderung blockiert bestätigte sitzungsbezogene Pfade, nicht jede Variante. PHP 8.5 hat außerdem gesonderte Empfehlungen zu fatal_error_backtraces. Ein kurzer Konfigurationsausschnitt aus einem Forum ist kein Beleg dafür, dass beide Schwachstellen behoben wurden.

Der Hinweis zu Speichermangel beschreibt andere Kontrollen, darunter Anfragelimits und Änderungen am Umgang mit Speichergrenzen. Diese beeinflussen Ressourcen und Verfügbarkeit. Prüfen Sie die vollständigen, zur Bereitstellung passenden Anweisungen, statt leichtfertig Speichergrenzen auf einem Produktivserver aufzuheben.

Wenn sich die Exposition vor dem Patchen nicht vertretbar verringern lässt, besprechen Sie eine Einschränkung des öffentlichen Zugangs zur betroffenen Anwendung. Dokumentieren Sie die vorübergehende Maßnahme, ihre Grenzen, den Verantwortlichen und die geplante dauerhafte Korrektur. Ein Workaround benötigt eine Bedingung für Entfernung oder Überprüfung und darf nicht zu einer undokumentierten Dauereinstellung werden.

Was sollten Sie nach der Expositionsprüfung überwachen?

Beginnen Sie mit einem Ausgangszustand und sichern Sie den maßgeblichen Zeitraum. Korrelieren Sie Webanfragen mit PHP-, Webserver- und Hostereignissen, statt eine einzelne ungewöhnliche Anfrage als vollständige Diagnose zu behandeln. Halten Sie fehlende Protokolle ausdrücklich als Einschränkung fest.

Das sind Untersuchungsansätze, keine PHP2Shell-spezifischen Indikatoren oder Kompromittierungsnachweise. Normale Abläufe können ähnliche Symptome erzeugen. Umgekehrt belegt das Ausbleiben von Alarmen nicht, dass ein ungepatchtes System sicher war.

Wenn Hinweise auf einen Einbruch vorliegen, sichern Sie diese und organisieren Sie die Vorfallbearbeitung parallel zum Patchen. Ein Interpreter-Update beseitigt keine Persistenz, macht gestohlene Zugangsdaten nicht ungeschehen und klärt nicht, auf welche Daten zugegriffen wurde. Behandeln Sie diese Punkte im Reaktionsplan als getrennte Fragen.

Häufig gestellte Fragen

Was ist der PHP2Shell-Exploit? PHP2Shell bezeichnet die PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619. Sie betreffen die Speicherverwaltung der Laufzeit und können eine entfernte Codeausführung ohne Authentifizierung ermöglichen. Es handelt sich nicht lediglich um einen Fehler in einem WordPress-Plugin.

Welche Versionen sollte ich auf den PHP2Shell-Patch prüfen? Die am 21. Oktober 2026 veröffentlichten Korrekturen für unterstützte Zweige sind PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Verlangen Sie bei Distributions-Backports den Herstellerhinweis und bestätigen Sie die genaue korrigierte Paketrevision in der tatsächlich genutzten Webumgebung.

Behebt ein WordPress-Update PHP2Shell? Ein WordPress-Update allein aktualisiert nicht den darunterliegenden PHP-Interpreter. Halten Sie die Anwendung aktuell, prüfen Sie die Sicherheitskorrektur der PHP-Laufzeit aber separat mit Ihrem Hoster oder dem für den Server verantwortlichen Techniker.

Ist eine Website hinter Cloudflare automatisch sicher? Cloudflare berichtet über WAF-Schutzmaßnahmen, doch Verkehrsweg, anwendbare Regeln und die Erreichbarkeit des Ursprungs müssen weiterhin geprüft werden. Lassen Sie den Schutz aktiviert und patchen Sie PHP. Ein Firewall-Dashboard beweist weder eine korrigierte Laufzeit noch das Ausbleiben eines früheren Einbruchs.

Genügt es, die Upload-Fortschrittsanzeige für Sitzungen zu deaktivieren? Nein. PHP beschreibt diese Maßnahme als Blockierung bestätigter sitzungsbezogener Pfade, nicht aller Varianten. Sie muss auf der passenden Konfigurationsebene mit Worker-Neustarts umgesetzt werden. Eine korrigierte Laufzeit oder ein geprüfter Hersteller-Backport bleibt erforderlich.

Kann ich einen öffentlichen Exploit an meiner Live-Website testen? Bevorzugen Sie zunächst Versions-, Paket- und Konfigurationsnachweise. Wenn ein Exploit-Test erforderlich ist, vereinbaren Sie ihn mit ausdrücklicher Genehmigung in einer kontrollierten Umgebung mit Isolation, Überwachung und Wiederherstellungsplan. Führen Sie keine ungeprüften Exploit-Skripte auf Produktivsystemen aus.

Beweist der installierte Patch, dass der Server nicht kompromittiert wurde? Nein. Das Patchen behebt Laufzeitfehler, während die Vorfallbewertung frühere Aktivitäten, Persistenz, Zugangsdaten und mögliche Datenzugriffe untersucht. Verbinden Sie diese Arbeitsstränge und dokumentieren Sie die Grenzen der verfügbaren Belege.

Hilfe beim Prüfen, Überwachen oder Patchen Ihrer PHP-Website?

Wir können ermitteln, welche PHP-Laufzeiten Ihre Websites bedienen, die Exposition bewerten, verfügbare Protokolle und Schutzmaßnahmen prüfen und den erforderlichen Patch oder ein unterstütztes Upgrade planen. Wenn weitere Beobachtung nötig ist, können wir einen Überwachungsumfang, Alarmverantwortliche und einen Eskalationsablauf passend zu den festgestellten Risiken vereinbaren.

Unser Anwendungssicherheitsservice unterstützt Bewertung und Untersuchung, während unser Serversicherheitsservice Hosting und Konfiguration abdeckt. Wir können mit Ihrem Hoster Herstellerkorrekturen verifizieren, Änderungen koordinieren und Anwendungstests nach dem Update dokumentieren.

Ein nützliches Ergebnis hält klar fest, was geprüft und gepatcht wurde, welche Unsicherheiten bleiben und wer Folgemaßnahmen verantwortet. Wir versprechen keine Unbedenklichkeitsbescheinigung anhand einer Versionszeichenfolge oder eines einzelnen Scans. Umfang und Verfügbarkeit werden vor Arbeitsbeginn vereinbart.

Kontaktieren Sie uns für eine PHP2Shell-Expositionsprüfung, Sicherheitsüberwachung oder Patch-Unterstützung . Nennen Sie Hosting-Modell, betroffene Domains, bekannte PHP-Versionen und die Person, die Änderungen genehmigen darf. Senden Sie bei der ersten Anfrage bitte keine Passwörter oder Zugriffstoken.