PHP2Shell: Zwei kritische Lücken in PHP selbst – wer betroffen ist und was jetzt zu tun ist (CVE-2026-109618, CVE-2026-109619)

Am 21. Oktober 2026 hat das PHP-Projekt Notfall-Updates für zwei kritische Schwachstellen veröffentlicht, die unter dem Namen „PHP2Shell“ kursieren. Beide erlauben das Ausführen von Code ohne Anmeldung – und zwar nicht in einer bestimmten Anwendung, sondern im PHP-Interpreter selbst. Damit ist praktisch jede öffentlich erreichbare PHP-Installation betroffen: WordPress, Shops, Webmailer, phpMyAdmin, Kundenportale. Dieser Beitrag ordnet ein, wer betroffen ist, wie man den eigenen Stand prüft und was man tun kann, wenn das Update nicht sofort einspielbar ist.

Was ist passiert?

Die Lücken wurden bereits im August von mehreren Forschergruppen unabhängig voneinander gefunden und dem PHP-Sicherheitsteam gemeldet – unter anderem von Calif, Wiz Research und OpenAI. Die koordinierte Veröffentlichung war für den 22. Oktober geplant. Am 20. Oktober sickerten jedoch Details durch, watchTowr bestätigte die Ausnutzbarkeit, und das PHP-Team zog die Veröffentlichung auf den 21. Oktober, 14:00 UTC vor. Cloudflare meldete bereits am Morgen desselben Tages erste Angriffe – also noch vor dem offiziellen Patch. Inzwischen sind technische Beschreibungen und ein Angriffswerkzeug öffentlich. Mit breiter, automatisierter Ausnutzung ist zu rechnen.

Die beiden Schwachstellen im Überblick

Technisch handelt es sich in beiden Fällen um Use-after-free-Fehler: Ein fataler Fehler mitten im Request – typischerweise das Überschreiten von memory_limit – reißt nativen PHP-Code aus der Ausführung, bevor er aufräumt. Ein nachfolgender Request oder ein wiederverwendeter Worker benutzt dann freigegebenen Speicher, den ein Angreifer zuvor mit eigenen Daten belegt hat. Am Ende steht ein Funktionsaufruf, den der Angreifer auf system() oder Ähnliches umlenken kann – Codeausführung mit den Rechten des PHP-Prozesses.

Ein bestätigter Angriffsweg führt über die Fortschrittsanzeige für Datei-Uploads der Session-Erweiterung (session.upload_progress). Der Angreifer schickt einen multipart/form-data-POST mit dem Feld PHP_SESSION_UPLOAD_PROGRESS vor einem Dateiteil und löst mit einem zweiten Request das Freigeben des Speichers aus. Weitere Pfade laufen über Backtraces bei fatalen Fehlern und eine Typverwechslung im OPcache. Eine der beiden Lücken gibt zusätzlich freigegebenen Worker-Speicher an den Client zurück – vergleichbar mit Heartbleed. Darin können Kennwörter, Session-Token, API-Schlüssel oder private Schlüssel aus fremden Requests stecken.

Wer ist betroffen?

PHP-Versionen

Der verwundbare Code stammt aus PHP 5.4.0 (2012). Betroffen ist damit alles ab PHP 5.4 – in der Standardkonfiguration, ohne exotische Einstellungen. Sowohl Apache mit mod_php als auch PHP-FPM sind angreifbar, mod_php gilt als besonders gefährdet.

Anwendungen und Plattformen

Laut Sansec haben die Entdecker die Codeausführung ohne Anmeldung unter anderem gegen aktuelle Versionen von WordPress, Drupal, Joomla, Magento, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony und WHMCS nachgewiesen. Das ist keine abschließende Liste – es sind Beispiele dafür, dass die Anwendung keine Rolle spielt. Nach Schätzungen aus der Sicherheitsforschung sind weltweit weit über eine Million aus dem Internet erreichbare Hosts potenziell verwundbar.

Typische Kandidaten, die man in Admin-Umgebungen leicht übersieht:

• WordPress- und Shop-Seiten bei Hostern (Shared Hosting, Managed WordPress)
• Webmailer (Roundcube) vor dem Exchange- oder Mailserver
• phpMyAdmin, Nextcloud, Ticketsysteme, Kundenportale, Zeiterfassung
• Hosting-Panels und Geräteoberflächen, die intern PHP nutzen
• PHP unter Windows/IIS per FastCGI, XAMPP- oder WAMP-Pakete auf „mal eben“ aufgesetzten Servern, mitgelieferte PHP-Laufzeiten in Fachanwendungen

Schritt 1: Eigenen Stand prüfen

Linux (Konsole)

php -v
php -i | grep -E "session.upload_progress.enabled|memory_limit"

# Paketstand der Distribution (Debian/Ubuntu bzw. RHEL-Familie)
dpkg -l | grep -E "^ii\s+php[0-9.]*-(fpm|cli|common)|libapache2-mod-php"
rpm -qa | grep -E "^php"

Wichtig: die Werte des Webservers prüfen, nicht der Konsole

PHP-FPM liest eigene Pool-Konfigurationen; die CLI zeigt unter Umständen eine ganz andere Version und andere Werte. In WordPress steht die tatsächlich verwendete Version unter Werkzeuge → Website-Zustand → Bericht → Server. Wer keinen Shell-Zugang hat, fragt beim Hoster nach – mit konkretem Verweis auf CVE-2026-109618 und CVE-2026-109619.

Windows / IIS (PowerShell)

Unter Windows liegt PHP häufig in verschiedenen Ordnern, manchmal mehrfach. Zuerst alle Installationen finden, dann jede einzeln prüfen:

# Alle PHP-Laufzeiten auf den lokalen Laufwerken finden
Get-PSDrive -PSProvider FileSystem | ForEach-Object {
    Get-ChildItem -Path $_.Root -Include php.exe, php-cgi.exe -Recurse -ErrorAction SilentlyContinue
} | Select-Object FullName, @{n='Version';e={$_.VersionInfo.ProductVersion}}

# Welche PHP-Laufzeit nutzt der IIS per FastCGI?
Import-Module WebAdministration
Get-WebConfiguration -Filter "system.webServer/fastCgi/application" | Select-Object fullPath, arguments

# Werte einer bestimmten Installation
& "C:\PHP\php.exe" -v
& "C:\PHP\php.exe" -i | Select-String "upload_progress.enabled|memory_limit"

Für Windows gibt es keine Paketverwaltung, die das erledigt: Den passenden Build (Thread Safe bzw. Non Thread Safe, x64) von windows.php.net beziehen, Versionsstand prüfen, den Ordner ersetzen, php.ini und Erweiterungen übernehmen und anschließend den Anwendungspool recyceln bzw. iisreset ausführen.

Schritt 2: Aktualisieren – die einzige echte Lösung

Das PHP-Team ist hier eindeutig: Nur das Update schließt die Lücken. Alle Einstellungen in der php.ini sind Notbehelfe.

• Eigene Server: PHP auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 bzw. auf den gepatchten Paketstand der Distribution heben, danach PHP-FPM und Webserver neu starten.
• RHEL-basierte Server mit Remi-Repository: Laut Sansec standen die Updates dort am 21.10. noch nicht bereit. Gegebenenfalls auf die PHP-Pakete der Distribution wechseln oder aus den Quellen bauen.
• Hosting-Kunden: Im Kundenmenü auf eine gepatchte Version umstellen oder den Hoster aktiv anfragen – nicht darauf warten, dass er von selbst aktualisiert.
• PHP 8.1 und älter: Kein offizieller Fix. Entweder Rückportierung über Distribution/LTS-Anbieter oder die Anwendung vom Internet nehmen und auf eine unterstützte Version migrieren. Das britische NCSC rät, nicht sofort patchbare Systeme notfalls offline zu nehmen.
• Container: Basis-Images neu ziehen und Images neu bauen – ein laufender Container aktualisiert sich nicht selbst.

Schritt 3: Überbrückung, wenn das Update nicht sofort geht

Die folgenden Maßnahmen kaufen Zeit, sie schützen nicht vollständig. Am besten kombinieren und nach dem Update wieder zurücknehmen.

a) multipart/form-data am Webserver abweisen

Alle bekannten Auslöser sind multipart/form-data-Requests, die PHP verarbeitet, bevor die Anwendung startet. Diese lassen sich vor PHP blocken – mit dem Preis, dass Uploads (Medienbibliothek, Formulare mit Anhang, manche Checkouts) nicht mehr funktionieren.

# Apache (je VirtualHost bzw. .htaccess, mod_rewrite erforderlich)
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

# nginx (je server-Block, der an PHP weiterreicht)
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Für den IIS lässt sich dasselbe mit dem URL Rewrite-Modul über eine Bedingung auf {HTTP_CONTENT_TYPE} und die Aktion „Anforderung abbrechen“ bzw. Statuscode 403 umsetzen.

b) PHP-Einstellungen

; php.ini (mod_php, CGI/FastCGI unter IIS)
session.upload_progress.enabled = 0
; nur PHP 8.5:
fatal_error_backtraces = 0

; PHP-FPM: in JEDEM Pool, z. B. /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off

Danach PHP-FPM neu laden (systemctl reload php8.3-fpm) bzw. Apache oder den IIS-Anwendungspool neu starten – und den Wert anschließend über einen echten Webrequest kontrollieren, nicht über die CLI. Auf Shared Hosting lässt sich session.upload_progress.enabled oft über eine .user.ini setzen.

c) WAF und Isolierung

• Cloudflare hat Regeln für die bekannten Angriffsmuster ausgerollt, auch im kostenlosen Tarif. Das wirkt nur für Datenverkehr, der tatsächlich über Cloudflare läuft, und ist ausdrücklich nur eine Übergangslösung.
• Wo vertretbar: nur GET und HEAD zulassen (Lesebetrieb) oder die Seite durch eine statische Wartungsseite am Webserver ersetzen und PHP-FPM stoppen.
• Interne Anwendungen (phpMyAdmin, Admin-Oberflächen) sofort per Firewall auf Admin-Netze bzw. VPN beschränken.

Schritt 4: Auf Angriffe prüfen

Weil die Ausnutzung vor dem Patch begann, reicht Aktualisieren allein nicht. Wer seit dem 20. Oktober ungepatcht im Netz stand, sollte nachsehen:

• Zugriffsprotokolle: POST-Requests mit multipart/form-data auf Pfade, die normalerweise keine Uploads empfangen; das Feld PHP_SESSION_UPLOAD_PROGRESS im Request-Body (falls Bodies mitgeschrieben werden). Achtung: Der Feldname ist konfigurierbar, und PHPs Multipart-Parser ist tolerant – einfache Mustersuchen lassen sich umgehen.
• Abstürze als Signal: Fehlgeschlagene Versuche bringen den PHP-Worker oft zum Absturz. Hinter nginx zeigt sich das als Häufung von 502-Fehlern, bei PHP-FPM als SIGSEGV im FPM-Log. Unter Windows lohnt der Blick ins Anwendungsprotokoll nach Ereignis 1000 mit php-cgi.exe als fehlerhafter Anwendung. Ein Status 200 auf dasselbe Muster ist der Erfolgsfall.
• Dateisystem: neue oder geänderte PHP-Dateien in wp-content/uploads, im Webroot oder in Cache-Verzeichnissen; unbekannte Admin-Konten in der Anwendung; neue Cronjobs bzw. geplante Aufgaben.
• Ausgehende Verbindungen des Webservers zu unbekannten Zielen.

# Linux: kürzlich geänderte PHP-Dateien im Webroot (seit 20.10.2026)
find /var/www -name "*.php" -newermt "2026-10-20" -ls

# PHP-Dateien im WordPress-Upload-Ordner gehören dort nicht hin
find /var/www -path "*wp-content/uploads*" -name "*.php" -ls

# Windows / IIS
Get-ChildItem C:\inetpub -Recurse -Include *.php -ErrorAction SilentlyContinue |
    Where-Object LastWriteTime -gt (Get-Date "2026-10-20") |
    Select-Object FullName, LastWriteTime

Geheimnisse wechseln

Da eine der Lücken Speicherinhalte anderer Requests an den Angreifer zurückgeben kann, sollte man bei ungepatchten, öffentlich erreichbaren Systemen nach dem Update davon ausgehen, dass Zugangsdaten abgeflossen sein könnten: Datenbankkennwörter, API-Schlüssel, SMTP-Zugänge, in WordPress die Salts und Schlüssel in der wp-config.php (macht alle Sitzungen ungültig) sowie Admin-Kennwörter. Bei Hinweisen auf eine Kompromittierung gilt: System aus sauberer Sicherung neu aufbauen, nicht „bereinigen“.

Compliance-Einordnung

• BSI IT-Grundschutz: OPS.1.1.3 Patch- und Änderungsmanagement (zeitnahes Einspielen sicherheitskritischer Updates), APP.3.1 Webanwendungen und Webservices, APP.3.2 Webserver. End-of-Life-PHP widerspricht der Anforderung, nur unterstützte Software einzusetzen.
• NIS2: Art. 21 Abs. 2 lit. e verlangt Maßnahmen zur Handhabung und Offenlegung von Schwachstellen. Wird eine erfolgreiche Ausnutzung festgestellt, greifen bei erheblichen Vorfällen die Meldefristen nach Art. 23 (Frühwarnung binnen 24 Stunden).
• DSGVO: Bei abgeflossenen personenbezogenen Daten Meldung an die Aufsichtsbehörde binnen 72 Stunden (Art. 33).
• CIS Controls: Control 7 (Continuous Vulnerability Management) und Control 2 (Software-Inventar) – ohne Inventar keine Antwort auf die Frage „Wo läuft bei uns überall PHP?“.

Checkliste

Fazit

PHP2Shell ist keine Lücke in „irgendeinem Plugin“, sondern im Fundament eines Großteils des Webs. Standardkonfigurationen sind verwundbar, Exploit-Werkzeuge sind öffentlich, Angriffe laufen bereits. Wer PHP betreibt – selbst oder beim Hoster –, sollte heute aktualisieren und nicht auf das nächste Wartungsfenster warten. Und wer seit Tagen ungepatcht im Netz stand, prüft nicht nur die Version, sondern auch, ob jemand schneller war.