Was passiert ist
Am 21. Oktober veröffentlichte das PHP-Projekt Fixes für zwei Schwachstellen, CVE-2026-109618 und CVE-2026-109619. Beide sind mit CVSS 9.2 bewertet und können laut der Analyse von Arctic Wolf einem nicht authentifizierten Angreifer erlauben, Code auf einem Server auszuführen, der Web-Requests mit PHP verarbeitet.
Die Bugs stecken im Request-Lebenszyklus von PHP selbst, nicht in einem Framework oder Plugin:
- CVE-2026-109618 ist eine Speicherbeschädigung, die ausgelöst wird, wenn ein Out-of-Memory-Zustand PHP unterbricht, während die Request-Daten erst teilweise aufgebaut sind.
- CVE-2026-109619 ist ein Use-after-free: Zustand eines Requests kann überleben und von einem späteren Request auf demselben Worker gelesen werden, wodurch auch Speicherinhalte durchsickern können.
Beim zweiten Punkt lohnt es sich, kurz innezuhalten. Qualys weist darauf hin, dass durchgesickerter Worker-Speicher Passwörter, Tokens und API-Keys enthalten kann. Selbst wenn also niemand eine Shell auf deinem Server bekommt, können Secrets abfließen.
Nach dem Patch ging alles sehr schnell, und das Ausmaß ist groß: The Hacker News zitiert Schätzungen von Censys, wonach mehr als 32 Millionen PHP-Dienste noch eine betroffene Version ausführen.
- Das Threat-Intelligence-Team von Amazon gibt an, dass die Angriffe vier Tage vor Veröffentlichung der Fixes begannen, wie BleepingComputer berichtet.
- Am 24. Oktober bestätigte ein Forscher bei Perplexity erfolgreiche Codeausführung gegen Honeypots (The Hacker News).
- Am 26. Oktober nahm die CISA beide CVEs in ihren Katalog Known Exploited Vulnerabilities auf und gab US-Bundesbehörden bis zum 29. Oktober Zeit, sie zu beheben.
Warum das auch für kleine Apps relevant ist
Angreifer wählen ihre Ziele hier nicht nach Unternehmensgröße. Sie scannen das Internet nach allem, was wie PHP antwortet, und probieren den Exploit aus. Ein vergessenes Nebenprojekt auf einem VPS ist genauso erreichbar wie ein großer Onlineshop.
Ein paar Details machen diesen Fall besonders dringend:
- Es hängt nicht von deinem Code ab. Arctic Wolf betont, dass die Lücken in der Request-Verarbeitung von PHP liegen und die Gefährdung daher nicht davon abhängt, welche Anwendung du betreibst. Eine perfekt geschriebene Laravel-App auf einem alten PHP-Build ist trotzdem angreifbar.
- Viele Server-Setups sind betroffen. Apache mit mod_php gilt als höchstes Risiko, aber auch PHP-FPM, php-cgi, FrankenPHP und LiteSpeed werden als betroffen genannt, ebenso Produkte und Appliances, die PHP mitbringen.
- Altes PHP ist verbreitet. Qualys berichtet, dass etwa 71 % der PHP-Installationen, deren Version es ermitteln konnte, bereits End-of-Life waren. Wenn du auf 8.1 oder älter bist, gibt es für dich keinen regulären Upstream-Fix.
So prüfst du deine App
Du suchst pro Server eine Antwort: Verarbeitet hier etwas Web-Requests mit PHP, und in welcher genauen Version?
1. Liste alles auf, was du hostest. Nicht nur die Haupt-App. Dazu gehören Marketingseiten, Blogs, Docs, Staging-Umgebungen, Admin-Tools und alles auf einer Subdomain. Die vergessenen sind die gefährlichen.
2. Sieh dir die Response-Header an. Viele PHP-Setups verraten sich in einem X-Powered-By- oder Server-Header. Kein Header heißt nicht kein PHP (er lässt sich mit expose_php = Off abschalten), aber ein Header ist ein schnelles Ja. Ausführliche Fehlerseiten sind ein weiteres Indiz: Ein PHP-Stacktrace in Produktion verrät einem Angreifer genau, was du betreibst.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Prüfe die Version, die den Web-Traffic bedient, nicht nur die CLI. php -v auf dem Server kann einen anderen Build melden als den, den Apache oder PHP-FPM tatsächlich nutzen; Qualys weist ausdrücklich darauf hin. Prüfe das FPM-Binary oder das PHP-Modul deines Webservers, oder frag deinen Hoster.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Vergleiche mit den gefixten Versionen. Wenn du PHP aus deiner Linux-Distribution installierst, kann der Fix in ein Paket mit älter wirkender Versionsnummer zurückportiert sein, prüfe also das Advisory deiner Distribution statt nur den Versionsstring. Andernfalls brauchst du mindestens:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
5. Managed Hosting? Wenn du bei einem Managed-WordPress-Hoster oder einer PaaS bist, prüfe deren Statusseite oder Changelog auf einen PHP2Shell-Hinweis. Die meisten patchen für dich, aber „die meisten“ heißt nicht „alle“, und ein selbst verwalteter VPS liegt komplett bei dir.
So behebst du es
Patchen, dann neu starten. Ein PHP-Update ist die einzige vollständige Lösung.
Der Neustart ist wichtig: Laufende Worker behalten den alten Code im Speicher, bis sie ersetzt werden. Bei Docker baust du auf einem aktualisierten Base-Image neu (zum Beispiel einem aktuellen php:8.3-fpm-Tag) und deployst erneut. Starte nicht einfach den alten Container neu.
Unter Debian oder Ubuntu mit PHP-FPM sieht das meist ungefähr so aus:
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpWenn du heute nicht patchen kannst, fasst Qualys die vorläufigen Gegenmaßnahmen von PHP zusammen. Sie senken das Risiko, machen einen ungepatchten Server aber nicht sicher. Setze sie in der php.ini oder der FPM-Pool-Konfiguration (nicht in .user.ini oder per ini_set) und starte dann alle Worker neu.
Wenn ein Dienst ungepatcht ist und nicht öffentlich sein muss, stell ihn hinter ein VPN oder eine IP-Allowlist, oder nimm ihn offline, bis du aktualisieren kannst.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizeAuf PHP 8.1 oder älter? Plane das Upgrade jetzt. Für einige alte Zweige gibt es begrenzte Backports, aber du verlässt dich jedes Mal auf Glück, wenn so etwas passiert.
Achte auf Anzeichen einer Kompromittierung. Prüfe auf unerwartete Prozesse, neue Dateien im Web-Root, unbekannte Cronjobs und ausgehende Verbindungen vom Webserver. Arctic Wolf weist außerdem darauf hin, dass viele „PHP2Shell“-Requests in Logs ältere Techniken wiederverwenden; eine beängstigend aussehende Logzeile bedeutet also nicht automatisch einen erfolgreichen Einbruch.
Rotiere Secrets, wenn du betroffen warst. Da CVE-2026-109619 Worker-Speicher preisgeben kann, behandle Secrets, die durch einen ungepatchten, aus dem Internet erreichbaren PHP-Prozess gelaufen sind, als potenziell gesehen. Das betrifft Datenbankpasswörter, API-Keys, Session-Signing-Keys und Keys von Zahlungsanbietern. Laravel und ähnliche Frameworks halten diese in der .env, prüfe also auch, dass diese Datei nie über das Web erreichbar war.
Kurze Checkliste
Geh das für jede Domain durch, die dir gehört:
- Jede Domain und Subdomain, die dir gehört, ist erfasst, auch alte Marketing- und Staging-Seiten.
- Du weißt, welche davon PHP nutzen, und kennst die genaue Version, die Web-Traffic bedient.
- Jede läuft auf 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder einem vom Anbieter gepatchten Build.
- PHP-Worker und Webserver wurden nach dem Update neu gestartet.
- Alles Ungepatchte ist eingeschränkt oder offline, mit angewendeten Gegenmaßnahmen.
- Secrets auf betroffenen Hosts wurden rotiert.
- Die Produktion verrät ihre PHP-Version nicht mehr und zeigt keine Stacktraces.
Die größere Lektion
PHP2Shell wird in ein paar Wochen gepatcht und vergessen sein. Das Muster nicht. Die Lücke zwischen „Fix veröffentlicht“ und „wird ausgenutzt“ beträgt inzwischen Tage, manchmal ist sie sogar negativ. Kleine Teams können das nicht mit Heldentaten abhängen. Was funktioniert: zu wissen, was du betreibst, und schnell zu bemerken, wenn sich daran etwas ändert.
Das ist derselbe Gedanke wie hinter unserer Launch-Checkliste für KI-gebaute Apps: Die meisten realen Vorfälle entstehen durch Dinge, die leicht zu prüfen sind, wenn man sie tatsächlich prüft.
AppSafe scannt deine Live-Website von außen, so wie ein Angreifer sie sieht. Es sucht nach Problemen wie fehlenden Security-Headern, einem X-Powered-By-Header, der deinen Stack verrät, offengelegten Dateien und ausführlichen Fehlermeldungen, und gibt dir verständliche Lösungen. Wenn du gepatcht hast, starte einen kostenlosen Scan für jede deiner Domains, um bei der Gelegenheit auch die anderen schnellen Verbesserungen mitzunehmen.