PHP2Shell: die PHP-Sicherheitslücke, die für den Wechsel zu Headless spricht

Am 21. Oktober nahm das niederländische nationale Cybersicherheitszentrum seine eigene Website offline. Nicht weil WordPress gehackt worden war, sondern weil der PHP-Interpreter darunter gehackt werden könnte.

An jenem Tag lieferte das PHP-Projekt Fixes für zwei unauthentifizierte Remote-Code-Execution-Bugs im Interpreter selbst, CVE-2026-109618 und CVE-2026-109619. Jede Website, auf der PHP öffentliche Anfragen beantwortete, musste patchen oder offline gehen. Websites, die statisches HTML von einem CDN auslieferten, hatten keinen PHP-Prozess im Request-Pfad, daher gab es nichts an der Edge zu patchen. Headless WordPress brauchte sein Backend immer noch aktualisiert, aber die öffentliche Website blieb online. Unten: die Timeline, das architektonische Argument, eine Entscheidungstabelle nach Stack, ein 30/60/90-Tage-Plan und eine Checkliste, wenn du vorerst bei PHP bleibst.

Falls du PHP betreibst, mach das heute.

• Bestätige, dass die laufende Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 ist, oder ein Vendor-Backport, dessen Mitteilung du gelesen hast, und starte alle Worker neu.
• Überprüfe, was dein Hosting-Kontrollpanel tatsächlich ausgeliefert hat, nicht was das Dashboard sagt.
• Behanle PHPs ini-Mitigationen und jede WAF-Regel als eine Brücke zum Patch, nicht als Ersatz dafür.
• Auf 7.4 bis 8.1 frag deinen Host, ob er die Backports des Security-Teams aus der Quelle gebaut hat, und buche das Upgrade auf jeden Fall.

Was am 21. Oktober 2026 passierte

Die Chronologie ist wichtig, weil sie die Panik erklärt. Nach Tenable zirkulierten die CVE-Identifikatoren am 20. Oktober auf Hacker News und in den sozialen Medien. Später an jenem Tag veröffentlichte das PHP-Sicherheitsteam eine Vorankündigung einer Veröffentlichung für den 21. Oktober um 14:00 UTC und sagte, dass es früher ausgeliefert werden könnte, wenn Details öffentlich werden. Tenable berichtet auch unter Berufung auf watchTowr, dass die Offenlegung ursprünglich für den 22. Oktober unter Embargo geplant war.

Das PHP-Sicherheitsteam veröffentlichte dann seine Empfehlung am 21. Oktober mit dem Titel "Security advisory: Critical remote code execution vulnerabilities, update now" (php.net news archive). Die gemeinsame Stellungnahme der ENISA datiert die Updates auf 13:40 UTC. Gepatchte Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Die beiden Bugs aus den GitHub-Empfehlungen:

• CVE-2026-109618: Remote-Code-Execution über Out-of-Memory-Speicherbeschädigung.
• CVE-2026-109619: Remote-Code-Execution über abgelaufenen globalen Status, ein Use-After-Free zwischen Anfragen, die vom gleichen Worker bearbeitet werden.

Das PHP-Sicherheitsteam bewertet beide mit CVSS v4.0 9.2. Tenable vermerkt, dass einige frühe Berichte, einschliesslich watchTowr und eines Hacker-News-Beitrags, von 10.0 sprachen. Jede Web-serving-SAPI ist im Umfang enthalten: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Die OOM-Empfehlung hebt mod_php als am meisten gefährdet hervor, weil der Fehler vollständig vor jeglichem Anwendungscode auftritt. Calif sagt, dass der früheste betroffene Code-Pfad auf PHP 5.4.0 zurückgeht. Die Entdeckung wird Wiz, Calif und OpenAI gutgeschrieben, mit KI-gestützter Forschung.

Dann die Ausfälle. Reuters und RTE berichteten über Regierungsdienstleistungen, die offline gingen in den Niederlanden, Finnland, Frankreich und Australien, einschliesslich der Website des niederländischen nationalen Cyber-Sicherheitszentrums selbst. CERT-EU empfahl, internetgestützte Anwendungen bis zur Bereitstellung des Patches zu isolieren, und CISA forderte sofortiges Patchen. Krebs berichtet, dass Cloudflare WAF-Regeln um 3:02 Uhr UTC einsetzte. Amazon Threat Intelligence sagt, dass es einen Versuch am 17. Oktober sah und die Ausnutzung später als breit beschrieb.

Bei der Ausnutzung sind sich die Quellen uneinig, und das sollten Sie wissen. Die PHP Foundation sagte, dass sie zum Zeitpunkt der Veröffentlichung keine funktionalen Exploits identifiziert habe. Krebs berichtet von Experten, die sagen, dass funktionierende Exploits existieren. Tenable sagte, dass Code, der die Bugs ausnutzen soll, zirkulierte, aber es hatte nichts davon verifiziert.

Warum die Empfehlung war patchen oder offline gehen

Unauthentifizierte Remote-Code-Execution im Request-Pfad bedeutet, dass der Webserver das Ziel ist. Es gibt keine Anmeldung, um sie davor zu setzen, kein Plugin zum Deaktivieren. Eine Anfrage kommt an, PHP parst sie, und der Bug ist bereits aktiv. Die OOM-Empfehlung bestätigt Auswirkungen als unauthentifizierte Code-Ausführung als Web-Worker-Konto, validiert über HTTP gegen mod_php mit Standard-Input- und Memory-Limits.

Die Minderungsmassnahmen, die PHP aufzählte, sind real, und sie sind Notbehelfe. Die Empfehlungen sagen:

• Setze memory_limit=-1 administrativ (über php_admin_value), halte post_max_size konservativ, und blockiere Multipart-Anfragen am Frontend, wenn du sie nicht nutzt.
• Setzen Sie session.upload_progress.enabled=0.
• Auf PHP 8.5 setzen Sie fatal_error_backtraces=0.
• Starten Sie jeden Worker nach jedem davon neu.

Die gleichen Stellungnahmen sind deutlich, dass ein Update die einzige vollständige Lösung ist. Für den Stale-State-Bug gibt es überhaupt keine vollständige generische Konfigurationsmilderung. PHP-Kernentwickler Gina Peter Banyard, zitiert von Tenable, sagte, die einzige Milderung ist das Patchen oder Upgraden von PHP, und PHP-8.6-Release-Manager Joe Ferguson sagte, dass ini-Einstellungen Sie nicht retten. Behandeln Sie die Liste also als eine Brücke über einen Nachmittag, nicht als eine Haltung.

Zwei praktische Schwierigkeiten machten den Tag schwerer als ein Versions-Bump. Shared-Hosting und Control Panels versenden PHP-Pakete nach ihrem eigenen Plan, daher ist die Version, die Sie denken zu verwenden, möglicherweise nicht die Version, die läuft. Plesk veröffentlichte eine eigene Mitteilung für die PHP, die es versendet, und das ist die Art von Seite, die Sie lesen müssen, anstatt sie anzunehmen.

Und dann die älteren Versionen. Die php.net-Empfehlung besagt, dass PHP 8.1 und älter keine Updates mehr vom Projekt erhalten, und verweist auf Distributoren und LTS-Anbieter für Backports. Das Security-Team hat zwar minimale Source-Backport-Branches für 7.4, 8.0 und 8.1 auf GitHub veröffentlicht, aber ein Source-Patch ist keine Release: Jemand muss ihn immer noch bauen und an deinen Host liefern. PHP 5.4 bis 7.3 erhalten nichts. Falls du nie aktualisiert hast, war das dein 21. Oktober.

Ein paar Zahlen zum Maßstab. W3Techs zeigt PHP auf 69,3% der Websites mit einer bekannten serverseitigen Sprache ab 22. Oktober, davon 65,3% auf Version 8, 26,9% auf Version 7 und 7,7% auf Version 5. Censys zählt 2,58 Millionen internetfähige Hosts und 54,9 Millionen Webeigenschaften, auf denen PHP läuft. Das ist eine Menge Worker zum Neustarten.

Wer am 21. Oktober nichts zu tun hatte

Hier ist die Belastung in Request-Path-Begriffen. Stellen Sie jeder Site eine Frage: Wenn ein Besucher eine Seite lädt, welcher Code läuft, um sie zu beantworten?

Statisches HTML auf einem CDN

Wenn die Antwort "nichts, das CDN gibt eine Datei zurück" ist, berührt PHP2Shell nicht die öffentliche Site. Kein PHP-Prozess antwortet auf Anfragen, daher gibt es nichts, das an der Kante gepatched werden muss, und keinen Grund, etwas offline zu nehmen. Ich betreibe gautamkhorana.com auf Astro mit statischer Ausgabe. HostList, das ich auf Next.js und Supabase mit etwa 28.000 programmatischen Seiten aufgebaut habe, hatte keinen PHP-Prozess zum Patchen. Deluxe Astrology auch nicht, das 91.000+ Seiten in 30 Sprachen läuft. Niemand bekam am 21. Oktober einen Anruf.

Headless WordPress

Headless ist eine andere Geschichte, und ich würde lieber präzise als schmeichelhaft sein. Das PHP-Backend brauchte an diesem Tag immer noch 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, weil WordPress immer noch auf PHP läuft. Der Unterschied ist, wo es sitzt. Hinter einer Firewall oder einer IP-Allowlist, mit der öffentlichen Site serviert von Astro oder Next.js, war das Backend nicht im Pfad einer Besucheranfrage. Das Patchen war eine Wartungsaufgabe, kein öffentlicher Ausfall.

Sagen Sie es klar: das ist nicht "Headless ist unhackbar". Ein Angreifer, der das Backend erreichen kann, kann immer noch den Bug erreichen, weshalb die Allowlist zählt. SSR-Frameworks haben ihre eigenen Server-Runtime-Risiken, die im Next.js-, Astro- und Nuxt-Sicherheitsartikel behandelt werden, und der breitere Vergleich lebt in Headless vs WordPress-Sicherheit. Ich werde keinen von beiden hier wiederholen.

Ein Muster, kein Einzelfall

Das war nicht das erste Mal, dass PHPs Request-Path die Schlagzeilen machte. PHP-CGI-Argument-Injection, CVE-2024-4577, landete 2024. Es gab einen älteren PHP-CGI-Bug 2012. Jetzt PHP2Shell. Verschiedene Fehler, gleiche Form: Code, der vor jeder öffentlichen Anfrage sitzt, wird getroffen, und jeder Downstream-Betrieb gerät in Aufruhr.

Jetzt die Lektion, die in die andere Richtung schneidet. React2Shell auf Next.js zeigte, dass SSR-Runtimes ihre eigene Request-Path-Belastung haben. Wenn ein JavaScript-Server jede Seitenanfrage beantwortet, ist es das neue PHP zum Zweck des Patchens. Der Wechsel von WordPress zu einer mit Next.js serverseitig gerenderten Site verschiebt die Angriffsfläche. Es löscht sie nicht. Statische Ausgabe ist die starke Aussage. SSR ist ein Trade-off.

Also die Frage war nie "welche Sprache". Es ist "welcher Code beantwortet eine öffentliche Anfrage". Schneiden Sie diese Liste herunter und Ihre Incident-Tage werden kürzer, egal in welcher Sprache die nächste CVE geschrieben ist.

Es gibt auch einen zukunftsorientierten Punkt. Die Wiz-Forscher schrieben, dass die Fehler seit Jahrzehnten vorhanden waren, dass das Ausnutzen eine Kette von Schritten "an der Grenze dessen, was menschliche Forscher praktisch erreichen konnten" erforderte, und dass "Frontier-AI-Modelle diese Barriere erheblich senkten" (Krebs). Die Implikation, die eher meine als ihre ist: wenn alte Fehler billiger werden, um in Exploits umzuwandeln, geht der Disclosure-Rhythmus für jeden Runtime nach oben. Planen Sie auf mehr Tage wie diesen, nicht weniger.

Was der 21. Oktober Sie nach Stack gekostet hat

Klassisches WordPress oder anderes PHP-CMS. Drupal, Magento, Joomla und WordPress laufen alle auf PHP, und Calif meldet bestätigte Pre-Authentication-Remote-Code-Execution gegen spezifische Versionen aller vier, laut Tenables FAQ. Diese Reihe trug die gesamten Kosten des Tages.

Headless WordPress. Du hast gepatcht, aber nach deinem Zeitplan und hinter einer Firewall. Redakteure konnten weiterhin bearbeiten. Besucher sahen nichts.

Laravel oder Custom PHP. Dieselbe Exponierung wie bei klassischen CMS, mit einer Wendung: Niemand veröffentlicht eine Produktwarnung für deine Custom App, also trägst du die Verantwortung für das Inventar. Das php2shell-Repository von NCSC-NL besagt, dass Custom PHP-Anwendungen nicht in seiner Übersicht registriert sind.

Statisches Jamstack. Nichts zu tun am Edge. Falls dein Build auf einer CI-Box läuft, patche diese, wenn es dir passt, da sie nicht für Besucher erreichbar ist.

SSR mit Next.js oder Nuxt. Kein PHP, kein PHP2Shell. Aber ein Serverprozess beantwortet weiterhin Anfragen, und React2Shell ist die Erinnerung daran, dass dieser Prozess seine eigenen kritischen Momente hat.

Der 30/60/90-Tage-Plan

Das Ziel ist, die öffentliche Oberfläche aus PHP zu nehmen, ohne das Bearbeitungserlebnis neu aufzubauen.

1. Bis Tag 30: Liste deine Seitentypen auf (Posts, Landing Pages, Produktseiten, Archive) und kennzeichne, welche wirklich eine Logik pro Anfrage benötigen. Bestätige die PHP-Version auf jedem Host. Setze ein CDN vor den Origin und beschränke das Admin-Panel auf eine Allowlist.
2. Bis Tag 60: Baue ein Astro- oder Next.js-Front-End für einen oder zwei der verkehrsstärksten statischen Seitentypen auf, gebaut aus der WordPress Content API. Löse einen Rebuild bei Veröffentlichung aus. Füge 301-Umleitungen für jede URL hinzu, die du verschiebst.
3. Bis Tag 90: Migriere die verbleibenden Seitentypen, die statisch sein können. Schließe den PHP-Origin vor öffentlichem Datenverkehr ab, damit nur der Build-Prozess und deine whitelisted Redakteure ihn erreichen. Alles, das wirklich einen Server braucht (Suche, Formulare, Konten), geht an einen kleinen, benannten Service, den du unabhängig patchen kannst.

Die öffentliche Oberfläche aus PHP nehmen, ohne das CMS zu verlieren

Du musst WordPress nicht wegwerfen, um PHP aus dem Request-Pfad zu nehmen. Headless WordPress behält Redakteure, Inhalte und den Plugin-Workflow für Schreiben und Genehmigungen, während Astro oder Next.js die Website bedient. Redakteure behalten den Screen, den sie kennen. Besucher erhalten Dateien von einem CDN.

Migriere schrittweise. Wähle einen Seitentyp, baue ihn im neuen Front-End auf, leite die alten URLs per 301 um, und mache weiter. Das Admin-Panel bleibt in PHP, hinter einer Allowlist. Das Hosting-Muster ist einfach: Origin gesperrt, CDN davor, Build bei Veröffentlichung.

Zur Framework-Wahl: Astro für Content-Websites, Next.js wenn die Website eine Application Layer braucht, Nuxt für Vue-Teams. Die tieferen Trade-offs stehen im Static Site Generator Vergleich und im Headless WordPress Guide.

Bei der Mühe, nur die Startpreise verwendet: WordPress zu Astro Migration ab 7.000 €, Headless WordPress Development ab 10.000 €, und eine Legacy CMS Migration ab 5.000 €. Falls die Website eine Application Layer braucht, ist WordPress zu Next.js Migration ab 10.000 € der passende Weg. Das sind Ausgangspunkte, und die reale Summe hängt von Seitentypen, Integrationen und davon ab, wie viel Bearbeitungs-Workflow du bewahren möchtest. Falls du erwägst, PHP ganz zu verlassen, behandelt die Seite "leave-WordPress" diesen Pfad.

Der billigste Tag, um damit anzufangen, ist nicht der Tag nach einer Warnung. Aber der Tag nach einer Warnung ist, wenn Budgets genehmigt werden, also nutze ihn.

Falls du vorerst bei PHP bleibst

Einige Websites bleiben ein Jahr oder drei stehen. In Ordnung. Machen Sie das unterdessen:

1. Bestätigen Sie, dass die laufende PHP-Version 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 ist (oder ein Vendor-Backport, dessen Hinweis Sie gelesen haben), und dass jeder Worker neu gestartet wurde. Ein Paket-Upgrade, das alte Worker am Laufen lässt, hat nichts behoben.
2. Prüfen Sie, was Ihr Hosting-Control-Panel tatsächlich ausgeliefert hat, nicht was das Dashboard sagt.
3. Wende PHPs aufgelistete Minderungsmaßnahmen nur als Brücke an. Die Empfehlungen besagen, dass sie eine Installation nicht sicher machen, und die OOM-Empfehlung warnt vor RLIMIT_AS und RLIMIT_DATA, die den anfälligen Pfad auslösen.
4. Planen Sie den Ausstieg aus 7.4 zu 8.1 jetzt. Das PHP-Projekt aktualisiert 8.1 und älter nicht mehr, und Sie verlassen sich auf das Backport von jemand anderem.
5. Setzen Sie die Website hinter eine WAF, während Sie patchen. Cloudflare CTO Dane Knecht nannte ihre Regeln "nur eine NOTLÖSUNG", und Tenable vermerkt, dass sie nur Traffic abdecken, der über Cloudflare geroutet wird.
6. Beobachten Sie Web Shells und PHP-Dateien, die nicht existieren sollten. Wiz erwartet Massenausnutzung zum Installieren, also prüfen Sie Upload-Verzeichnisse und kürzlich geänderte Dateien.

Für Websites, die bei WordPress bleiben, deckt WordPress-Sicherheitspflege ab 150 Euro pro Monat die laufenden Patch- und Überwachungsaufgaben ab.

Die schärfste Tatsache vom 21. Oktober ist, dass der Bug an dem einen Ort lebte, den jeder PHP-Besucher berührt, daher waren die einzigen Websites ohne etwas zu tun diejenigen, bei denen PHP nie eine öffentliche Anfrage beantwortete. Statische Ausgabe ist die starke Version dieser Aussage; Headless WordPress brauchte immer noch sein Backend gepatcht, und SSR tauscht nur einen Runtime gegen einen anderen.

FAQ

Ist WordPress von PHP2Shell betroffen?

WordPress selbst ist nicht der Bug. Die Schwachstellen sind in PHP, und WordPress läuft auf PHP, daher war jede WordPress-Site auf einem ungepatchten PHP gefährdet. Tenables FAQ, unter Berufung auf Calif, meldet bestätigte Pre-Authentication-Remote-Code-Execution gegen spezifische WordPress-Versionen, was die Frage klärt.

Braucht Headless WordPress dennoch den Patch?

Ja. Das Backend läuft auf PHP, und ein Angreifer, der es erreichen kann, kann den Bug erreichen. Was Headless ändert, ist die Gefährdung: das Backend kann hinter einer Firewall oder Allowlist sitzen, während ein separates Frontend die Öffentlichkeit bedient.

Ist eine Next.js- oder Astro-Website sicherer als PHP?

Statische Ausgabe von beiden ist sicherer gegen diese Bug-Klasse, weil kein serverseitiges Runtime Anfragen beantwortet. SSR ist ein Kompromiss: Sie tauschen PHP gegen einen JavaScript-Server-Runtime mit eigenen Empfehlungen, wie React2Shell zeigte.

Schützt mich eine WAF?

Teilweise, und nur eine Weile. Cloudflare nannte seine Regeln eine Notlösung und sie decken nur Traffic über Cloudflare. Eine WAF gibt Ihnen Zeit zum Patchen. Sie ist kein Patch.

Sollte ich meine Website offline nehmen?

CERT-EU empfahl, die Isolierung von internetgestützten Anwendungen bis zu einer Behebung zu erwägen, und EINSAs gemeinsame Erklärung sagt dasselbe, wenn sofortige Abhilfe nicht durchführbar ist. Wenn Sie schnell patchen können, patchen Sie. Wenn Sie nicht können, ist Isolierung ein vernünftiger Schritt.

Welche PHP-Versionen sind behoben?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, gemäß den PHP-Empfehlungen.

Sind PHP 7.4, 8.0 und 8.1 gepatcht?

Nicht mit Releases. Die php.net-Empfehlung besagt, dass 8.1 und älter keine Updates mehr vom PHP-Projekt erhalten, und das Security-Team hat stattdessen minimale Source-Backport-Branches für 7.4, 8.0 und 8.1 veröffentlicht. Frag deinen Host oder deine Distribution, ob sie diese gebaut hat; plan auf jeden Fall das Upgrade.