PHP2Shell

Was hinter PHP2Shell steckt

Hinter dem Spitznamen stehen zwei Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Das PHP-Projekt bewertet beide mit 9,2 von 10 Punkten (CVSS v4.0) und beschreibt sie in seiner Sicherheitsmeldung vom 21. Oktober 2026 so: Bei der ersten kann die Behandlung von Speichermangel PHP unterbrechen, während interne Daten einer Anfrage erst halb vorbereitet sind. Bei der zweiten überlebt interner Zustand einer Anfrage, obwohl der zugehörige Speicher schon freigegeben ist. Beides kann im schlimmsten Fall zu Remote Code Execution führen, also zur Ausführung fremden Codes aus der Ferne.

• Wer betroffen ist: laut PHP-Projekt alle PHP-Installationen, die Web-Anfragen beantworten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das Projekt bei mod_php.
• Seit wann: Laut den Entdeckern von Wiz Research steckt der fehlerhafte Code seit über zehn Jahren in PHP, betroffen sind Versionen bis zurück zu PHP 5.4.
• Was hilft: die Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Projekt nennt weitere Einstellungen als Übergangslösung, betont aber, dass nur ein Update eine vollständige Lösung ist.

Wichtig für Dein Verständnis: Die Lücke sitzt eine Ebene unter Deiner Website. Ein Update von WordPress, Shopware, Laravel oder einem Plugin ändert daran nichts, wie auch The Hacker News betont. Laut Wiz kann sogar eine einfache „Hello World“-Seite angreifbar sein.

Warum aus der Lücke so schnell ein Ernstfall wurde

Bei der PHP-Lücke CVE-2024-4577 sah Akamai im Juni 2024 die ersten Angriffsversuche innerhalb von 24 Stunden nach Bekanntwerden. Bei PHP2Shell begannen sie sogar vorher:

• 17. Oktober: Amazon registrierte einen Angriffsversuch auf einen seiner Honeypots (Köder-Server), vier Tage vor der Veröffentlichung. Das wurde erst später bekannt, so The Hacker News.
• 20. Oktober: Ein Beitrag auf der Plattform Hacker News kündigte die Lücken samt Kennungen für den 22. Oktober an. Noch am selben Abend zog das PHP-Projekt die Veröffentlichung auf den 21. Oktober, 14:00 UTC (16 Uhr deutscher Zeit), vor.
• 20. Oktober, abends: Laut PHP Foundation veröffentlichte eines der beteiligten Sicherheitsunternehmen versehentlich ein Video seines funktionierenden Angriffs.
• 21. Oktober: Die Updates erschienen. Cloudflare meldete schon vorher erste Angriffsversuche, das Sicherheitsunternehmen watchTowr am Nachmittag aktive Ausnutzungsversuche beider Lücken.

Dazu kommt ein zweiter Beschleuniger: Die Entdecker schreiben, dass KI-Modelle ihnen geholfen haben, funktionierende Angriffe innerhalb von Stunden an unterschiedliche PHP-Versionen und Konfigurationen anzupassen. Das beteiligte Sicherheitsunternehmen Calif schätzt, dass ein einzelner Forscher so in etwa einer Woche schaffte, wofür sonst ein Team Monate gebraucht hätte. Nach Stand der Berichterstattung vom 22. Oktober 2026 ist kein erfolgreicher Einbruch öffentlich bestätigt. Mehrere Organisationen haben Dienste aber vorsorglich vom Netz genommen, in den Niederlanden zum Beispiel das staatliche Login-System DigiD.

Was ein erfolgreicher Angriff für Dein Unternehmen bedeutet

Eine Lücke mit 9,2 von 10 Punkten klingt abstrakt. Übersetzt in Geschäftsrisiken heißt das:

• Zugriff auf Daten: Wer Code auf Deinem Server ausführt, kommt im schlimmsten Fall an Dateien und Datenbank, also an Kundendaten, Bestellungen und Formulareingaben. Davor warnt laut The Hacker News auch die US-Behörde NSA.
• Kaum Spuren: Laut CrowdStrike hinterlässt ein Angriff fast keine Spuren. Die Website antwortet normal, oft steht nur ein einzelner Speicherfehler im Fehlerprotokoll, den man leicht als Rauschen abtut.
• Mehr als Codeausführung: Die Forscher konnten nach eigenen Angaben sogar Arbeitsspeicher von PHP-Prozessen auslesen, ohne vorher Code auszuführen. Je nach Anwendung können dort auch sensible Daten liegen.
• Rechtliche Folgen: Werden personenbezogene Daten kompromittiert, kann eine Meldepflicht gegenüber der Datenschutzaufsicht innerhalb von 72 Stunden entstehen (Art. 33 DSGVO). Das ist ein allgemeiner Hinweis, keine Rechtsberatung.

So prüfst Du, ob Deine Website geschützt ist

Du musst dafür kein Entwickler sein. Diese fünf Punkte kannst Du selbst prüfen oder bei Deinem Hoster abfragen:

• Die PHP-Version: Geschützt sind PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35 und neuer. Linux-Distributionen spielen Korrekturen oft in ältere Versionsnummern ein. Dort zählt, ob die Kennungen CVE-2026-109618 und CVE-2026-109619 im Änderungsprotokoll des Pakets stehen, nicht die Versionsnummer.
• Alte Versionen: PHP 8.1 und älter bekommt vom PHP-Projekt keine Updates mehr. Laut W3Techs laufen rund 35 % der PHP-Websites noch auf PHP 7 oder älter. Wer dazugehört, braucht jetzt einen Anbieter mit nachgelieferten Korrekturen oder ein Upgrade. Auch PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates.
• Alle Systeme: Denk nicht nur an die Website. Shop, Buchungssystem, interne Werkzeuge und Verwaltungsoberflächen bringen oft ihr eigenes PHP mit.
• Spuren nach dem Update: Wiz nennt als mögliche Anzeichen ungewöhnliche Formular-Anfragen mit anschließenden Speicherfehlern oder wiederholten Serverfehlern (HTTP 500), auffällig große Session-Cookies und unerklärliche Neustarts von PHP-Prozessen. Das FBI rät, auf PHP-Prozesse zu achten, die unerwartet eine Kommandozeile starten oder Dateien herunterladen.
• Speichergrenzen nach dem Update: Laut The Hacker News führt das Update eine harte Speichergrenze ein. Wird sie erreicht, beendet PHP den Prozess. Lass deshalb prüfen, ob die Einstellungen für Speicher und Upload-Größe zu Deiner Anwendung passen.

Wie wir das bei uns gelöst haben

Auch unser eigenes CMS Evolu und alle Websites, die wir hosten, laufen auf PHP. Ein schlankes System ohne Plugin-Sammlung verkleinert die Angriffsfläche einer Anwendung, wie wir in unserem Artikel Headless vs. moderner Monolith beschreiben. Gegen eine Lücke in PHP selbst hilft das nicht. Wir waren also genauso betroffen wie alle anderen. So sind wir vorgegangen:

• Vorbereitet: Nach der Vorankündigung haben wir am 21. Oktober noch vor der Veröffentlichung festgehalten, welche PHP-Versionen auf unserem Server laufen, und vor dem Update eine vollständige Sicherung des Servers außerhalb des Servers angelegt.
• Nicht auf die Automatik gewartet: Die automatischen Updates hatten die neue PHP-Version noch nicht installiert, obwohl sie in der Server-Verwaltung schon bereitstand. Wir haben das Update deshalb selbst angestoßen. Es war am 21. Oktober gegen 15:50 Uhr aktiv, wenige Minuten vor dem offiziellen Termin.
• Getestet: Danach haben wir Websites und Anwendungen auf ihre Funktion geprüft.
• Nach Spuren gesucht: Weil Angriffe schon vor der Veröffentlichung liefen, haben wir den Server rückwirkend ab dem 15. Oktober untersucht: laufende Prozesse, geänderte Dateien, geplante Aufgaben, Zugangsschlüssel, Netzwerkverbindungen und Protokolle, auch abgeglichen mit den inzwischen veröffentlichten Angreifer-Adressen.
• Informiert: Unsere Hosting-Kunden haben noch am 21. Oktober eine Service-Mitteilung von uns bekommen.

Dabei haben wir gesehen, dass wir auf der Liste standen. Ab dem 19. Oktober haben Adressen, die später als PHP2Shell-Angreifer veröffentlicht wurden, unseren Server abgetastet. Das waren reine Abfragen einer statischen Standardseite, PHP wurde dabei nicht ausgeführt. Am 22. Oktober um 15:10 Uhr kam dann ein echter Angriffsversuch mit PHP2Shell-Kennung. Er lief ins Leere, weil unser Server seit dem Vortag gepatcht war und die Anfrage eine Seite ohne PHP traf. Nach unseren Prüfungen gibt es keine Hinweise auf einen Einbruch.

Die wichtigsten Learnings auf einen Blick

• Die Lücke sitzt in PHP selbst: Updates von WordPress, Shop-Software oder Plugins schützen nicht. Entscheidend ist die PHP-Version auf dem Server.
• Nur das Update ist eine vollständige Lösung: Übergangseinstellungen verringern das Risiko, machen eine Installation laut PHP-Projekt aber nicht sicher.
• Es zählen Stunden: Angriffe liefen bereits vor der offiziellen Veröffentlichung. Wer bei kritischen Lücken auf die nächste Wartung wartet, wartet zu lange.
• Alte PHP-Versionen sind jetzt ein akutes Risiko: Ohne offizielle Updates braucht es nachgelieferte Korrekturen oder ein Upgrade.
• Nach dem Patch prüfen, nicht hoffen: Ein Blick in Protokolle, Prozesse und geänderte Dateien zeigt, ob vor dem Update schon jemand drin war.