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

Kategorien: Datenschutz und Security

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.

Spätestens am 26.10.2026 wurde bekannt, dass die PHP-Sicherheitslücke erfolgreich ausgenutzt werden konnte. HackerNews berichtet, dass die Ausnutzungsversuche weiter gehen. Schnelles handeln ist also unbedingt erforderlich!

Deutsche Provider haben schnell reagiert

Anhand zweier Beispiele konnte am Tag des Problems nachvollzogen werden, dass deutsche Provider schnell reagierten.

Mittwald war fast schon übervorsichtig und schaltete vorsorglich nicht nur alle Kunden-Webseiten ab, sondern auch seine eigene (mittwald.de). Ein paar Stunden nach der Störung gab es regelmäßige Status-Updates:

Kunden mussten später die richtige PHP-Version (mit dem Patch) in ihrem Kundenkonto auswählen, sofern Mittwald dies nicht automatisch erledigt hatte.

Bei ALL-INKL gab es keinen so langen Shutdown wie bei Mittwald. Auch die ALL-INKL Webseite blieb online.

ALL-INKL Kunden mussten nichts tun. Ihre PHP-Versionen wurden automatisch hochgestuf. Bei ALL-INKL ist es sowieso einfacher als bei Mittwald: Statt der Unterunterversionsnummern (wie 8.2.35) gibt es bei ALL-INKL nur eine Unterversion (8.2) und gut ist. Das funktioniert.

Einen Tag nach dem Spuk meldete ALL-INKL Vollzug:

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.

Auch Firewalls sind betroffen

Palo Alto Networks meldete in einem Update seines Advisories zu CVE-2026-109618, dass PHP2Shell aktiv gegen aus dem Internet erreichbare PAN-OS- und Panorama-Management-Interfaces ausgenutzt wird. Hotfixes erscheinen gestaffelt, einige davon am 29. und 30.10.

Dream beschreibt eine Kette aus PHP2Shell und der Linux-Rechteausweitung „Fragnesia“ (CVE-2026-46300), mit der 25 Server gerootet wurden.

CISA hat CVE-2026-46300 am 28.10. in den KEV-Katalog aufgenommen. (The Hacker News, auch Heise berichtetet).

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