PHP2Shell: Was die kritischen PHP-Lücken bedeuten und was statische Websites ändern

Am 21. Oktober 2026 haben die PHP-Entwickler Notfall-Updates für zwei kritische Schwachstellen veröffentlicht: CVE-2026-109618 und CVE-2026-109619, zusammen als „PHP2Shell“ bekannt. Beide können unter Umständen ohne Anmeldung zur Ausführung fremden Codes auf dem Server führen. Behörden in Finnland und den Niederlanden haben Websites vorsorglich abgeschaltet. Dieser Beitrag ordnet ein, was belegt ist, was noch unklar bleibt und was die Lücken über die Architektur von Websites sagen. Stand ist der 22. Oktober 2026; die Lage ändert sich schnell.

Kurz gesagt

• Die Fehler stecken im PHP-Interpreter selbst, nicht in WordPress, Magento oder einem Plugin. Ein Update der Anwendung genügt nicht.
• Gepatcht sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Nur das Update ist eine vollständige Lösung.
• Beide Lücken erreichen die Schwelle „kritisch“ mit einem CVSS-v4.0-Wert von 9,2.
• Es gibt Angriffsversuche. Ob sie bereits erfolgreich waren, wird unterschiedlich berichtet.
• Eine statisch ausgelieferte Website führt keinen PHP-Code pro Anfrage aus und ist von dieser Klasse von Lücken nicht betroffen. Das gilt nicht für das gesamte Umfeld, also CMS, Formulare und Build-Systeme.

Was ist passiert?

Laut PHP-Team und mehreren Sicherheitsunternehmen verlief der Ablauf so (Zeiten UTC):

• 20. Oktober: Details sickern vor der geplanten Veröffentlichung durch. Das PHP-Team zieht den Termin vor.
• Früh am 21. Oktober: Mehrere Betreiber nehmen Dienste vorsorglich vom Netz. Gegen 07:43 meldet Cloudflare erste Angriffe und stellt WAF-Regeln bereit.
• Gegen 14:00: PHP veröffentlicht die korrigierten Versionen.
• Am Nachmittag: watchTowr meldet Exploit-Versuche in freier Wildbahn, etwa mit User-Agents, die „php2shell“ enthalten.

Die Forscher von Calif zeigten in einem Video, wie sie auf einem Laravel-Server innerhalb von 38 Sekunden Systembefehle ausführen. Nach Angaben von Sansec bestätigten Forscher die Ausnutzbarkeit gegen aktuelle Versionen unter anderem von WordPress, Drupal, Joomla, Magento, Nextcloud und phpMyAdmin.

Die Ursachen

Das PHP-Team beschreibt die beiden Fehler als Probleme bei der Speicherverwaltung einer einzelnen Anfrage:

• CVE-2026-109618: Wenn PHP während des Aufbaus einer Anfrage nicht genug Speicher hat, kann es unterbrochen werden, während Anfragedaten erst teilweise initialisiert sind. Die anschließende Bereinigung behandelt diese ungültigen Daten als gültig.
• CVE-2026-109619: Anfragebezogener interner Zustand bleibt bestehen, obwohl der zugehörige Speicher freigegeben wurde. Eine spätere Anfrage im selben Worker kann diesen veralteten Zustand verwenden.

Bekannte Auslöser sind das Verarbeiten von multipart/form-data-Anfragen, der Upload-Fortschritt von Sessions und, in PHP 8.5, Backtraces bei Fatal Errors. Die Angreifer müssen dafür keine Anmeldung und keine verwundbare Anwendungslogik treffen: Der Fehler tritt auf, bevor Anwendungscode läuft. Deshalb hilft auch eine saubere Applikation nicht.

Nach Angaben von Wiz sind alle Versionen von PHP 5.4 bis 8.5.11 betroffen. Der verwundbare Code ist damit rund 14 Jahre alt. Die Dimension ergibt sich aus der Verbreitung: PHP läuft hinter WordPress, Drupal, Joomla, Magento und vielen Programmen, bei denen man es nicht erwartet, etwa in Control Panels, NAS-Systemen und Routern.

Wer ist besonders betroffen?

Die Entwickler sehen das größte Risiko bei mod_php. Betroffen sind aber nach Angaben von Sansec und Huntress alle Betriebsarten, die Webanfragen bedienen, darunter PHP-FPM, php-cgi und LiteSpeed. Red Hat bewertet das praktische Risiko für Standardinstallationen mit PHP-FPM niedriger, weil die Ausnutzung dort präzise Speichermanipulation und Timing voraussetze. Beide Einschätzungen können zugleich stimmen: Schwerer auszunutzen heißt nicht sicher.

Ein besonderes Problem sind Versionen, die nicht mehr gepflegt werden. Hier widersprechen sich die Quellen: Wiz nennt PHP 8.1 und älter als „nicht gepatcht“, heise berichtet von angekündigten Backports für 7.4, 8.0 und 8.1. Wer so alte Versionen betreibt, sollte sich direkt beim Hoster oder Distributor nach einem Backport erkundigen und ansonsten auf eine unterstützte Version wechseln. Das empfiehlt auch das britische NCSC.

Warum wurden Websites abgeschaltet?

Das ist der Teil, der am meisten Aufmerksamkeit bekam. Belegt sind folgende Abschaltungen, jeweils vorsorglich:

• Finnland: Der staatliche IT-Dienstleister Valtori nahm laut Yle am frühen Nachmittag des 21. Oktober Webdienste vom Netz, darunter die Website des Landesvermessungsamts. Valtori betonte, es handle sich um eine Vorsichtsmaßnahme ohne bestätigten Angriff.
• Niederlande: Laut Security.NL waren DigiD, MijnOverheid, Overheid.nl, TweedeKamer.nl und die Belastingdienst-Seiten zeitweise nicht erreichbar. Ein großer Teil war am selben Tag wieder online.
• Datenschutz-Organisation noyb: zog laut The Register die eigene Website vorübergehend zurück.
• Uberspace: kündigte laut heise an, PHP-Dienste vorübergehend komplett abzuschalten.
• Japan: Patchstack nennt unter Berufung auf ITmedia Notfallwartungen unter anderem bei Sakura Rental Server.

Eine Einordnung gehört dazu: Die Quellen belegen vorsorgliche Abschaltungen einzelner Betreiber. Eine Liste „großer Hoster, die ihre Kundenseiten komplett abgeschaltet haben“ konnte ich nicht belegen. Andere Hoster berichten eher von eingeschränkten Funktionen: Serverprofis deaktivierte vorübergehend Datei-Uploads, IONOS plante die Updates auf allen Systemen. Zu einzelnen Berichten, etwa über weitere Medienseiten, fand ich keine verlässliche Bestätigung und nehme sie deshalb nicht auf.

Der Hintergrund war die Zeitlücke. CERT-EU und andere Behörden empfahlen, betroffene Anwendungen vom öffentlichen Netz zu trennen, wenn sie nicht rechtzeitig gepatcht werden können. Zwischen Bekanntwerden und Patch lagen Stunden, in denen ein Angriff möglich war und der Fix noch fehlte. Wer Bürgerportale betreibt, nimmt dann lieber Verfügbarkeit in Kauf als eine Übernahme.

Welche Auswirkungen sind realistisch?

Im schlimmsten Fall führen Angreifer Befehle auf dem Server aus, installieren Hintertüren, lesen Daten aus und verändern Seiten. Zusätzlich lässt sich laut Sansec der Speicher eines Workers auslesen, in dem Passwörter, Tokens oder API-Schlüssel anderer Anfragen liegen können. Das macht eine Prüfung nach dem Update wichtig: Ein Patch entfernt keine Hintertür, die zuvor platziert wurde.

Zum Umfang gibt es bislang keine belastbaren Zahlen zu erfolgreichen Einbrüchen. Previdian berichtet laut Security.NL, die Angreifer hätten es nicht geschafft, Code auszuführen oder Dateien hochzuladen. Patchstack sah bis zum Nachmittag nur Sondierungen. Die Zahl von über 22 Millionen potenziell verwundbaren Instanzen, die Palo Alto Networks nennt, beschreibt die Angriffsfläche, nicht den Schaden. Mit öffentlichen Details ist mit breiter Ausnutzung zu rechnen.

Was Sie jetzt tun sollten

1. PHP-Installationen inventarisieren. Eingeschlossen sind Container, Staging-Systeme, Control Panels und Geräte mit eingebettetem PHP.
2. Updaten. Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 beziehungsweise das gepatchte Paket des Distributors. Bei Shared Hosting ist der Hoster zuständig; fragen Sie nach dem Stand.
3. Wenn das nicht sofort geht, überbrücken. Das PHP-Team nennt unter anderem session.upload_progress.enabled=0, fatal_error_backtraces=0 (nur PHP 8.5), memory_limit=-1 mit Limit auf Container-Ebene und ein niedriges pm.max_requests für PHP-FPM. Auch das Blockieren von multipart/form-data am Webserver hilft, bricht aber Uploads und teils Formulare. Das PHP-Team bezeichnet diese Maßnahmen als „temporary crutch“, also Notbehelf.
4. Notfalls vom Netz nehmen oder nur lesend betreiben. Praktikabel ist ein Betrieb, der nur GET und HEAD zulässt. Den PHP-Handler allein abzuschalten ist keine Lösung, weil dann Quellcode im Klartext ausgeliefert werden kann.
5. Auf Kompromittierung prüfen. Auffällig sind ungewöhnliche Multipart-Anfragen, Memory-Limit-Fehler, abstürzende Worker, große PHPSESSID-Cookies und PHP-Prozesse, die eine Shell starten. Danach Zugangsdaten rotieren, die auf dem Server liegen.
6. Mitigationen zurücknehmen und die Wirkung nach dem Update prüfen.

Wirkungslos sind laut den Hinweisen des PHP-Teams unter anderem display_errors=0, file_uploads=Off, Laufzeit-Einstellungen per ini_set() und Schutzmaßnahmen innerhalb der Anwendung. Ein Plugin kann diese Lücke nicht schließen.

Die Brücke zu statischen Websites

Statische Auslieferung löst nicht alle Sicherheitsprobleme. Sie verändert aber, welche Angriffsfläche im Betrieb überhaupt existiert.

Was sich ändert. Eine mit Astro gebaute Website besteht beim Ausliefern aus fertigen HTML-, CSS-, JavaScript- und Bilddateien. Der Webserver liest sie von der Platte oder aus einem CDN und gibt sie zurück. Es läuft kein Interpreter pro Anfrage, kein Speicher wird für eine PHP-Anfrage aufgebaut, und es gibt keinen Worker mit Zustand, der sich zwischen Anfragen erhalten könnte. Die Bedingung, die beide Lücken voraussetzen, ist auf der öffentlichen Seite schlicht nicht vorhanden. Bei der Abschaltung der Behördenseiten war das der entscheidende Punkt: Statische Seiten hätten nicht abgeschaltet werden müssen.

Was gleich bleibt. Folgendes sollten Sie nicht übersehen:

• Das CMS dahinter. Wird Astro mit WordPress als Redaktionssystem betrieben, siehe Headless WordPress, läuft dieses PHP weiter. Es lässt sich aber vom öffentlichen Netz trennen: Das Backend braucht keine öffentliche Adresse, nur der Build greift darauf zu. Genau diese Trennung hätte am 21. Oktober die Entscheidung erleichtert.
• Dynamische Funktionen. Kontaktformulare, Suche, Kommentare und Shops brauchen weiterhin ein Backend oder einen Dienst. Dessen Sicherheit hängt von seiner Technik ab, nicht von Astro.
• Die Lieferkette. Build-Pipeline, npm-Abhängigkeiten, Deployment-Zugänge und DNS sind eigene Angriffsflächen. Ein statisches Ergebnis ist nur so vertrauenswürdig wie der Prozess, der es erzeugt.
• Fehlkonfiguration. Auch statische Hosts können falsch eingerichtet sein, etwa mit offenen Verzeichnislisten oder geleakten Zugangsdaten.

Der Preis. Statisch bedeutet, dass sich Inhalte erst nach einem Build ändern, dass Vorschau und Freigabe geplant werden müssen und dass dynamische Funktionen gesondert gelöst werden. Das ist kein Nachteil, wenn die Website überwiegend Inhalte präsentiert; für eine Anwendung mit Konten und veränderlichen Daten ist es das falsche Werkzeug. Wie diese Abwägung aussieht, beschreibt Astro oder WordPress, und die Grundlagen finden Sie in Static Site Generation.

Was Sie daraus mitnehmen können

Die PHP-Lücken sind kein Argument, jede WordPress-Installation sofort abzulösen. Sie sind ein Anlass, drei Fragen zu klären:

1. Brauchen Sie auf der öffentlichen Seite wirklich eine Laufzeit? Für Unternehmensseiten, Fachartikel und Dokumentation meist nicht. Dann reduziert eine statische Auslieferung die Angriffsfläche unabhängig von dieser Lücke.
2. Wissen Sie, wo PHP bei Ihnen läuft? Wer am 21. Oktober erst suchen musste, hat ein Inventarproblem. Dazu gehört auch, technische Schulden in WordPress sichtbar zu machen, etwa nicht mehr gepflegte PHP-Versionen.
3. Wie schnell kommen Sie vom Netz, und wie schnell wieder zurück? Ein dokumentierter Weg zur Notabschaltung und zum sicheren Wiederanlauf gehört zum Betrieb, genauso wie ein Backup, das kein Sicherheitskonzept ersetzt.

Checkliste

• Alle PHP-Installationen und -Versionen erfassen, auch Container und Geräte.
• Beim Hoster den Patch-Stand für 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 erfragen.
• PHP 8.1 und älter auf eine unterstützte Version bringen oder einen Backport klären.
• Bis zum Patch: Multipart-Anfragen am Webserver einschränken, Upload-Fortschritt abschalten.
• Logs ab dem 17. Oktober auf auffällige Multipart-Anfragen und Worker-Abstürze prüfen.
• Zugangsdaten, die auf betroffenen Servern liegen, rotieren.
• Mitigationen nach dem Update zurücknehmen.
• Prüfen, welche Seiten gar keine PHP-Laufzeit brauchen.

Häufige Fragen

Ist meine WordPress-Website betroffen?

Ja, wenn der Server eine verwundbare PHP-Version einsetzt, unabhängig davon, ob WordPress und alle Plugins aktuell sind. Entscheidend ist die PHP-Version auf dem Server, die Sie über das Hosting-Panel oder den Hoster erfahren.

Hilft eine Web Application Firewall?

Nur teilweise. Cloudflare hat Regeln gegen die bekannten Angriffswege veröffentlicht und bezeichnet sie als temporär. Solche Regeln helfen nur, wenn der Server nicht direkt erreichbar ist und der Datenverkehr über den Dienst läuft. Ein Ersatz für das Update sind sie nicht.

Ist eine Astro-Website sicher vor dieser Lücke?

Die ausgelieferten statischen Seiten sind von dieser Lücke nicht betroffen, weil sie kein PHP ausführen. Sicher ist die Website damit nicht automatisch: Redaktionssystem, Formularbackend und Build-Prozess müssen separat betrachtet werden.

Muss ich jetzt migrieren?

Nein, nicht aufgrund dieser Lücke allein. Aktualisieren Sie zuerst PHP. Dann prüfen Sie in Ruhe, welche Teile Ihrer Website eine Laufzeit brauchen und welche nicht.

Weiterführend

• Astro oder WordPress: Welche Architektur passt zu Ihrem Projekt?
• Astro für Content-Sites
• Headless WordPress
• Static Site Generation

Weiterführende Quellen

Primär- und Fachquellen, auf die sich dieser Beitrag stützt. Die Lage entwickelt sich weiter; prüfen Sie den aktuellen Stand direkt dort.

• NCSC (UK): Critical security issue affecting PHP
• The Register: PHP devs publish critical bug fix as site owners warned
• heise: php2shell – Critical flaws allow code injection in PHP
• Sansec: PHP2Shell
• Patchstack: Major security alert, PHP vulnerable to critical RCE
• Google Cloud / Wiz: Responding to core PHP vulnerabilities
• Security.NL: Misbruik van PHP2Shell-lek gemeld, DigiD en andere sites weer online
• Yle: Finland temporarily shuts down government websites
• Red Hat: CVE-2026-109618
• ma.ttias.be: Early mitigation steps