PHP2Shell (CVE-2026-109618): Bin ich betroffen und was tun?

Was passiert ist

Das PHP-Projekt hat am 21. Oktober 2026 zwei kritische Sicherheitslücken im PHP-Kern veröffentlicht:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): „RCE via OOM corruption“, Remote Code Execution ohne Login, CVSS 4.0: 9.2. Laut CVSS-Vektor ist der Angriff komplex und an Voraussetzungen gebunden (AC:H, AT:P).
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): „RCE via stale global state“, ein Use-after-free zwischen zwei Requests im selben Worker, ebenfalls CVSS 4.0: 9.2.

Laut Advisory wurde die vollständige Codeausführung gegen mod_php mit Standardeinstellungen nachgewiesen. Für PHP-FPM gibt es laut Advisory noch keinen vollständigen Exploit, FrankenPHP gilt als wahrscheinlich angreifbar, bei LiteSpeed (LSAPI) sind anwendungsspezifische Exploits wahrscheinlich. Die PHP-Release-Meldung nennt PHP-FPM, mod_php, php-cgi, FrankenPHP und LiteSpeed als betroffen.

Betroffene und gefixte Versionen

Das Advisory nennt das Update als einzige vollständige Abhilfe. Welche PHP-Versionen überhaupt noch Updates bekommen, steht in der End-of-Life-Übersicht.

Wird die Lücke ausgenutzt?

• Amazon Threat Intelligence hat einen ersten Ausnutzungsversuch auf einem Honeypot am 17. Oktober beobachtet, vier Tage vor der Veröffentlichung, und am 21. Oktober mehrere Proof-of-Concept-Exploits verschiedener Akteure. Ob Versuche erfolgreich waren, ist laut Amazon offen.
• Cloudflare hat nach eigenen Angaben ab dem 21. Oktober, 03:02 UTC, etwa neun Stunden vor der Veröffentlichung, WAF-Regeln für alle Kunden aktiviert und Angriffsverkehr beobachtet.
• Nach Auswertungen von Censys, über die heise berichtet, zeigten am 23. Oktober von knapp 11 Millionen PHP-Diensten in Deutschland rund 4,2 Millionen eine verwundbare Versionsnummer. Weil Distributionen Fixes zurückportieren, beweist die Versionsnummer allein aber keine Verwundbarkeit.
• Die CISA hat am 21. Oktober zum sofortigen Patchen aufgerufen. Im KEV-Katalog der CISA standen die beiden CVEs am 23. Oktober noch nicht. Warum das kein Grund zum Abwarten ist, erklärt der Artikel zu CVSS, EPSS und CISA KEV.

Bin ich betroffen? So prüfst du es

Auf jedem System, das PHP-Requests bedient:

php -v

Achte darauf, die PHP-Version zu prüfen, die wirklich Requests beantwortet. CLI und FPM können verschiedene Versionen sein:

php-fpm -v

In Repos mit Docker steht die Version meist im Basis-Image:

grep -rn "FROM php:" --include=Dockerfile* .

Weitere Stellen, an denen PHP-Versionen in Repos stehen: .php-version, composer.json ("require": {"php": ...} gibt nur den erlaubten Bereich an, nicht die laufende Version), CI-Configs wie .github/workflows/*.yml (php-version:) und Infrastruktur-Code.

Fallstricke

Distributionen mit Backports. Debian, Ubuntu und RHEL patchen oft, ohne die PHP-Versionsnummer anzuheben. php -v zeigt dann eine „alte“ Version, die trotzdem gefixt ist, oder umgekehrt. Maßgeblich ist die Paketversion laut Security-Tracker deiner Distribution.

Worker laufen weiter. Nach dem Update laufen PHP-FPM-Worker und mod_php mit dem alten Code weiter, bis sie neu gestartet werden. Bei Docker heißt das: Image neu bauen und Container ersetzen, zum Beispiel:

docker compose build --pull && docker compose up -d

Gepinnte Images. FROM php:8.3-fpm zieht beim nächsten Build die gefixte Version, FROM php:8.3.35-fpm nicht. Prüfe auch Images, die selten gebaut werden.

Paket-Scanner sehen es nicht. Dependabot und andere SCA-Werkzeuge prüfen Pakete aus der composer.lock. Eine Lücke im PHP-Interpreter ist kein Composer-Paket. Mehr dazu im Vergleich mit Dependabot.

Was du jetzt tust

1. Alle Systeme und Repos mit PHP auflisten, auch selten deployte.
2. Auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 aktualisieren, bei Distributions-PHP auf das gefixte Paket.
3. PHP-FPM, Webserver beziehungsweise Container neu starten.
4. Mit php -v und php-fpm -v auf dem laufenden System nachprüfen.
5. Logs auf auffällige Requests seit dem 17. Oktober sichten, wenn du verwundbar online warst.

Wenn du nicht sofort patchen kannst

Diese Maßnahmen ersetzen kein Update, sie verringern nur das Risiko bis dahin:

• Eine Web Application Firewall mit Regeln für PHP2Shell vorschalten, sofern dein Anbieter welche bereitstellt.
• Die in der PHP-Meldung genannten Konfigurationsänderungen setzen, etwa session.upload_progress.enabled=0. Laut PHP machen diese Einstellungen ein System nicht sicher.
• Betroffene Dienste, die nicht öffentlich erreichbar sein müssen, vom Netz nehmen. Das BSI hat laut heise empfohlen, Websites vorsorglich offline zu nehmen.

Am 23. Oktober hat das PHP-Projekt zusätzlich einen informativen Hinweis zu CVE-2026-115560 (Session Upload Progress) veröffentlicht. PHP stuft diesen Angriffsweg als unwahrscheinlich ein und empfiehlt bis zum nächsten regulären Release ebenfalls session.upload_progress.enabled=0.

Quellen

• PHP Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• php.net: Meldung vom 21. Oktober 2026
• php.net: Hinweis vom 23. Oktober 2026 (Session Upload Progress)
• AWS Security Blog: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure
• Cloudflare Blog: WAF-Schutz für die PHP-Lücken
• heise: PHP2Shell, Millionen PHP-Dienste in Deutschland verwundbar
• heise: Updates rollen aus, Websites gehen offline
• CISA Alert vom 21. Oktober 2026