PHP2Shell: Was die kritische PHP-Sicherheitslücke für deine Website bedeutet

PHP2Shell ist der Name für zwei kritische Sicherheitslücken im Kern der Programmiersprache PHP: CVE-2026-109618 und CVE-2026-109619. Angreifer können damit ohne Login eigenen Code auf Webservern ausführen. Betroffen ist praktisch jede Website, die mit PHP läuft, also auch WordPress, WooCommerce, Shopware, TYPO3 oder Laravel. Sicher sind erst die PHP-Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21. Oktober 2026.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat die Lage mit Warnstufe 3 von 4 (Orange) eingestuft. Die Stadt Mainz, die Berliner Charité und die Ruhr-Universität Bochum haben ihre Websites am 21. Oktober vorsorglich vom Netz genommen. Erste Angriffe liefen bereits, bevor das Update verfügbar war.

Das Wichtigste vorweg: Ein Update von WordPress, Plugins oder Theme hilft hier nicht. Die Lücke steckt in der PHP-Laufzeitumgebung auf dem Server. In diesem Beitrag erfährst du, was hinter PHP2Shell steckt, wie du prüfst, ob deine Website sicher ist, und was zu tun ist, wenn sie es nicht ist.

PHP2Shell auf einen Blick

Chronologie

Gemeldet wurden die Fehler schon im August. Am Morgen des 21. Oktober meldete Cloudflare die ersten Angriffe und verteilte Firewall-Regeln an alle Kunden, auch im Gratis-Tarif. Am Nachmittag folgten die Patches.

Was technisch hinter PHP2Shell steckt

Beide Lücken entstehen, wenn PHP eine Anfrage abrupt abbricht und danach mit fehlerhaften Daten im Arbeitsspeicher weiterarbeitet. Das Gefährliche: Der Angriff greift, bevor dein CMS oder ein Security-Plugin überhaupt startet. Laut Datadog reicht schon ein PHP-Skript, das nur eine einfache Ausgabe erzeugt.

CVE-2026-109618: Codeausführung über Speicherüberlauf („RCE via OOM corruption“)

Wenn eine Anfrage das eingestellte Speicherlimit (memory_limit) sprengt, bricht PHP die Verarbeitung sofort ab. Passiert das in einem ungünstigen Moment, sind interne Datenstrukturen nur halb fertig. Die Aufräumroutine behandelt diese halbfertigen Daten anschließend als gültig. Angreifer erzwingen den Abbruch gezielt, etwa mit präparierten Datei-Uploads (multipart/form-data) mit sehr vielen Headern oder verschachtelten Feldnamen.

Bei Apache mit mod_php läuft das komplett ab, bevor Anwendungscode ausgeführt wird. Für PHP-FPM hält das PHP-Team die Lücke nach Quellcode-Analyse ebenfalls für ausnutzbar, ein vollständiger Exploit war dafür zum Zeitpunkt der Veröffentlichung aber noch nicht gezeigt.

CVE-2026-109619: Codeausführung über veralteten Zustand („RCE via stale global state“)

PHP-Worker bearbeiten nacheinander viele Anfragen. Bricht eine Anfrage mit einem schweren Fehler ab, kann ein Verweis auf bereits freigegebenen Speicher übrig bleiben. Die nächste Anfrage auf demselben Worker greift auf diesen Verweis zu, bevor PHP ihn zurücksetzt. Fachlich heißt das Use-after-free.

Bestätigt sind zwei Wege: über die Funktion session.upload_progress (standardmäßig aktiv) und, nur in PHP 8.5, über fatal_error_backtraces. Neben der Codeausführung bestätigt das PHP-Team auch, dass Arbeitsspeicher ausgelesen werden kann. Darin können Sitzungsdaten, Passwörter oder API-Schlüssel aus anderen Anfragen stehen.

Bemerkenswert ist die Entstehung: Laut Wiz waren die Fehler seit Jahrzehnten im Code. Erst moderne KI-Modelle hätten die aufwändige Angriffskette praktisch machbar gemacht.

Welche PHP-Versionen betroffen und welche sicher sind

Betroffen ist jede PHP-Version ab 5.4 bis einschließlich 8.5.11, sofern sie Web-Anfragen verarbeitet. Reine Kommandozeilen-Skripte ohne Webzugriff sind nicht das Ziel. Sicher bist du nur mit einer dieser Versionen oder einem gepatchten Paket deiner Linux-Distribution:

Achtung bei Linux-Distributionen: Die Versionsnummer allein sagt nichts. Ubuntu 24.04 LTS liefert den Fix zum Beispiel im Paket php8.3 8.3.6-0ubuntu0.24.04.13 aus, Ubuntu 22.04 LTS in php8.1 8.1.2-1ubuntu2.28. Die Anzeige „8.3.6“ ist dort also trotzdem sicher. Entscheidend ist die Paketrevision aus dem Sicherheitshinweis deiner Distribution.

Wer PHP über das Community-Repository rpms.remirepo.net bezieht, sollte laut PHP-Team auf Distributionspakete wechseln oder selbst kompilieren, weil dort am Veröffentlichungstag noch keine Updates bereitstanden.

Was du jetzt tun musst

Wer das Update einspielt, hängt davon ab, wo deine Website läuft. Im normalen Webhosting-Paket ist das dein Hoster, auf einem eigenen Server bist du es selbst.

Website im Webhosting-Paket (z. B. IONOS, Strato, All-Inkl, Hetzner, Mittwald)

Hier spielt der Hoster das PHP-Update auf seinen Servern ein. Deine Aufgabe ist, das zu überprüfen:

1. PHP-Version im Kundenmenü prüfen. Steht dort PHP 8.1 oder älter, stell auf eine aktuelle Version um. Vorher kurz testen, ob Theme und Plugins kompatibel sind.
2. Statusseite des Hosters lesen. Hetzner meldete gepatchte Versionen von PHP 7.4 und 8.0 bis 8.5 im Webhosting, später auch 5.6 und 7.3. IONOS spielte das Update auf allen Systemen ein und rechnete mit rund 24 Stunden. Mittwald und netcup nahmen ihre Webhosting-Systeme am 21. Oktober vorsorglich vom Netz.
3. Im Zweifel direkt fragen. Ein Satz an den Support reicht: „Welche PHP-Version läuft auf meinem Paket, und sind die Patches gegen CVE-2026-109618 und CVE-2026-109619 eingespielt?“

Von All-Inkl und Strato war bis zum Morgen des 22. Oktober keine öffentliche Stellungnahme zu finden. Das heißt nicht, dass nicht gepatcht wurde, aber eine Nachfrage lohnt sich.

Eigener Server, VPS oder Docker

Hier bist du selbst verantwortlich. Die Reihenfolge ist wichtig:

1. Alle PHP-Quellen finden. Distributionspakete, Drittanbieter-Repositories wie packages.sury.org, Docker-Images, Panels wie Plesk oder CloudPanel und mitgelieferte Binaries. Bei Laravel Octane mit FrankenPHP liegt die frankenphp-Binary oft direkt im Projektordner und muss separat aktualisiert werden.
2. Updates einspielen. Unter Debian oder Ubuntu zum Beispiel mit:

   sudo apt update && sudo apt upgrade
   dpkg -l | grep php   # Paketrevisionen mit dem Sicherheitshinweis abgleichen

   Docker-Images neu bauen (docker build --pull --no-cache) und ausrollen, statt laufende Container zu flicken.
3. Alle PHP-Prozesse neu starten. Ohne Neustart läuft der alte, verwundbare Code im Arbeitsspeicher weiter:

   sudo systemctl restart apache2
   sudo systemctl restart php8.3-fpm   # Versionsnummer anpassen

4. Ergebnis prüfen. Mit php -v und einer Kontrolle der laufenden Prozesse (ps aux | grep php) sicherstellen, dass kein alter Worker mehr läuft.

Wer Cloudflare vor der Website hat, bekommt zusätzlich Firewall-Regeln gegen die bekannten Angriffswege, laut Cloudflare auch im kostenlosen Tarif. Das ist eine gute zweite Linie, ersetzt aber kein Update.

Notmaßnahmen, wenn das Update nicht sofort geht

Es gibt keine Einstellung, die PHP2Shell vollständig abwehrt. Das PHP-Team sagt klar: Nur das Update ist eine sichere Lösung. Die folgenden Maßnahmen aus dem offiziellen PHP-Sicherheitshinweis verkleinern lediglich die Angriffsfläche für einzelne, bekannte Angriffswege.

Sie gehören in die globale php.ini, die FPM-Pool-Konfiguration oder die Apache-Konfiguration (etwa per php_admin_value). ini_set() im Code oder eine .user.ini helfen nicht, weil sie zu spät greifen.

; Gegen CVE-2026-109618 (Speicherüberlauf):
memory_limit = -1
post_max_size = 8M          ; 32M, falls Uploads nötig sind

; Gegen CVE-2026-109619 (veralteter Zustand):
session.upload_progress.enabled = 0
fatal_error_backtraces = 0  ; nur PHP 8.5

Dazu kommen einige Punkte, die man kennen sollte:

• memory_limit = -1 hebt PHPs eigenes Speicherlimit auf. Begrenze den Speicher dann über Container oder cgroups. RLIMIT_AS oder RLIMIT_DATA solltest du laut PHP-Team nicht nutzen, weil sie genau den verwundbaren Pfad auslösen können.
• upload_max_filesize muss unter post_max_size bleiben. Zusätzlich empfiehlt sich, Anfragegröße, Anzahl der Formularfelder und Multipart-Teile schon am Webserver oder Proxy zu begrenzen.
• Nach jeder Änderung alle Worker neu starten, sonst wirken die Einstellungen nicht.
• Datadog weist ausdrücklich darauf hin, dass session.upload_progress.enabled = 0 allein keinen Schutz bietet.

Kannst du weder patchen noch diese Maßnahmen umsetzen, raten CERT-EU und das britische NCSC, betroffene Systeme vorübergehend vom Netz zu nehmen.

Nach dem Update: Spuren prüfen und Zugangsdaten tauschen

Das Update schließt die Lücke, entfernt aber keine Angreifer, die schon vorher drin waren. Weil erste Angriffe bereits am 17. Oktober registriert wurden, solltest du jeden Server prüfen, der bis zum Patch ungeschützt erreichbar war.

Darauf achten Sicherheitsforscher von Datadog und das PHP-Team:

• ungewöhnlich große Formular- oder Upload-Anfragen in den Webserver-Logs
• Fehlermeldungen zu Speichererschöpfung („Allowed memory size exhausted“) während der Anfrageverarbeitung
• Shell-Prozesse, die vom PHP- oder Webserver-Benutzer gestartet wurden
• unbekannte .php-Dateien im Webverzeichnis (mögliche Webshells)

Wichtig: Ein erfolgreicher Angriff muss den Worker nicht zum Absturz bringen. Fehlende Auffälligkeiten im Log sind also kein Beweis, dass nichts passiert ist.

War dein Server länger ungeschützt online, tausche vorsorglich Datenbank-Passwörter, API-Schlüssel und die Geheimnisse aus .env oder wp-config.php. Der Grund ist die zweite Wirkung der Lücke: Angreifer können Arbeitsspeicher auslesen, ohne Spuren im Dateisystem zu hinterlassen.

Und ein Hinweis für den Alltag: Rechne mit Phishing-Mails, die PHP2Shell als Vorwand nutzen („Ihr Passwort muss wegen der PHP-Lücke zurückgesetzt werden“). Logge dich bei Hoster oder CMS immer direkt über die bekannte Adresse ein, nie über einen Link aus so einer Mail.

Einordnung: Lücke in PHP oder Lücke in deiner Website?

PHP2Shell ist eine Lücke im PHP-Interpreter selbst. Das ist selten und genau deshalb so ernst. Die meisten Meldungen über eine „PHP-Sicherheitslücke“ betreffen dagegen Fehler in einem CMS, Plugin oder selbst geschriebenen Skript.

Nicht verwechseln mit wp2shell: Im Juli 2026 gab es zwei kritische Lücken im WordPress-Kern unter dem Namen wp2shell. Die wurden mit WordPress-Updates (u. a. 6.9.5 und 7.0.2) geschlossen. PHP2Shell betrifft dagegen die Laufzeitumgebung darunter und lässt sich nicht per WordPress-Update beheben.

Frühere kritische Lücken im PHP-Kern

Typische Lücken im Anwendungscode

Diese Fehler entstehen im Code von Themes, Plugins oder Eigenentwicklungen. Sie lassen sich nur dort beheben:

• SQL-Injection: Nutzereingaben landen ungefiltert in Datenbankabfragen. Schutz: Prepared Statements mit PDO oder mysqli.
• File Inclusion (LFI/RFI): Dateien werden über ungeprüfte Parameter eingebunden, etwa include($_GET['page']).
• Object Injection: Fremde Daten gehen an unserialize(). Besser json_decode() nutzen.
• Cross-Site-Scripting (XSS): Eingaben werden ohne htmlspecialchars() wieder ausgegeben.

Deshalb gehören zu einer sicheren Website immer beide Ebenen: ein aktueller Server und gepflegter Code. Bei einem Website-Relaunch ist das ein guter Moment, beides gleichzeitig aufzuräumen.

Was PHP2Shell für Selbstständige und kleine Unternehmen bedeutet

Für die meisten Selbstständigen mit WordPress-Website im Webhosting-Paket ist die Lage nach dem 22. Oktober beherrschbar: Der Hoster patcht, du kontrollierst. Kritisch wird es bei drei Konstellationen:

• Veraltete PHP-Versionen (8.1 oder älter), die noch im Kundenmenü eingestellt sind
• Eigene Server oder VPS, die eine Agentur einmal eingerichtet und danach nie mehr gewartet hat
• Vergessene Projekte wie alte Landingpages, Testinstallationen oder Subdomains, die noch online sind

Gerade der letzte Punkt wird unterschätzt. Eine gehackte Nebenseite kann Spam-Links oder Schadcode verbreiten, und Google warnt dann im Zweifel in den Suchergebnissen vor deiner Domain. Das kostet Vertrauen und Sichtbarkeit, die du dir über Jahre mit Suchmaschinenoptimierung aufgebaut hast. Das gilt für klassische Google-Rankings genauso wie für die Frage, ob KI-Suchen deine Seite als Quelle nennen. Mehr dazu, warum Letzteres zählt, liest du in meinem Beitrag Lohnt sich GEO?

Gehostete Systeme wie Shopify verwalten ihre Server-Software selbst, dort musst du nichts an PHP ändern. Wie du einen solchen Shop trotzdem sichtbar machst, steht im Beitrag zur Shopify-Suchmaschinenoptimierung. Und wer als Betrieb vor allem lokal gefunden werden will, findet Tipps unter SEO für Handwerker.

Du bist unsicher, ob deine Website betroffen ist? Ich schaue mir PHP-Version, Hosting und Erreichbarkeit deiner Seite an und sage dir, was zu tun ist. Dabei prüfe ich auf Wunsch gleich mit, wie gut deine Website in Google und in KI-Antworten sichtbar ist. Buch dir ein unverbindliches Erstgespräch.

Häufige Fragen zu PHP2Shell

Was ist PHP2Shell? PHP2Shell bezeichnet zwei kritische Sicherheitslücken im Kern von PHP (CVE-2026-109618 und CVE-2026-109619), die am 21. Oktober 2026 geschlossen wurden. Sie erlauben Angreifern, ohne Anmeldung Code auf Webservern auszuführen.

Ist meine WordPress-Website betroffen? Ja, sofern der Server noch eine ungepatchte PHP-Version nutzt. WordPress selbst ist nicht fehlerhaft, läuft aber auf PHP. Prüfe beim Hoster, ob PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12 oder ein gepatchtes Distributionspaket installiert ist.

Reicht es, WordPress und alle Plugins zu aktualisieren? Nein. Die Lücke steckt in der PHP-Laufzeitumgebung auf dem Server. Nur ein PHP-Update durch dich oder deinen Hoster schließt sie.

Welche PHP-Version ist sicher? PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 sowie die gepatchten Pakete der Linux-Distributionen, zum Beispiel Ubuntu 24.04 mit 8.3.6-0ubuntu0.24.04.13. Für PHP 8.1 und älter gibt es kein offizielles Release.

Hilft es, session.upload_progress abzuschalten? Nur teilweise. Es blockiert einen bekannten Angriffsweg von CVE-2026-109619, schützt aber nicht vor CVE-2026-109618 und nicht vor anderen Varianten. Das Update bleibt Pflicht.

Woran erkenne ich, ob meine Website angegriffen wurde? Hinweise sind große, ungewöhnliche Upload-Anfragen in den Logs, Speicherfehler, Shell-Prozesse des Webserver-Benutzers und unbekannte PHP-Dateien. Ein unauffälliges Log ist aber kein Beweis. Im Zweifel Zugangsdaten tauschen.

Muss ich bei Shopify, Wix oder Squarespace etwas tun? Nein. Bei diesen gehosteten Baukastensystemen verwaltet der Anbieter die Server-Software. Du hast dort keinen Zugriff auf PHP und musst nichts aktualisieren.