Knapp eine Woche nach den Notfall-Updates ist aus der Warnung ein bestätigter Angriffsfall geworden: Die US-Cybersicherheitsbehörde CISA hat am Montag die beiden als „php2shell“ bekannt gewordenen Lücken im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, in ihren Katalog aktiv ausgenutzter Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen. US-Bundesbehörden müssen bis zum 29. Oktober reagieren. Für Admins ist das der Anlass, den eigenen Patchstand noch einmal genau zu prüfen. Denn auf vielen Linux-Servern zeigt php -v nach dem Update dieselbe Versionsnummer wie vorher – und das ist kein Fehler.

Was hinter php2shell steckt

Beide Lücken sitzen nicht in einer Anwendung, sondern in PHP selbst. Das PHP-Projekt beschreibt CVE-2026-109618 als Codeausführung über Speicherkorruption bei Out-of-Memory-Fehlern: Bricht PHP eine Anfrage wegen Speichermangels ab, während interne Daten erst teilweise initialisiert sind, behandelt das Aufräumen am Ende der Anfrage diese Daten als gültig. Bei CVE-2026-109619 überlebt interner Zustand einer Anfrage, obwohl der zugehörige Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Worker kann diesen veralteten Zustand nutzen, bevor er zurückgesetzt wird. Eine Anmeldung ist laut den Advisories nicht nötig; Angreifer erhalten im Erfolgsfall die Rechte des Webserver-Prozesses.

Betroffen sind nach Angaben des PHP-Teams alle Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am höchsten schätzt das Team das Risiko bei mod_php ein. Dort wurde ein Exploit demonstriert, der ohne Anmeldung greift, bevor überhaupt Anwendungscode läuft. Für PHP-FPM hält das Advisory zu CVE-2026-109618 einen Angriff für wahrscheinlich möglich, ein vollständiger Exploit sei aber nicht gezeigt worden. Den Angriffsweg über die Funktion Session Upload Progress (CVE-2026-109619) haben die Entwickler dagegen sowohl gegen mod_php als auch gegen FPM nachvollzogen.

Nach Angaben von Wiz Research, das an der Entdeckung beteiligt war, reichen die Fehler bis PHP 5.4 zurück. Eine Schwachstelle in der eigenen Anwendung braucht es nicht: Wiz demonstrierte Angriffe auf die aktuellen Container-Images von WordPress, Drupal und Joomla. Behoben sind die Lücken in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es keine offiziellen Releases mehr; das PHP-Sicherheitsteam hat wegen der Schwere aber minimale Quell-Backports für 7.4, 8.0 und 8.1 veröffentlicht. Auch das BSI hatte gewarnt und betont, dass ein Update der Anwendung nicht reicht – die PHP-Laufzeitumgebung selbst muss gepatcht werden.

Reihen von Serverschränken in einem großen Rechenzentrum (Symbolbild)

Bild: Serverraum im CERN (Symbolbild) – Foto: Florian Hirzinger / Wikimedia Commons, CC BY-SA 3.0

Honeypot-Treffer, ein Rückzieher und jetzt der KEV-Eintrag

Die Lage war in den vergangenen Tagen unübersichtlich. CrowdStrike berichtete am 23. Oktober, weder im Feld noch in eigenen Honeypots erfolgreiche Angriffe gesehen zu haben. Einen universell funktionierenden Exploit hält das Unternehmen für unwahrscheinlich, weil Angreifer ihren Code an PHP-Version, Betriebsart und Anwendung anpassen müssten. Am 24. Oktober zählte der Perplexity-Forscher Adel Karimi dann nach einem Bericht von SecurityWeek 35 Shells auf drei Honeypots mit PHP 8.4.26 unter Apache und mod_php. Der Angriffsverkehr glich einem öffentlich verfügbaren Proof of Concept und passt zu CVE-2026-109618. Karimi schränkt selbst ein, dass sein Aufbau mit nur einem Worker bewusst angreiferfreundlich war.

Für Verwirrung sorgte Palo Altos Sicherheitsteam Unit 42. Es ergänzte seinen Threat Brief am 23. Oktober um einen Angriff auf eine europäische Regierungsbehörde, den es mit php2shell in Verbindung brachte. Am 25. Oktober zog Unit 42 diesen Abschnitt zurück: Man habe zwar einen Angriff im Umfeld einer verwundbaren PHP-Anwendung beobachtet, könne aber nicht bestätigen, dass der Erstzugriff über die php2shell-Lücken erfolgt sei. Berichte, die diesen Fall als ersten bestätigten php2shell-Angriff darstellen, sind damit überholt. Die CISA hatte am 23. Oktober noch erklärt, keine erfolgreiche Ausnutzung beobachtet zu haben – mit dem KEV-Eintrag vom 26. Oktober gilt sie nun offiziell als belegt.

9,2 oder 9,8? Und was ist CVE-2026-115560?

Bei der Schwere kursieren unterschiedliche Zahlen, die sich aber nicht widersprechen. Das PHP-Projekt bewertet beide Lücken nach CVSS 4.0 mit 9,2 von 10. Die US-Schwachstellendatenbank NVD hat eigene Werte nach dem älteren CVSS 3.1 vergeben: 9,8 für CVE-2026-109618 und 8,1 für CVE-2026-109619. Es handelt sich schlicht um verschiedene Bewertungssysteme.

Am 23. Oktober hat das PHP-Team außerdem auf ein separates Problem hingewiesen. CVE-2026-115560 betrifft ebenfalls Session Upload Progress, setzt aber eine ungewöhnliche Kombination voraus: Eine Anwendung muss session.serialize_handler auf php_binary oder php_serialize konfigurieren und zur Laufzeit per ini_set() auf php umstellen, bevor sie session_start() aufruft. Das Team hält diesen Aufbau für unwahrscheinlich, will den Fehler im regulären Release-Zyklus beheben und empfiehlt bis dahin, Session Upload Progress abzuschalten. Ein vollständiges Advisory soll mit dem nächsten Release folgen.

Gepatcht ohne neue Versionsnummer

Linux-Distributionen hatten die Patches vorab erhalten, setzen sie aber unterschiedlich um. Debian hat die neuen Upstream-Versionen übernommen: Debian 13 bekommt PHP 8.4.27 (Paket 8.4.27-1~deb13u1, DSA-6574-1), Debian 12 über das LTS-Team PHP 8.2.35 (8.2.35-1~deb12u1, DLA-4848-1). Ubuntu portiert die Korrekturen dagegen in die ausgelieferte Version zurück (USN-8948-1 vom 21. Oktober). Auf Ubuntu 26.04 LTS meldet PHP nach dem Update deshalb weiterhin Version 8.5.4; gepatcht ist das Paket ab 8.5.4-0ubuntu1.5. Für Ubuntu 24.04 lautet die korrigierte Paketversion 8.3.6-0ubuntu0.24.04.13, für 22.04 8.1.2-1ubuntu2.28. Ältere LTS-Versionen erhalten Fixes nur über Ubuntu Pro.

Ein Abgleich von php -v mit der Liste der PHP-Releases führt bei solchen Backports in die Irre. Aussagekräftig sind Paketversion und Changelog:

# Laufende PHP-Version – bei Backports wenig aussagekräftig
php -v

# Installierte Paketversion (Ubuntu 26.04: gepatcht ab 8.5.4-0ubuntu1.5)
dpkg -l 'php8.5*' | grep ^ii

# Enthält das Paket die php2shell-Patches?
apt changelog php8.5-fpm | grep CVE-2026-1096

Im Changelog des Ubuntu-Pakets tauchen die Patches als CVE-2026-109618_109619 auf; auf einem von uns geprüften Ubuntu-26.04-Server lieferte der Befehl genau diese Einträge. Wer mod_php nutzt, fragt statt php8.5-fpm das Paket libapache2-mod-php8.5 ab. Unter Debian zeigt der Security Tracker für jede CVE, ab welcher Paketversion ein Release als behoben gilt.

Was du jetzt tun solltest

Updates einspielen und PHP neu starten. Der korrigierte Code läuft erst, wenn PHP-FPM beziehungsweise Apache neu gestartet wurden; darauf weist auch CrowdStrike hin. Wer bei einem Hoster liegt, sollte dort nachfragen.

Session Upload Progress abschalten. Die Funktion ist standardmäßig aktiv und Teil der bestätigten Angriffswege. Das Advisory zu CVE-2026-109619 rät, sie auch nach dem Patch ausgeschaltet zu lassen, wenn man sie nicht braucht. Gebraucht wird sie laut PHP-Handbuch nur von Anwendungen, die den Fortschritt eines Uploads gezielt aus $_SESSION auslesen. Laravel verwaltet Sessions mit eigenen Treibern und ruft PHPs session_start() gar nicht auf; Symfony hat seine upload_progress-Optionen schon mit Version 5.4 als veraltet markiert. Wichtig: Die Einstellung muss in der php.ini oder der FPM-Pool-Konfiguration stehen, ini_set() und .user.ini greifen zu spät.

# Beispiel Ubuntu/Debian mit PHP-FPM 8.5 – Version und Pfad anpassen
echo "session.upload_progress.enabled = Off" | sudo tee /etc/php/8.5/fpm/conf.d/99-upload-progress.ini
sudo systemctl restart php8.5-fpm

# Kontrolle
php-fpm8.5 -i | grep session.upload_progress.enabled

Für mod_php gehört die Datei nach /etc/php/8.5/apache2/conf.d/, danach Apache neu starten. Die Abschaltung ersetzt das Update nicht: Laut PHP-Team blockiert sie nur die bestätigten Session-Pfade, nicht andere Varianten.

Bei Verdacht Zugangsdaten tauschen. Über die Lücken lässt sich laut Wiz Speicher des PHP-Workers auslesen, der Passwörter, Tokens, API-Schlüssel und Zertifikate aus anderen Anfragen enthalten kann. Varonis rät, solche Daten als kompromittiert zu betrachten, wenn ein Angreifer vor dem Patch an den Worker-Speicher kommen konnte. Bei einer Laravel-App gehören dazu etwa Datenbank-Passwort, API-Schlüssel und APP_KEY aus der .env.

Logs prüfen. Als Anzeichen nennt Wiz ungewöhnliche Multipart-Anfragen mit anschließenden Speicherlimit-Fehlern, gehäufte HTTP-500-Antworten, auffällig große oder fehlerhafte PHPSESSID-Cookies und unerklärlich häufig neu startende Worker. Das BSI empfiehlt zusätzlich, auf Shells und Download-Werkzeuge zu achten, die der Webserver-Prozess startet, und nach neuen oder veränderten PHP-Dateien zu suchen.

Wer nicht sofort aktualisieren kann, findet im Advisory des PHP-Projekts Notbehelfe wie memory_limit=-1 und ein knapp bemessenes post_max_size. Das PHP-Team stellt aber klar: Vollständigen Schutz bietet nur das Update.

Quellen

Bildnachweis