PHP2Shell: Was es ist und wie Sie Ihre PHP-Website schützen

Stand 26.10.2026 geprüft anhand der PHP-Release-Notes sowie Berichten der Forscher und Sicherheitsanbieter. Wir aktualisieren diesen Beitrag, sobald PHP eine neue Version veröffentlicht.

Wenn Ihre Website mit PHP läuft, aktualisieren Sie PHP heute. Das ist die Kurzfassung dieses Beitrags.

Am 21.10.2026 veröffentlichte das PHP-Projekt Korrekturen für zwei kritische Sicherheitslücken in PHP selbst, zusammen bekannt als PHP2Shell. Sie ermöglichen es Angreifern, einen Webserver aus dem Internet zu übernehmen – ohne Login und Passwort. Die Angriffe begannen bereits vor Veröffentlichung des Fixes.

Laut W3Techs nutzen 69,2 % aller Websites mit bekanntem serverseitigem Code PHP. Dazu zählen WordPress, WooCommerce, Magento, Drupal, Joomla, Laravel und die meisten individuellen PHP-Seiten. Das ist also kein Randproblem, sondern betrifft einen großen Teil des Webs.

Für Website-Betreiber: PHP2Shell einfach erklärt

Nicht technisch? Dann ist dieser Abschnitt für Sie. PHP ist die Software auf Ihrem Webserver, die Ihre Website betreibt – vergleichbar mit dem Motor eines Autos. Wenn Ihre Website mit WordPress, WooCommerce, Magento, Drupal, Joomla oder Laravel läuft, nutzt sie PHP.

PHP2Shell bezeichnet zwei Schwachstellen in diesem System. Externe Angreifer können Ihrer Website gezielt manipulierte Anfragen senden und so die Kontrolle über den Server übernehmen – ohne Passwort oder Benutzerkonto. Das Problem liegt nicht an Ihrem Theme oder an Plugins; ein Update dieser Komponenten behebt es nicht. Nur ein Update von PHP selbst schließt die Lücke.

Sobald Angreifer Zugriff haben, können sie Passwörter und Schlüssel auf dem Server auslesen, auf Kundendaten zugreifen, Ihre Website verändern oder eine Hintertür einbauen, um später zurückzukehren. Erste Angriffe begannen noch vor Veröffentlichung des Patches – warten Sie also nicht bis nächsten Monat.

Was Sie heute tun sollten:

1. Stellen Sie Ihrem Entwickler oder Hosting-Anbieter diese eine Frage: „Läuft unser PHP in einer Version, die PHP2Shell behebt, und wurde PHP danach neu gestartet?“ Bitten Sie um eine schriftliche Ja-oder-Nein-Antwort.
2. Wenn die Antwort nein oder „nicht sicher“ ist, fordern Sie eine Behebung noch heute. Läuft Ihre Website auf einer alten PHP-Version (8.1 oder älter), gibt es kein fertiges Update – dann ist jetzt ein Upgrade-Plan nötig.
3. Wenn das Problem bereits behoben ist, lassen Sie den Server auf Angriffsversuche seit dem 17. Oktober prüfen und alle gespeicherten Passwörter und Schlüssel ändern.
4. Wenn niemand Ihren Server betreut oder Sie keine Antwort bekommen, holen Sie sich jetzt Unterstützung. Jeder Tag, an dem eine ungepatchte Website online bleibt, erhöht das Risiko.

Wenn Ihr Shop auf Shopify oder einer vergleichbaren gehosteten Plattform läuft, müssen Sie nichts tun: Die Plattform betreibt die Server, nicht Sie.

Die Kurzfassung

• Aktualisieren Sie PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 (oder neuer), und starten Sie anschließend PHP-FPM, Apache oder jeden anderen lang laufenden PHP-Worker neu. Ein Update von WordPress, Magento oder Ihren Plugins aktualisiert PHP nicht.
• Bei PHP 8.1 oder älter gibt es kein fertiges offizielles Update. Wechseln Sie auf eine unterstützte Version oder nutzen Sie ein Hosting- oder Linux-Paket, das beide Fixes zurückportiert hat.
• Können Sie heute nicht aktualisieren? Aktivieren Sie die PHP2Shell-Regeln Ihrer Web Application Firewall und die PHP-Einstellungen aus Schritt 4 unten. Das senkt das Risiko, macht Ihre Seite aber nicht sicher.
• Nach dem Update sollten Sie alle auf dem Server gespeicherten Geheimnisse als potenziell kompromittiert betrachten und ab dem 17.10.2026 nach Anzeichen eines Angriffs suchen.

Was ist PHP2Shell?

PHP2Shell ist der Name, den die Forscher zwei Schwachstellen in der PHP-Engine und dem Exploit-Skript, das sie kombiniert, gegeben haben. Die Fehler liegen nicht in Ihrem Theme, Plugin oder Code, sondern in PHP selbst – der Software, die Ihre Seite auf dem Server ausführt.

Deshalb ist das Problem so gravierend. Die Forscher von Wiz sagen, dass selbst eine einfache „Hello World“-Anwendung auf einer betroffenen PHP-Version verwundbar sein kann. Für Server mit Apache und mod_php gibt PHP selbst an, dass ein Exploit „vor Ausführung jeglichen Anwendungscodes“ funktioniert. Ihre Seite kann also gefährdet sein, selbst wenn Ihr eigener Code fehlerfrei ist.

Konkret: Wenn eine Anfrage dazu führt, dass PHP der Speicher ausgeht (oder ein anderer schwerwiegender Fehler im falschen Moment auftritt), bricht PHP die Anfrage sofort ab und räumt an manchen Stellen nicht sauber auf. Unvollständige oder eigentlich zu löschende Daten bleiben zurück und werden später von PHP als gültig behandelt – teils sogar bei der nächsten Anfrage desselben Workers. Ein Angreifer kann dies gezielt mit speziell präparierten Formular-Uploads auslösen, auch auf Seiten, die eigentlich keine Uploads nutzen, und so eigene Befehle ausführen.

RCE steht für Remote Code Execution: Jemand aus dem Internet kann eigenen Code auf Ihrem Server ausführen. OOM bedeutet Out of Memory. PHP bewertet beide Fehler mit 9,2 von 10 (kritisch) nach dem aktuellen CVSS 4.0. Die US National Vulnerability Database nutzt noch CVSS 3.1 und bewertet sie mit 9,8 (kritisch) und 8,1 (hoch); diese Zahlen können Ihnen ebenfalls begegnen. Der Name PHP2Shell beschreibt das Ergebnis: Von einer normalen PHP-Website direkt zur „Shell“, also voller Befehlszugriff auf den Server.

Was kann ein Angreifer konkret tun?

• Befehle auf Ihrem Webserver ausführen – ohne Benutzername oder Passwort.
• Geheimnisse aus dem Arbeitsspeicher des Servers auslesen. Wiz nennt „Passwörter, Authentifizierungstokens, API-Schlüssel und Zertifikate“. Dafür muss der Angreifer nicht einmal eigenen Code auf Ihrem Server ausführen – der Angriff bleibt also leise und schwer zu bemerken.
• Diese Geheimnisse nutzen, um Zugriff auf Ihre Datenbank, Kundendaten und Zahlungsanbieter-Konten zu erhalten.
• Eine versteckte Hintertür (eine „Web Shell“) platzieren, um später zurückzukehren oder Ihre Website zu verändern und zu beschädigen.

Wie es zu PHP2Shell kam

Die Schwachstellen wurden im August gemeldet, während PHP an einer Lösung arbeitete, geheim gehalten und nach dem Leak der CVE-Nummern vorzeitig veröffentlicht.

Laut der PHP Foundation wurden die beiden CVE-Nummern am 20. Oktober ohne technische Details bekannt, allerdings enthüllte ein versehentlich veröffentlichtes Video eines Forschungsunternehmens einige begrenzte Einzelheiten. Die Foundation berichtet außerdem, dass ein PHP-Core-Entwickler bereits 2024 im Rahmen eines Audits erste Hinweise auf das Out-of-Memory-Problem gesehen hatte, das damals jedoch nicht behoben wurde.

Warum es diesmal so schnell ging

KI hat einen Großteil der Analyse übernommen. Wiz gibt an, eigene KI-Modelle (Wiz Atlas), Googles Gemini 4 Argon und OpenAI GPT-5.6 Sol eingesetzt zu haben. „Ein einzelner Forscher schaffte in einer Woche, wofür früher ein Spitzenteam Monate gebraucht hätte.“ OpenAIs Codex Security Team und Calif werden neben Wiz auf der PHP2Shell-Website genannt.

Angreifer verfügen über die gleichen Werkzeuge. Amazons Threat-Intelligence-Team warnt, dass KI es günstiger macht, aus einem Patch einen funktionierenden Exploit zu entwickeln. „Mehr Akteure können innerhalb von Stunden oder sogar Minuten handeln.“ Die Empfehlung für kritische Schwachstellen in internet-exponierten Systemen: „Patch- und Mitigationszeiten in Stunden messen.“

Wer ist von PHP2Shell betroffen?

Die offiziellen PHP-Releases decken 8.2 bis 8.5 ab, für 7.4, 8.0 und 8.1 gibt es nur Quellcode-Patches. Laut den Forschern sind betroffene Versionen bis PHP 5.4 zurück betroffen, nahezu jede PHP-Version weist mindestens einen der beiden Fehler auf. Wenn Ihre Website, Ihr Shop oder Ihre Webanwendung auf PHP läuft und Sie PHP seit dem 21.10.2026 nicht aktualisiert haben, sollten Sie davon ausgehen, betroffen zu sein.

ProjectDiscoverys Liste nennt rund 20 Arten von langlaufender PHP-Software, die Sie prüfen sollten. Alles, was auf PHP basiert, ist betroffen, darunter:

• WordPress und WooCommerce, Magento / Adobe Commerce, Laravel, Drupal und Joomla-Seiten
• Moodle, Nextcloud und MediaWiki
• Admin-Tools wie phpMyAdmin, Roundcube-Webmail und WHMCS
• Hosting-Panels wie cPanel und Plesk
• Netzwerkgeräte mit PHP, von Firewalls (pfSense, OPNsense) über Telefonsysteme (FreePBX) bis zu Monitoring-Tools (Zabbix, Nagios XI). Die Hersteller veröffentlichen eigene Hinweise; HPEs für ClearPass Policy Manager ist ein Beispiel.

Das Ausmaß ist enorm. Laut Zahlen, die am Tag der Fehlerbehebung veröffentlicht wurden, zählte VulnCheck PHP auf 2.608.039 öffentlich erreichbaren Hosts in den vorangegangenen 30 Tagen und bewertete 99,998 % davon als verwundbar oder wahrscheinlich verwundbar. Über 1,1 Millionen davon, etwa 42 %, laufen mit PHP-Versionen, für die es keine offiziellen Sicherheitsupdates mehr gibt, und etwa 27 % nutzen PHP 7.3 oder älter. Viele Hosts verbergen ihre PHP-Version, daher ist ein Teil der Zahlen eine Schätzung von VulnCheck.

Wer ist nicht betroffen

• Vollständig gehostete Plattformen wie Shopify, bei denen die Plattform die Server betreibt, nicht Sie. Jedes WordPress-Blog oder PHP-Tool, das Sie daneben betreiben, muss dennoch geprüft werden.
• Websites ohne PHP auf dem Server: Node.js, Next.js, Python oder reines statisches HTML.
• Server, die bereits auf die unten genannten, behobenen Versionen aktualisiert und seitdem neu gestartet wurden. (Beachten Sie den dritten Fehler weiter unten.)

Behobene PHP-Versionen

Wenn Sie PHP 8.2 einsetzen: Die Sicherheitsunterstützung endet am 31.12.2026. Planen Sie den Umstieg auf 8.4 oder 8.5 jetzt, statt zweimal zu patchen. Die grundsätzliche Frage beleuchten wir in Ist PHP noch die richtige Wahl für E-Commerce.

Werden PHP2Shell-Angriffe bereits durchgeführt?

Ja. Erste Angriffsversuche begannen noch vor der Veröffentlichung der Fehlerbehebung.

• Vier Tage zu früh: MadPot-Honeypots von Amazon (Lockvogel-Server, die Angreifer anziehen sollen) registrierten einen PHP2Shell-Angriffsversuch am 17.10.2026, vier Tage vor der öffentlichen Bekanntmachung.
• Vor der Veröffentlichung: Amazon meldet Proof-of-Concept-Exploits ab etwa 02:00 UTC am 21. Oktober, zwölf Stunden vor Bereitstellung der behobenen Versionen, und weitere in den darauffolgenden Stunden. Inzwischen spricht Amazon von „breiten Ausnutzungsversuchen in freier Wildbahn“.
• Automatisierte Scans: VulnCheck beobachtete Scanner mit dem User-Agent php2shell-scan/109618 und einen Versuch von einer IP-Adresse aus China, über eine Session-Datei eine Webshell zu platzieren. Dieser Versuch schlug fehl.
• Gefälschte Exploits: Gefälschte Proof-of-Concept-Repositories kursieren auf GitHub. Führen Sie niemals heruntergeladene Exploit-Codes auf einem produktiven Server aus.

Einige Organisationen gingen vorsorglich offline. Laut den auf Wikipedias PHP2Shell-Seite gesammelten Medienberichten nahmen viele europäische Organisationen ihre Websites auf Empfehlung von CERT-EU und dem britischen NCSC offline, und die US-NSA empfahl, offline zu gehen, falls ein sofortiges Update nicht möglich war. Finnland schaltete öffentliche Regierungsdienste ab, und das Internet Archive war vorübergehend nicht erreichbar.

Ein dritter, weniger kritischer Fehler (23. Oktober)

Zwei Tage nach der Hauptkorrektur veröffentlichte PHP eine Information zu einer verwandten Schwachstelle, CVE-2026-115560, im selben Session-Upload-Progress-Feature. Laut Cloudflare betrifft sie auch die bereits aktualisierten Versionen, einschließlich 8.5.12. PHP bezeichnet sie als „unwahrscheinlichen RCE-Vektor“, der eine ungewöhnliche Session-Konfiguration voraussetzt. Bis zum nächsten regulären PHP-Release empfiehlt PHP, session.upload_progress.enabled=0 zu setzen.

So schützen Sie Ihre PHP-Website: fünf Schritte

Nur ein PHP-Update behebt das Problem vollständig. Die Sicherheitsmeldung von PHP ist eindeutig: „Es gibt keine vollständigen Gegenmaßnahmen, ein Update ist die einzige sichere Option.“ Gehen Sie diese Schritte der Reihe nach durch.

Schritt 1: Alle Orte finden, an denen PHP läuft

Erstellen Sie eine Liste aller Server, Websites und Tools, die Sie besitzen und die PHP verwenden. Vergessen Sie dabei nicht:

• Staging- und Testkopien Ihrer Website
• Alte Kampagnenseiten oder Landingpages, die von einer Agentur erstellt wurden
• Admin-Tools wie phpMyAdmin oder Webmail
• Docker-Container, die auf einem alten php:-Image basieren
• Hosting-Panels und Netzwerkgeräte

Vergessene Websites werden leicht übersehen und selten gepatcht. Prüfen Sie außerdem, ob Port 9000 von PHP-FPM nicht aus dem Internet erreichbar ist: ProjectDiscovery weist darauf hin, dass offizielle php-fpm-Docker-Images auf allen Netzwerkschnittstellen lauschen. Wenn Sie einen Codebestand oder Server übernommen haben, den niemand vollständig versteht, ist unser Legacy-PHP-Due-Diligence-Framework ein guter Einstieg.

Schritt 2: PHP-Version prüfen

• Shared Hosting oder cPanel: Im Hosting-Panel unter „Select PHP Version“ oder „MultiPHP Manager“ nachsehen.
• Eigener Server (VPS): Führen Sie php -v und php-fpm -v auf dem Server aus. Auf manchen Systemen trägt der FPM-Befehl die Version, z. B. php-fpm8.3 -v.
• WordPress: Gehen Sie zu Werkzeuge → Website-Zustand → Info → Server.

Vergleichen Sie die Version mit der oben genannten Tabelle der behobenen Versionen. Wenn Ihr Hoster oder Ihre Linux-Distribution Fixes zurückportiert, prüfen Sie das Paket-Changelog auf beide CVE-Nummern statt nur auf die Versionsnummer.

Schritt 3: PHP aktualisieren und neu starten

Installieren Sie die behobene Version und starten Sie Apache, PHP-FPM, LiteSpeed und alle lang laufenden PHP-Worker neu. Die Empfehlung der Forscher lautet: „Installieren Sie ein behobenes PHP-Release auf jedem Laufzeitsystem und starten Sie es neu.“ Ohne Neustart bedient das alte PHP weiterhin Anfragen. Wenn Sie Apache mit mod_php betreiben, aktualisieren Sie diese Server zuerst – PHP stuft sie als höchstes Risiko ein.

Ein Update von WordPress, Magento oder Ihren Plugins aktualisiert nicht PHP. PHP ist eine eigenständige Software auf dem Server. Für Docker: Bauen Sie Ihr Image auf einem behobenen php:-Basisimage neu und stellen Sie es erneut bereit.

Schritt 4: Wenn ein Update heute nicht möglich ist

Diese Maßnahmen senken das Risiko nur kurzfristig. Die PHP-Sicherheitsmeldung sagt, solche Maßnahmen „reduzieren die Angriffsfläche für bestimmte Angriffspfade, machen eine Installation aber nicht sicher“. Manche Einstellungen können Uploads beeinträchtigen – prüfen Sie Ihre Seite nach jeder Änderung.

• Aktivieren Sie die PHP2Shell-Regeln Ihrer Web-Firewall. Cloudflare hat die Regeln auf allen Tarifen mit WAF, auch Free, automatisch aktiviert. Fortinet nennt Schutz für FortiWeb und FortiGate in seiner Outbreak-Meldung. Für den Fehler vom 23. Oktober deckt die Cloudflare-Regel keine Seiten ab, die session.upload_progress.name umbenannt haben.
• Deaktivieren Sie Upload-Progress: Setzen Sie session.upload_progress.enabled=0 in php.ini oder der PHP-FPM-Pool-Konfiguration und starten Sie alle Worker neu. Die Einstellung per ini_set() oder .user.ini funktioniert hier nicht.
• Begrenzen Sie die Größe von Request-Bodys: Setzen Sie post_max_size auf 8M, wenn keine Uploads nötig sind, oder auf 32M, wenn Uploads erforderlich sind. Amazon empfiehlt außerdem, auf nicht gepatchten Servern Multipart-Uploads zu blockieren.
• Unter PHP 8.5 setzen Sie zusätzlich fatal_error_backtraces=0 und starten Sie alle Worker neu.
• Nehmen Sie die Website offline oder schützen Sie sie mit einem Login, falls sie sensibel ist. So haben es mehrere Behörden gehandhabt.

Schritt 5: Nach dem Update prüfen, ob ein Angriff stattfand

War der Server vor dem Update aus dem Internet erreichbar, gehen Sie davon aus, dass Geheimnisse im Speicher kompromittiert sein könnten. Prüfen Sie rückwirkend mindestens bis zum 17.10.2026, dem frühesten von Amazon gemeldeten Angriff.

• Ändern Sie Datenbankpasswörter, API-Keys, Payment-Gateway-Keys, SMTP-Passwörter und Schlüssel zur Signierung von Sessions (z. B. WordPress Salts oder den Magento-Verschlüsselungsschlüssel mit einem Entwickler, sofern sicher möglich).
• Suchen Sie nach neuen oder unbekannten Admin-Nutzern, neuen oder veränderten PHP-Dateien (insbesondere in Upload- und Session-Ordnern) und neuen geplanten Aufgaben (Cronjobs).
• Prüfen Sie die Request-Logs auf POST-Uploads mit PHP_SESSION_UPLOAD_PROGRESS (Amazon) sowie auf Multipart-Anfragen, denen Fehlermeldungen wie „Allowed memory size of … bytes exhausted“, wiederholte 500-Fehler oder PHP-Worker-Abstürze folgen (Wiz).
• Achten Sie auf ungewöhnlich große oder fehlerhafte PHPSESSID-Cookies in Antworten (Wiz) und auf den Text PWNED:: in Antworten oder Session-Dateien (VulnCheck).
• Suchen Sie nach unbekannten Prozessen und unerwarteten ausgehenden Verbindungen vom Server.

Wenn Sie Auffälligkeiten finden, holen Sie sich Expertenhilfe, bevor Sie aufräumen, damit keine Beweise verloren gehen.

Fazit

PHP2Shell ist eines der schwerwiegendsten Web-Sicherheitsprobleme der letzten Jahre. Es betrifft PHP selbst, ist direkt aus dem Internet ohne Login erreichbar, und Angreifer haben es bereits vor Veröffentlichung der Korrektur aktiv versucht.

Die Lösung ist einfach: PHP aktualisieren, neu starten und alle Server prüfen. Warten Sie nicht bis nächste Woche. Nutzen Sie die Gelegenheit, um alles auf End-of-Life-PHP außer Betrieb zu nehmen. Wenn eine komplette Legacy-Anwendung Sie blockiert, haben wir einen Leitfaden zum Umstieg eines Legacy-PHP-Monolithen auf Laravel ohne Feature Freeze geschrieben.

Brauchen Sie Unterstützung beim Patchen von PHP2Shell?

Wir betreuen und entwickeln täglich WordPress- und WooCommerce-, Magento-, Laravel- und individuelle PHP-Websites. Wir finden alle Ihre PHP-Seiten und Server, aktualisieren PHP sicher und starten es neu, richten eine Web-Firewall ein, rotieren Passwörter und Schlüssel, prüfen auf Hinweise auf Angriffe und migrieren alte Seiten von End-of-Life-PHP 7.x, 8.0 und 8.1.

Kontaktieren Sie uns oder schreiben Sie an info@stathmosgroup.com. Wir beginnen mit Ihrem am stärksten exponierten Server.