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

Auf einen Blick

PHP2Shell ist der Name für zwei kritische Sicherheitslücken in PHP selbst (CVE-2026-109618 und CVE-2026-109619), geschlossen am 21. Oktober 2026. Im schlimmsten Fall reicht eine einzige präparierte Anfrage, und ein Angreifer übernimmt deinen Webserver: ohne Login, ohne Klick, ohne Hilfe von innen.

• Wer betroffen ist: praktisch jede Website, die auf PHP 5.4 oder neuer läuft. Dazu gehören WordPress, WooCommerce, Shopware, Magento, Joomla, Drupal, Laravel-Anwendungen und individueller Code.
• Wird die Lücke schon ausgenutzt? Angriffsversuche gab es schon vor dem Patch, und mehrere Sicherheitsfirmen melden inzwischen breit angelegte Angriffswellen.
• Die Lösung: PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren (oder das gepatchte Paket deiner Linux-Distribution einspielen) und PHP danach neu starten. Ein Update von WordPress oder deinen Plugins hilft hier nicht.
• Was du heute tun solltest: deinen Hoster oder Entwickler fragen, ob dein Server gepatcht ist, und auf ein klares Ja bestehen.

Stand: Abend des 21. Oktober 2026. Die Lage entwickelt sich schnell.

Warum das gerade jetzt wichtig ist

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates veröffentlicht, von denen jeder Website-Betreiber wissen sollte. PHP läuft auf einem riesigen Teil des Webs: Wiz, eines der beteiligten Forschungsteams, spricht von rund 70 % aller Websites. Darunter sind WordPress und bekannte Shopsysteme wie WooCommerce, Shopware und Magento.

Das Besondere an PHP2Shell ist, wo das Problem steckt. Es ist kein fehlerhaftes Plugin und kein schwaches Passwort, sondern ein Fehler im Motor, der deine Website antreibt. Deine Seite kann sauber gebaut und auf Anwendungsebene komplett aktuell sein und trotzdem angreifbar. Der Sicherheitsforscher Kevin Beaumont nannte PHP2Shell eine der größten Schwachstellen seit Jahren.

In diesem Artikel erfährst du verständlich, was passiert ist, wie du herausfindest, ob du betroffen bist, und was jetzt zu tun ist, egal ob du deinen Server selbst betreibst oder dich auf einen Hoster oder eine Agentur verlässt.

Was ist PHP2Shell?

PHP2Shell ist der Spitzname für zwei Lücken in der PHP-Laufzeitumgebung. Das PHP-Sicherheitsteam stuft beide mit 9,2 von 10 Punkten als kritisch ein. Der Name stammt von einem Exploit-Werkzeug, das beide Lücken kombiniert, um eine „Shell“ zu bekommen, also Kommandozugriff auf den Server.

Beide Fehler drehen sich darum, wie PHP aufräumt, wenn eine Anfrage abstürzt, vor allem wenn der Speicher ausgeht:

• CVE-2026-109618, Codeausführung durch Speichermangel. Ein Angreifer kann PHP genau in dem Moment den Speicher ausgehen lassen, in dem eine Anfrage noch vorbereitet wird. Das anschließende Aufräumen behandelt dann halb fertige interne Daten, als wären sie gültig.
• CVE-2026-109619, Codeausführung durch verwaiste Daten. Daten einer abgestürzten Anfrage können weiterleben, obwohl ihr Speicher schon freigegeben wurde. Eine spätere Anfrage an denselben PHP-Prozess greift dann auf diese Reste zu, die der Angreifer vorbereitet hat.

Einfach gesagt: Der Angreifer bringt eine Anfrage absichtlich zum Absturz, damit sie eine Falle hinterlässt. Dann schickt er eine zweite Anfrage, die genau in diese Falle tappt. Mit etwas Vorbereitung reicht das, um eigenen Code auf deinem Server auszuführen.

Es gibt noch eine zweite Gefahr, über die weniger gesprochen wird. Die Forscher haben gezeigt, dass Angreifer Teile des Arbeitsspeichers auslesen können, ganz ohne den Server zu übernehmen. Darin können Passwörter, Login-Tokens, API-Schlüssel und Zertifikate stecken, aus Anfragen anderer Besucher oder vom Server selbst.

Warum diese Lücke anders ist

Die meisten PHP-Sicherheitswarnungen betreffen ein einzelnes Plugin, eine Erweiterung oder eine Einstellung. PHP2Shell ist breiter, aus vier Gründen:

1. Sie sitzt unter deiner Anwendung. Die Fehler stecken im Kern von PHP. Wiz hat gezeigt, dass selbst eine leere „Hello World“-Seite auf einer verwundbaren PHP-Version angreifbar ist. Guter Code auf deiner Seite schützt dich also nicht.
2. Kein Login nötig. Der Angriff funktioniert ohne Konto, ohne Passwort und ohne einen Klick von irgendwem. Er kann greifen, bevor dein Anwendungscode überhaupt startet.
3. Sie reicht ein Jahrzehnt zurück. Jede PHP-Version der letzten zehn Jahre ist von mindestens einem der Fehler betroffen, bis zurück zu PHP 5.4.
4. Sie ist an echten Systemen bewiesen. Forscher haben Standard-Installationen von WordPress, Drupal und Joomla komplett übernommen. Die E-Commerce-Sicherheitsfirma Sansec hat Angriffe auf Magento 2.4.9 und zehn weitere PHP-Anwendungen bestätigt und warnt, dass auch Shopware- und WooCommerce-Shops mit sauberem Code angreifbar sind.

Am höchsten ist das Risiko auf Servern, die PHP als Apache-Modul (mod_php) betreiben. Dort kann eine einzige Anfrage ohne Login den Angriff auslösen. Setups mit PHP-FPM, üblich bei nginx und vielen Managed-Hostern, verhalten sich anders, und die bestätigten Angriffswege sind dort enger. Der PHP-Sicherheitshinweis führt sie trotzdem als gefährdet, genau wie php-cgi, FrankenPHP und LiteSpeed.

Wie es ablief

Die Fehler wurden im August mithilfe von KI gefunden, veröffentlicht werden sollte der Fix am 22. Oktober. Ein Leak hat alles um einen Tag vorgezogen. Alle Uhrzeiten in MESZ:

• 11. Aug 2026: Calif und OpenAI melden unabhängig voneinander den Speichermangel-Fehler als Weg zur Codeausführung.
• 19.–24. Aug 2026: Wiz Research findet weitere Varianten, bestätigt Übernahmen von Drupal und WordPress und meldet sie an PHP.
• 20. Okt, ca. 17:20 Uhr: Ein Beitrag auf Hacker News verrät, dass zwei kritische PHP-Lücken kurz vor der Veröffentlichung stehen.
• 20. Okt, 21:33 Uhr: PHP kündigt ein Notfall-Release für den nächsten Tag um 16:00 Uhr an.
• 20. Okt, ca. 22:00 Uhr: Calif veröffentlicht versehentlich ein Video seines funktionierenden Exploits, was Nachahmer beschleunigt.
• 21. Okt, 05:02 Uhr: Cloudflare schaltet Firewall-Schutz für alle Kunden frei, auch im kostenlosen Tarif.
• 21. Okt, 09:41 Uhr: Chainguard veröffentlicht gepatchte Images zu früh, sodass jeder den Fix vor dem offiziellen Release studieren kann.
• 21. Okt, ca. 16:00 Uhr: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 erscheinen.
• 21. Okt, 16:19 Uhr: watchTowr meldet aktive Angriffsversuche auf beide Lücken.

Einige Organisationen haben nicht auf den Patch gewartet. In den Niederlanden gingen DigiD, MijnOverheid, die Website der Zweiten Kammer, das nationale Cybersicherheitszentrum und mehrere Bildungssysteme vorsorglich offline, wie The Hacker News berichtet. Der HR-Softwareanbieter BambooHR nahm seinen Dienst in den USA, Kanada und Irland vom Netz. Das britische NCSC riet, jedes System vom Netz zu nehmen, das sich nicht sofort patchen lässt.

Bis zum Redaktionsschluss ist kein erfolgreicher Einbruch öffentlich bestätigt. Die Angriffsversuche sind aber breit gestreut: Laut SecurityWeek meldet Hadrian Angriffe in großem Stil, meist über die Upload-Fortschrittsfunktion von PHP-Sessions, und watchTowr rechnet damit, dass die ersten Treffer nicht lange auf sich warten lassen.

Ist deine Website betroffen?

Wenn deine Website oder dein Shop auf PHP läuft und der Server das Update vom 21. Oktober noch nicht bekommen hat: Geh davon aus, dass ja.

• PHP 8.5: verwundbar unter 8.5.12. Update auf 8.5.12.
• PHP 8.4: verwundbar unter 8.4.27. Update auf 8.4.27.
• PHP 8.3: verwundbar unter 8.3.36. Update auf 8.3.36.
• PHP 8.2: verwundbar unter 8.2.35. Update auf 8.2.35, danach das nächste Upgrade planen: Der Support für 8.2 endet am 31. Dezember 2026.
• PHP 8.1, 8.0, 7.x und 5.x: verwundbar, ohne offizielles Update. Möglich sind ein zurückportierter Fix deiner Linux-Distribution oder deines Support-Anbieters, die Quellcode-Patches von PHP (7.4 bis 8.1) oder ein Upgrade auf eine unterstützte Version.

Drei Dinge sorgen oft für Verwirrung:

• Ein Update von WordPress, Shopware oder deinen Plugins behebt das nicht. PHP liegt eine Ebene darunter. Der Fix kommt von deinem Server, deinem Hoster oder deinem Container-Image.
• Die Versionsnummer kann täuschen. Linux-Distributionen wie Ubuntu und Debian patchen PHP, ohne die Hauptversionsnummer zu ändern. Ein Server mit „8.3.6“ kann sicher sein, während einer mit höherer Nummer noch verwundbar ist. Sicherheit gibt dir nur der Sicherheitshinweis oder das Paket-Changelog des Anbieters.
• Installiert heißt nicht aktiv. Nach dem Update müssen PHP-FPM oder Apache neu gestartet werden. Bis dahin bedienen die alten, verwundbaren Prozesse weiter deine Besucher.

Was du heute tun solltest, wenn dir eine Website gehört

Du musst dafür kein Techniker sein. Du brauchst klare Antworten von dem, der deinen Server betreut.

1. Kläre, wer für deinen Server zuständig ist. Das kann dein Hoster sein, deine Agentur, ein Freelancer oder deine IT-Abteilung. Bei Shared- oder Managed-Hosting aktualisiert meist der Hoster PHP für dich, lass dir das aber bestätigen.
2. Stell drei Fragen, schriftlich: Auf welcher PHP-Version läuft unsere Website? Ist sie gegen CVE-2026-109618 und CVE-2026-109619 gepatcht? Wurden die PHP-Prozesse nach dem Update neu gestartet?
3. Prüf die Version selbst, wenn du kannst. In WordPress findest du sie unter Werkzeuge → Website-Zustand → Bericht → Server. Die meisten Hosting-Oberflächen zeigen sie ebenfalls an. Auf vielen Linux-Servern beweist die Nummer allein aber nicht, dass der Patch drin ist, also frag trotzdem nach.
4. Läuft deine Seite auf PHP 8.1 oder älter, handle sofort. Es gibt kein offizielles Update. Frag nach einem gepatchten Paket deines Anbieters oder nach einem Upgrade. Geht beides heute nicht, nimm die Seite offline oder stell sie hinter eine Web Application Firewall, bis sie abgesichert ist.
5. Nutz Cloudflare, falls du es schon hast. Cloudflare hat Schutzregeln für alle Tarife aktiviert, auch für den kostenlosen. Das verschafft dir Zeit, ersetzt aber nicht den Patch.
6. Tausch nach dem Patch deine Zugangsdaten aus. Weil die Lücken Speicherinhalte preisgeben können, solltest du Admin-Passwörter, API-Schlüssel und Zugangsdaten deines Zahlungsanbieters erneuern, besonders wenn dein Server nach dem 20. Oktober noch ungepatcht war.
7. Lass prüfen, ob es Anzeichen für einen Einbruch gibt (siehe unten). Könnten Kundendaten betroffen sein, hol deine Datenschutzbeauftragte oder deinen Datenschutzbeauftragten dazu: Nach der DSGVO muss eine Datenschutzverletzung in der Regel innerhalb von 72 Stunden an die Aufsichtsbehörde gemeldet werden.

Für deine Entwickler oder deinen Hoster

Die einzige vollständige Lösung ist das Update. Laut dem PHP-Sicherheitshinweis verringern Konfigurationsänderungen nur einzelne Angriffswege, machen einen Server aber nicht sicher.

Patchen und prüfen

• Aktualisiere die PHP-Laufzeit, die Webanfragen bedient, nicht nur die Kommandozeilen-Version. php -v in der Shell kann einen anderen Build anzeigen als den hinter Apache oder PHP-FPM.
• Starte Apache, PHP-FPM und alle langlaufenden PHP-Worker auf jedem Host neu. Prüfe, dass die Prozesse nach dem Paket-Update gestartet wurden, zum Beispiel mit ps -eo pid,lstart,cmd | grep '[p]hp-fpm: master'.
• Bei Distributionspaketen prüfst du den Fix über das Changelog, nicht über die Versionsnummer. Unter Debian/Ubuntu: apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]'. Unter RHEL, Rocky oder Alma: rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'.
• Baue Container auf Basis der offiziellen PHP-Images neu und rolle sie aus. Laufende Container aktualisieren sich nicht von selbst.
• Wenn du das ehrenamtlich gepflegte Remi-Repository nutzt: PHP empfiehlt, auf Distributionspakete umzusteigen oder selbst zu kompilieren. Remi hatte am Release-Tag kein Update.
• Prüfe nach dem Update memory_limit und post_max_size. Der Fix führt ein neues hartes Speicherlimit ein. Wird es erreicht, endet der Prozess, ohne Shutdown-Handler auszuführen.

Wenn du nicht sofort patchen kannst

PHP nennt diese Übergangslösungen. Jede braucht einen Neustart aller Worker.

• Gegen CVE-2026-109618: memory_limit=-1 so setzen, dass Anwendungen es nicht überschreiben können (etwa per php_admin_value im FPM-Pool oder in der Apache-Konfiguration), und den Speicher stattdessen per Container- oder cgroup-Limit begrenzen. post_max_size niedrig halten: 8M ohne Uploads, 32M mit Uploads. Größenlimits für Anfragen am Webserver oder Proxy durchsetzen. Nicht RLIMIT_AS oder RLIMIT_DATA verwenden, sie können den verwundbaren Pfad selbst auslösen.
• Gegen CVE-2026-109619: session.upload_progress.enabled=0 in der php.ini oder Pool-Konfiguration setzen, nicht per ini_set() oder .user.ini. Unter PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Am Rand des Netzes: Sansec schlägt außerdem vor, multipart/form-data-Anfragen am Webserver zu blockieren (das legt Datei-Uploads lahm), den Traffic über Cloudflare zu leiten oder einen Shop bis zum Patch in den Nur-Lese-Modus zu schalten.

Eine Warnung zum Schluss: Rund um die Veröffentlichung kursierten gefälschte und möglicherweise schädliche „Proof-of-Concept“-Exploits. Führ keinen heruntergeladenen Exploit-Code gegen deine eigenen Server aus, um sie zu „testen“.

Anzeichen, dass deine Seite schon kompromittiert sein könnte

Der Patch schließt die Tür, wirft aber niemanden raus, der schon drin ist. Weil der Angriff unterhalb der Anwendung passiert, zeigen normale Anwendungslogs oft wenig. Forscher und Incident-Responder nennen diese Warnzeichen:

• Große oder fehlerhafte Upload-Anfragen (multipart), gefolgt von „Allowed memory size exhausted“-Fehlern oder gehäuften HTTP-500-Fehlern
• Ungewöhnlich große oder kryptische PHPSESSID-Cookies in Server-Antworten
• PHP-Worker, die ohne erkennbaren Grund abstürzen oder neu starten
• PHP oder der Webserver starten Shells (sh, bash) oder Werkzeuge wie curl oder wget
• Ausgehende Verbindungen vom Webserver zu unbekannten Adressen
• Neue oder veränderte .php-Dateien, neue Cronjobs, neue Benutzerkonten oder SSH-Schlüssel und Änderungen an php.ini, .user.ini oder .htaccess

Sieht ein Server kompromittiert aus, isolier ihn zuerst. Armis rät, Speicher- und Prozessspuren vor dem Neustart oder Patch zu sichern, weil ein Neustart sie löscht. Geh danach davon aus, dass alles, was dieser Server lesen konnte, inklusive Datenbankpasswörter und API-Schlüssel, beim Angreifer liegt.

Das große Ganze

PHP2Shell ist auch eine Geschichte über KI. Ein Teil der Schwachstelle war schon lange bekannt: Laut Calif wurde ein Speichermangel-Fehler bereits 2020 und erneut bei einem Audit 2024 entdeckt, blieb aber ungepatcht, weil niemand beweisen konnte, dass er ausnutzbar ist. Moderne KI-Modelle haben das geändert. Wiz zufolge hat ein einzelner Forscher mit KI in etwa einer Woche geschafft, wofür früher ein Spitzenteam Monate gebraucht hätte. Die PHP Foundation berichtet, dass KI mehr PHP-Fehler ans Licht bringt als früher: 15 neue CVEs seit dem 1. Juli.

Angreifer haben dieselben Werkzeuge. Rechne damit, dass die Zeit zwischen Veröffentlichung und Massenangriff weiter schrumpft und vergessene, ungepflegte PHP-Installationen zu einem wachsenden Risiko werden.

Zwei praktische Lehren für jedes Unternehmen mit Website:

• Kenne deinen Stack. Du solltest in wenigen Minuten beantworten können: „Auf welcher PHP-Version läuft unsere Seite, und wer aktualisiert sie?“
• Upgrade, bevor es zum Notfall wird. PHP 8.2 erreicht am 31. Dezember 2026 das Ende seiner Lebensdauer. Seiten auf 8.1 oder älter hatten diese Woche keinen offiziellen Fix.

Ist deine Website gepatcht?

Du weißt nicht, auf welcher PHP-Version deine Website läuft oder ob der Fix schon drin ist? Schreib mir und sag mir, worauf deine Seite läuft. Ich antworte in unter 24 Stunden.