PHP-Sicherheitslücke PHP2Shell: Was jetzt zu tun ist

Kategorien: Datenschutz

Die PHP-Sicherheitslücke PHP2Shell betrifft alle Versionen der Scriptsprache und hunderte von Millionen Webanwendungen weltweit, und mehrere Hoster nahmen Websites vorsorglich vom Netz (inklusive deren eigener Webseite). KI-Werkzeuge halfen beim Fund, und ein veröffentlichter Patch wird selbst zum Wettlauf.

Am 21. Oktober 2026 um kurz vor 16 Uhr erschienen Sicherheitsupdates für PHP, die zwei kritische Schwachstellen schließen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stufte die Lage in einem Sicherheitshinweis mit Kritikalität 3 (Orange) ein. Betreiber sollten demnach unverzüglich handeln. In Deutschland waren zeitweise mehrere Websites nicht erreichbar, weil Betreiber ihre Server vorsorglich vom Internet trennten.

Die Lücken lassen sich auch ohne Fachwissen nachvollziehen: Ein Speicherfehler hinterlässt halbfertige Zustände, die PHP später falsch verarbeitet. Betroffen ist die Laufzeitumgebung, nicht ein einzelnes CMS. Gesichertes, Unbestätigtes und Offenes sind dabei klar zu trennen. Stand der Angaben ist der 22. Oktober 2026, Details können sich ändern.

Die PHP-Sicherheitslücke im Überblick

Es geht um zwei Schwachstellen in der Programmiersprache PHP selbst, nicht in einem einzelnen Content-Management-System. Die Lücken tragen die Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind nach dem Bewertungssystem CVSS 4.0 (Common Vulnerability Scoring System, eine Skala von 0 bis 10) mit 9,2 als kritisch eingestuft. Das BSI leitet aus den Werten ab, dass für eine Ausnutzung weder eine Anmeldung noch eine Nutzerinteraktion nötig ist. Ziel ist Remote Code Execution (RCE), also die Ausführung fremden Programmcodes auf einem Server aus der Ferne.

In Berichten heißt die PHP-Sicherheitslücke auch PHP2Shell. Laut BSI soll der Name an die Ähnlichkeit mit der Schwachstelle Log4Shell erinnern. Mit der älteren WordPress-Lücke „wp2shell“ hat sie nichts zu tun.

Der zeitliche Ablauf ist durch die Meldungen des PHP-Projekts belegt. Am 20. Oktober 2026 erschien eine Vorankündigung ohne Details. Am 21. Oktober 2026 folgten um 14:00 UTC (16:00 Uhr deutscher Zeit) die Patches und die Advisories. Das BSI schreibt in seinem Sicherheitshinweis des BSI vom 21.10.2026 (Version 1.1) (das Dokument trägt die Kennung BITS-H Nr. 2026-297981-1132, die URL enthält 1032), ein Proof-of-Concept sei öffentlich, bestätigte Ausnutzungen seien noch nicht bekannt. Unbestätigte Berichte über Exploits gebe es jedoch.

Was hinter CVE-2026-109618 und CVE-2026-109619 steckt

Beide Fehler gehören zur Klasse der Speicherfehler. Vereinfacht gesagt, arbeitet PHP mit Speicherbereichen, die pro Anfrage reserviert und danach wieder freigegeben werden. Geht etwas schief, entstehen Zustände, mit denen der weitere Programmablauf nicht rechnet. Genau dort setzen die Lücken an. Die folgende Beschreibung ist bewusst vereinfacht und enthält keine Angriffsdetails.

Bei CVE-2026-109618 beschreibt das PHP-Projekt einen Abbruch bei Speichermangel (Out of Memory). Wird dieser Abbruch ausgelöst, während interne Daten einer Anfrage nur teilweise vorbereitet sind, hinterlässt er ungültige Zustände. Beim anschließenden Aufräumen der Anfrage liest PHP diese Daten und verzweigt darauf. Als Auslöser nennt das Advisory vor allem speicherintensives Verarbeiten von Formular-Uploads (multipart/form-data). Auch große Speicheranforderungen der Anwendung selbst können den Fehler auslösen.

Bei CVE-2026-109619 bleibt dagegen Zustand aus einer früheren Anfrage im sogenannten Worker stehen. Ein Worker ist ein PHP-Prozess, der nacheinander viele Anfragen bedient. Ein späterer Request kann diesen veralteten Zustand verwenden, bevor er zurückgesetzt wird. Es braucht also mindestens zwei Anfragen, die denselben Worker erreichen. Bestätigte Wege sind laut Advisory Diagnosemeldungen zu Einstellungen vor der Initialisierung, der Session-Upload-Fortschritt und bei PHP 8.5 die Funktion fatal_error_backtraces.

Am gefährlichsten ist die Lage bei Apache mit mod_php. Dort wurde ein Exploit demonstriert, bei dem eine nicht angemeldete Anfrage den Angriff auslösen kann, bevor irgendein Anwendungscode läuft. Für PHP-FPM wurde nach dem Advisory ein Teilpfad bestätigt. Was die Lücken im Einzelfall erlauben, hängt von der Umgebung ab. Die Patches setzen den Zustand vollständig zurück und beheben die Ursache.

Welche PHP-Versionen und Systeme betroffen sind

Nach der Bewertung des BSI sind alle bekannten PHP-Versionen betroffen, zurück bis mindestens PHP 5. Behoben sind die Fehler in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Das PHP-Update 8.5.12 gilt dabei für den neuesten Zweig, die übrigen Nummern für die jeweils älteren, noch unterstützten Zweige.

Für die bereits abgekündigten Zweige 7.4, 8.0 und 8.1 gibt es keine regulären Updates mehr. Das PHP Security Team stellte laut Sicherheitsmeldung minimale Backports im Quellcode bereit. Ein Backport überträgt eine Korrektur in eine ältere Programmversion, ohne die Versionsnummer zu erhöhen. Linux-Distributionen und Anbieter mit verlängerter Unterstützung (LTS) liefern teils eigene Korrekturen aus. Für PHP 8.2 endet die Sicherheitsunterstützung am 31. Dezember 2026. Ein Zweig ohne Unterstützung gilt als End of Life (EOL).

Betroffen sind laut BSI und PHP-Projekt alle PHP-Installationen, die Webanfragen verarbeiten. Genannt werden PHP-FPM (ein Prozessmanager, der PHP für Webserver bereitstellt), Apache mit mod_php (PHP als Modul im Webserver), php-cgi, FrankenPHP und LiteSpeed. Die Aussagen sind nicht ganz einheitlich. Die GitHub-Advisories nennen bei einigen Umgebungen nur einen vermuteten oder nicht validierten Pfad. Als sicher gilt daher nur: Wer PHP für Webseiten betreibt, sollte von einer Betroffenheit ausgehen, bis das Gegenteil geklärt ist.

Zudem betreffen die Schwachstellen die Laufzeitumgebung und keine einzelne Anwendung. Das BSI stellt klar, dass ein Update der Anwendung nicht ausreicht. Zu den auf PHP basierenden Projekten zählt das BSI beispielhaft WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense. Ein WordPress-Update allein behebt die Lücken also nicht, entscheidend ist die PHP-Version auf dem Server.

Wie KI die Lücken fand

Belegt ist, dass KI-Werkzeuge beim Fund eine Rolle spielten. Nach Angabe des BSI waren die Unternehmen Wiz und Calif an der Entdeckung beteiligt. Die Rolle weiterer Beteiligter wie OpenAI bleibt hier offen. Calif beschreibt, dass öffentlich verfügbare Sprachmodelle als Assistenten genutzt wurden, etwa zur Suche nach Umgehungen des Speicherlimits und zur Analyse der Speicherverwaltung. Laut dem Beitrag kamen keine speziellen Testumgebungen oder nicht öffentlich verfügbare Modelle zum Einsatz. Die Autoren betonen zugleich, dass Wissen über das Zielsystem entscheidend blieb. Ein Modell finde nicht einfach „alle Fehler“ durch einen einfachen Auftrag. Calif verweist auf einen Speicherlimit-Fehler in PHP aus dem Jahr 2004 als Vorgeschichte.

Auch Wiz berichtet von einer KI-gestützten Entdeckung. Frontier-Modelle hätten die Hürde gesenkt, Fehler zu einem funktionierenden Exploit zu verketten und diesen an verschiedene PHP-Versionen und Konfigurationen anzupassen. Welche Modelle genau eingesetzt wurden und wie groß der Anteil von Mensch und Maschine war, lässt sich anhand der Herstellerangaben nicht unabhängig prüfen. Beide Beiträge stammen von Beteiligten und sind zugleich Eigenwerbung. Die Angaben sind als Selbstauskunft zu lesen.

Die Zeitangaben zur Entdeckung weichen voneinander ab. Calif nennt den 1. August 2026 für die ersten Funde und den 11. August 2026 für die erste Meldung an PHP. Wiz nennt den 19. August 2026 für die erste entdeckte Lücke und den 24. August 2026 für die Meldung an das PHP-Sicherheitsteam. Beide Darstellungen können nebeneinander stehen, weil mehrere Gruppen unabhängig arbeiteten. Welche Gruppe zuerst meldete, ist anhand der Quellen nicht abschließend zu klären.

Eine Einordnung des Autors: Dieselben Werkzeuge stehen grundsätzlich auch Angreifern zur Verfügung. Das ist eine Bewertung, kein Beleg dafür, dass sie in diesem Fall für Angriffe genutzt wurden.

Patch-Diffing: Wie aus einem Security-Fix ein Exploit werden kann

Der Begriff Patch-Diffing kommt in der BSI-Warnung nicht vor. Er ist hier die fachliche Bezeichnung des Autors für den Vorgang, den das BSI beschreibt. Beim Patch-Diffing werden die Änderungen zwischen der alten und der neuen Programmversion verglichen. Aus dem Unterschied lässt sich ablesen, welche Stelle repariert wurde, und damit, wo die Schwachstelle lag. Bei Open-Source-Projekten wie PHP ist der Patch öffentlich einsehbar, sobald er erscheint.

Das Problem: Ab dem Moment der Veröffentlichung kennen nicht nur Verteidiger die Stelle, sondern auch Angreifer. Wer schneller aus dem Unterschied einen funktionierenden Angriff baut, als Betreiber updaten, gewinnt ein Zeitfenster. KI-Werkzeuge können diese Analyse nach Einschätzung des BSI verkürzen. Das BSI hält eine kurzfristige breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches für „wahrscheinlich“. Zur Begründung schreibt es: „Spätestens seit dem Aufkommen von KI-gestützten Tools zur Exploit-Entwicklung verfügen Akteure über die benötigten Mittel um Patches innerhalb kurzer Zeit zu analysieren und Exploits zu generieren.“

Es ist eine Bewertung des BSI, keine beobachtete Tatsache. Ein konkreter Fall, in dem schädliche KI in diesem Fall Patch-Diffing betrieben hätte, ist in den Quellen nicht belegt. Im Update vom 21. Oktober 2026 hält das BSI wegen der nun verfügbaren technischen Details eine kurzfristige Ausnutzung auf verwundbaren Systemen für wahrscheinlich. In sozialen Medien werde von ersten Angriffsversuchen berichtet, die sich nicht verifizieren ließen.

Für Betreiber folgt daraus eine einfache Regel: Das Zeitfenster zwischen Veröffentlichung eines Patches und dessen Einspielen ist so klein wie möglich zu halten. Nach Einschätzung des Autors war genau dieses Zeitfenster von wenigen Stunden bei einer vorab angekündigten Lücke ein wichtiger Grund für die Abschaltungen. Eine Aussage der Hoster dazu liegt nicht in jedem Fall vor.

Warum Hoster Websites vom Netz nahmen

Das BSI schreibt in Update 1, einige Betreiber von PHP-Webservern hätten im Laufe des Tages Systeme vorsorglich vom Internet getrennt, um Angriffe über die vorübergehend ungepatchten Lücken zu verhindern. Dadurch waren verschiedene Websites in Deutschland zeitweise offline oder nur eingeschränkt erreichbar, bis die betroffenen Server aktualisiert waren. Anbieter von Web Application Firewalls (WAF), also Filtern vor Webanwendungen, darunter Cloudflare und Bunny Shield, veröffentlichten Regeln für die bisher bekannten Angriffspfade. Vollständigen Schutz bieten laut BSI nur Patchen oder Trennen vom Internet.

Als Beispiel taugt der Hoster mittwald. Der Statuseintrag des Anbieters trägt den Titel „Vorsorgliche Einschränkungen aufgrund der aktuellen PHP-Sicherheitslücke“. Er begann am 21. Oktober 2026 um 14:16 Uhr (MESZ) mit der Ankündigung, vorab Formular-Uploads zu deaktivieren. Um 16:17 Uhr schrieb mittwald, eine Gefährdung der Systeme lasse sich nicht ausschließen, daher würden alle Systeme heruntergefahren und der eingehende Web-Traffic blockiert. E-Mail blieb funktionsfähig. Die Patches für PHP 7.2 bis 8.5 waren laut Eintrag um 22:52 Uhr ausgerollt.

Am 22. Oktober 2026 um 00:28 Uhr wurde der Eintrag auf „Gelöst“ gesetzt. Behoben sei die Lücke für nahezu alle betroffenen Versionen, ausgenommen Versionen unter PHP 5.6 ohne offizielle Sicherheitsupdates. Hinweise auf eine Ausnutzung gab es laut mittwald nicht. Zu anderen Hostern liegen keine geprüften Primärquellen vor.

Die Begründung der Abschaltungen ergibt sich aus der Lage. Auf einer Hosting-Plattform laufen viele Kundenprojekte mit unterschiedlichen PHP-Versionen. Jede Variante muss gepatcht, getestet und neu gestartet werden. Das kostet Zeit. Die Lücken lassen sich ohne Anmeldung aus der Ferne ausnutzen, und die Details waren ab dem Veröffentlichungstermin öffentlich. Eine vorübergehende Sperre des eingehenden Verkehrs ist dann die Maßnahme, die laut BSI verlässlich schützt. Ob eine Plattform das tut, ist eine Abwägung zwischen Erreichbarkeit und Risiko. Wie viele Websites insgesamt betroffen waren, ist nicht belegt. Zahlen im Millionenbereich werden in den geprüften Primärquellen nicht belegt.

Was Betreiber von PHP- und WordPress-Websites jetzt tun sollten

Bei Shared Hosting und Managed Hosting liegt die Verantwortung für PHP meist beim Anbieter. Hier hilft ein Blick auf die Statusseite und gegebenenfalls eine Nachfrage beim Support. Dinge, die der Hoster verwaltet, sollten nicht eigenmächtig geändert werden. Wer einen eigenen Server oder virtuellen Server betreibt, muss selbst handeln. Das BSI empfiehlt folgende Schritte:

1. PHP-Version prüfen, auf dem Server mit php -v oder im Hosting-Panel. Bei Linux-Paketen den Stand der Distribution abgleichen, da Korrekturen oft als Backport ohne neue Versionsnummer erscheinen. Ubuntu, Debian und Red Hat veröffentlichen eigene Advisories.
2. Patchen: auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf das Paket der Distribution mit Korrektur.
3. Anwendungen in Docker-Containern neu bauen, da dort ein eigenes PHP enthalten ist.
4. Abgekündigte Versionen auf einen unterstützten Zweig migrieren oder bei einem LTS-Anbieter absichern.
5. Falls ein Patch nicht sofort möglich ist: Server vorübergehend vom Internet trennen. Sind weder Patch noch Trennung möglich, mindestens die Workarounds des PHP-Projekts umsetzen.
6. Eine WAF als Ergänzung einsetzen, den Zugriff auf Webanwendungen restriktiv gestalten und Komponenten härten.
7. Logs und Server auf Auffälligkeiten beobachten. Verbindliche Erkennungsmerkmale gibt es laut BSI noch nicht.

Bei den Workarounds nennt das PHP-Projekt unter anderem memory_limit=-1 (möglichst so gesetzt, dass Anwendungen es nicht überschreiben können), ein niedriges post_max_size, session.upload_progress.enabled=0 und bei PHP 8.5 fatal_error_backtraces=0. Danach sind alle Worker neu zu starten. RLIMIT_AS und RLIMIT_DATA sollen nicht als Ersatz dienen.

Warum Workarounds keinen Ersatz für das Update bieten

Das BSI hält in seinem Update zur Lage fest:

Das BSI versteht die Workarounds nur als Überbrückung und verlangt, dass alle zusammen umgesetzt werden. Die Maßnahmen des PHP-Projekts reduzieren die Angriffsfläche, schließen sie aber nicht. Jeder Workaround sperrt einen bestätigten Weg, etwa über Sessions oder Backtraces, andere Varianten bleiben ungeblockt. Beim Speicherlimit-Fehler kann zudem ein Fehlschlag der darunterliegenden Speicherzuweisung den verwundbaren Codepfad weiter erreichen. Das PHP-Projekt schreibt in beiden Advisories, dass nur ein Update mit dem vollständigen Zustandsabgleich zuverlässig schützt.

Die Überbrückung hat trotzdem ihren Sinn, wenn ein Update an organisatorischen Hürden scheitert, etwa bei Software, die nur mit einer alten PHP-Version läuft. Der Weg ist dann als Notlösung zu verstehen, die dokumentiert und zeitlich begrenzt wird. Dauerhafte Sicherheit entsteht erst durch eine unterstützte PHP-Version und ein gepflegtes System.

Was noch offen ist

Bei einer so jungen Lage bleiben viele Punkte ungeklärt. Hilfreich ist die Dreiteilung in belegt, unbestätigt und offen.

• Tatsächliche Ausnutzung: Das BSI kennt keine bestätigten Angriffe, aber unbestätigte Berichte über Exploits und Angriffsversuche. Wie sich das entwickelt, ist offen.
• Veröffentlichungstermin: Das PHP-Projekt behielt sich vor, früher zu veröffentlichen, falls Details bekannt werden. In Medienberichten ist von einem Leak die Rede. Calif und Wiz beschreiben dagegen eine koordinierte Offenlegung. Aus Primärquellen lässt sich ein Leak nicht belegen.
• Zahl betroffener Websites: Wiz schreibt, PHP laufe auf rund 70 Prozent aller Websites, nennt dafür aber keine Quelle. Als gesicherte Zahl taugt das nicht.
• Stand bei einzelnen Hostern: Nur für mittwald liegt eine geprüfte Statusmeldung vor. Bei anderen Anbietern ist der Stand bei Bedarf dort zu erfragen.
• Weitere Varianten: Die Advisories weisen darauf hin, dass es keine vollständige generische Konfigurationsmaßnahme gibt. Weitere Wege sind nicht ausgeschlossen.
• Rolle der KI: Der Einsatz beim Fund ist durch die Hersteller belegt. Der Einsatz durch Angreifer ist eine Bewertung des BSI, kein beobachteter Fall.

Kurz gefasst: Die PHP-Sicherheitslücke ist real, kritisch und seit dem 21. Oktober 2026 durch Updates behoben. Wer PHP selbst betreibt, muss das Update einspielen, der Rest hängt vom Hoster ab. Die Frage nach KI-gestützter Ausnutzung bleibt vorerst eine begründete Befürchtung und kein bewiesener Befund.