PHP2Shell: Was hinter den zwei kritischen PHP-Lücken steckt und was du jetzt tun musst

Am 21. Oktober 2026 hat das PHP-Projekt zwei Sicherheitslücken geschlossen, die in der Szene schnell den Namen PHP2Shell bekamen, in Anlehnung an Log4Shell. Der Vergleich ist nicht übertrieben: Beide Lücken erlauben es einem Angreifer, ohne Anmeldung eigenen Code auf dem Webserver auszuführen, mit den Rechten des PHP-Prozesses. Und PHP läuft laut W3Techs auf rund 69 Prozent aller Websites, deren Serversprache bekannt ist.

Die zwei Lücken in einfachen Worten

Beide Fehler stecken nicht in WordPress, Laravel oder einer Bibliothek, sondern im PHP-Kern selbst. Deshalb hilft es nicht, „nur“ das CMS aktuell zu halten.

• CVE-2026-109618 – Speicherfehler bei „Out of Memory“. Geht PHP mitten in der Vorbereitung einer Anfrage der Speicher aus, bricht es ab. Die anschließende Aufräumroutine behandelt halb vorbereitete Daten aber so, als wären sie gültig. Ein präparierter Multipart-Upload kann diesen Zustand gezielt herbeiführen, auch wenn er innerhalb der konfigurierten Größenlimits bleibt. Unter Apache mit mod_php funktioniert das, bevor überhaupt eine Zeile Anwendungscode läuft.
• CVE-2026-109619 – Use-after-free über Anfragen hinweg. Ein PHP-Worker bearbeitet viele Anfragen nacheinander. Bestimmter globaler Zustand (Fehler, Sessions, Erweiterungen) kann die Anfrage überleben, die ihn erzeugt hat, und zeigt dann auf bereits freigegebenen Speicher. Die nächste Anfrage im selben Worker greift darauf zu. Bestätigte Wege führen über den Upload-Fortschritt von Sessions, der standardmäßig aktiv ist und ganz ohne session_start() greift, sowie über die in PHP 8.5 neuen Fatal-Error-Backtraces.

Das PHP-Team bewertet beide Lücken mit CVSS 4.0 von 9,2. Vorab kursierende Angaben von 10,0 nennt die PHP Foundation falsch, an der Dringlichkeit ändert das nichts.

Wie es ablief

• August 2026: Die Sicherheitsfirmen Calif und Wiz finden die Fehler unabhängig voneinander, beide nach eigenen Angaben mit Hilfe von KI-Modellen. Beteiligt war auch OpenAI.
• 17. Oktober: Amazon Threat Intelligence sieht in seinem Honeypot-Netz bereits einen Angriffsversuch, vier Tage vor der Veröffentlichung.
• 20. Oktober: Die CVE-Nummern sickern über Hacker News und soziale Medien durch, dazu ein versehentlich veröffentlichtes Demo-Video. Das PHP-Team zieht den Patch-Termin um einen Tag vor.
• 21. Oktober, 16 Uhr deutscher Zeit: PHP veröffentlicht die korrigierten Versionen. Am selben Tag melden Amazon, Cloudflare und watchTowr Angriffsversuche, das BSI gibt eine Cybersicherheitswarnung heraus.

Wer betroffen war

Betroffen ist praktisch jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Den ältesten betroffenen Codepfad datiert Calif auf PHP 5.4. Als besonders gefährdet gilt mod_php. Calif gibt an, Codeausführung vor der Anmeldung gegen bestimmte Versionen von WordPress, Drupal, Joomla und Magento bestätigt zu haben. Schätzungen zur Angriffsfläche reichen bis über 1,3 Millionen erreichbare, potenziell verwundbare Hosts.

Spürbar wurde das vor allem daran, wer vorsorglich abgeschaltet hat. Berichten zufolge gingen unter anderem das niederländische Portal Overheid.nl, öffentliche Webdienste der finnischen Regierung und Websites des französischen Innenministeriums vom Netz. Die Wikimedia Foundation fuhr Hilfsdienste wie Phabricator herunter, das Internet Archive war kurz offline, ebenso Foren wie 4chan. In Japan gingen mehrere Online-Spiele und Shops in Notwartung. CERT-EU und das britische NCSC empfahlen ausdrücklich, Systeme vom Netz zu nehmen, die sich nicht sofort aktualisieren lassen.

Was du jetzt tun musst

1. Aktualisieren, und zwar sofort. Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Distributionen und LTS-Anbieter wurden vorab versorgt, prüfe also die Pakete deines Systems. Für PHP 7.4 bis 8.1 gibt es nur Quellcode-Backports, für alles darunter gar keinen Fix mehr.

php -v
# Laufende Worker nach dem Update neu starten, sonst läuft der alte Code weiter
systemctl restart php8.3-fpm   # bzw. apache2 bei mod_php

2. Übergangsweise absichern, falls das Update noch Stunden dauert. Die Maßnahmen müssen in der Server- oder Pool-Konfiguration stehen, nicht per ini_set() oder .user.ini, die greifen zu spät:

session.upload_progress.enabled = 0
fatal_error_backtraces = 0      ; nur PHP 8.5
memory_limit = -1               ; administrativ erzwungen, nicht überschreibbar

Danach alle Worker neu starten. Wichtig: Das PHP-Team sagt ausdrücklich, dass es keine vollständige Konfigurationslösung gibt. Die Einstellungen schließen nur die bekannten Wege. Die Cloudflare-WAF-Regeln helfen ebenfalls nur für Verkehr, der über Cloudflare läuft.

3. Nach Spuren suchen. Weil schon vor dem Patch angegriffen wurde, reicht „jetzt aktuell“ nicht. Rapid7 weist darauf hin, dass fehlende Logeinträge keine Entwarnung sind. Prüfe auf unbekannte PHP-Dateien im Webroot, neue Cronjobs und ungewöhnliche ausgehende Verbindungen. Das NCSC warnt ausdrücklich vor zurückgelassenen Hintertüren.

4. Keinen „Exploit“ aus dem Netz testen. Laut Tenable kursiert ungeprüfter Exploit-Code. Er kann selbst Schadsoftware sein.

Was ich daraus mitnehme

Zwei Dinge fallen auf. Erstens lag einer der Fehler laut Berichten schon seit einem Audit 2024 auf dem Tisch, ohne dass man sich auf einen Fix einigen konnte. Zweitens wurden beide Lücken mit KI-Unterstützung gefunden. Das gilt in beide Richtungen: Wer verteidigt, findet Fehler schneller, wer angreift, auch. Die Zeit zwischen Veröffentlichung und Angriff schrumpft auf Stunden. Patchen nach dem nächsten Wartungsfenster ist für solche Lücken keine Option mehr. Wer viele PHP-Systeme betreibt, braucht einen Weg, ein Update am selben Tag auszurollen und zu prüfen, dass es wirklich läuft.

Quellen

• BSI-Cybersicherheitswarnung zu PHP2Shell
• PHP-Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Rapid7: technische Analyse und Gegenmaßnahmen
• Tenable: FAQ zu PHP2Shell
• Wikipedia: PHP2Shell (Chronik und betroffene Dienste)