PHP2Shell (CVE-2026-109618 und CVE-2026-109619): Was Administratoren jetzt wissen und tun müssen

Mit CVE-2026-109618 und CVE-2026-109619 – in Anlehnung an Log4Shell „PHP2Shell“ getauft – stecken zwei kritische Lücken direkt im PHP-Kern. Sie erlauben im ungünstigsten Fall das Ausführen von Schadcode ohne Anmeldung, noch bevor der Code der Anwendung überhaupt startet. Betroffen ist praktisch jede PHP-Installation, die Webanfragen beantwortet: WordPress, Nextcloud, Shopsysteme, Intranet-Anwendungen und Appliances mit PHP-Weboberfläche – unter Linux genauso wie unter Windows Server mit IIS. Dieser Beitrag bündelt den Kenntnisstand vom 26.10.2026: was genau passiert, wer betroffen ist, wie Sie patchen, was bis dahin hilft und woran Sie einen Angriff erkennen.

Was ist passiert? Die Zeitachse

Die Lücken verständlich erklärt

Beide Lücken haben dieselbe Wurzel: PHP bricht eine Anfrage bei bestimmten Fehlern hart ab (intern über longjmp()) und räumt danach Speicher auf. Wird dieser Abbruch im falschen Moment ausgelöst, ist der interne Zustand nicht mehr konsistent – und genau das nutzt der Angreifer aus.

Laut Akamai nutzt ein typischer Angriff einen multipart/form-data-POST mit einem Feld PHP_SESSION_UPLOAD_PROGRESS, einem Sitzungs-Cookie und Datei-Feldern, dazu zahlreiche weitere Formularfelder zum Vorbereiten des Speichers. Wichtig: Es reicht ein beliebiger PHP-Endpunkt – auch eine Seite, die gar keine Uploads verarbeitet, denn PHP wertet die Anfrage aus, bevor der Anwendungscode läuft.

Die dritte Lücke: CVE-2026-115560

Am 23.10. kam eine weitere RCE-Lücke im Zusammenhang mit dem Upload-Fortschritt hinzu. Nach Angabe der PHP-Entwickler ist sie nur bei einer ungewöhnlichen Kombination ausnutzbar: session.serialize_handler ist in der Konfiguration auf php_binary oder php_serialize gesetzt und wird zur Laufzeit per ini_set() vor session_start() auf php umgestellt. Es gibt dafür kein Sonderrelease; der Fix folgt im nächsten regulären Release. Bis dahin hilft session.upload_progress.enabled=0.

Wer ist betroffen?

PHP-Versionen

Betriebsarten

Betroffen sind alle Server-APIs, die Webanfragen bedienen: Apache mit mod_php, PHP-FPM (nginx, Apache mit proxy_fcgi), php-cgi – und damit auch IIS mit FastCGI –, LiteSpeed und FrankenPHP. Das höchste Risiko sieht das PHP-Team bei mod_php, weil dort ein Angriff demonstriert wurde, der mit einer einzigen nicht authentifizierten Anfrage auskommt.

Versteckte PHP-Installationen

• Webhosting: Bei Shared Hosting patcht der Anbieter. Prüfen Sie dennoch die tatsächlich verwendete Version (siehe unten) und ob Sie die PHP-Version im Kundenmenü selbst gewählt haben.
• Appliances und Netzwerkkomponenten: NAS-Systeme, Firewalls, Monitoring- und Verwaltungsoberflächen bringen oft ein eigenes PHP mit. Das BSI weist ausdrücklich darauf hin, dass zunehmend Hersteller von Netzwerkkomponenten Advisories veröffentlichen. Das NCSC-NL pflegt auf GitHub eine Liste betroffener Produkte.
• Windows-Server: Herstellertools und Branchensoftware mit eigener php-cgi.exe, alte XAMPP-, WAMP- oder Laragon-Installationen.
• Container: Docker-Images enthalten ihr eigenes PHP. Ein Update des Hosts hilft nicht – Images müssen neu gebaut und Container neu gestartet werden.

Schritt 1: Betroffene Systeme finden

Priorisieren Sie nach Erreichbarkeit: erst alles, was aus dem Internet erreichbar ist, dann interne Anwendungen, dann Test- und Entwicklungssysteme.

Windows Server und IIS

# Welche php-cgi.exe nutzt IIS tatsächlich?
& "$env:windir\system32\inetsrv\appcmd.exe" list config /section:system.webServer/fastCgi

# Version jeder registrierten PHP-Installation auslesen und bewerten
Import-Module WebAdministration
$fix = @{ '8.5' = [version]'8.5.12'; '8.4' = [version]'8.4.27'; '8.3' = [version]'8.3.36'; '8.2' = [version]'8.2.35' }
Get-WebConfiguration -Filter 'system.webServer/fastCgi/application' | ForEach-Object {
    $exe = $_.fullPath
    $ver = [version]((Get-Item $exe).VersionInfo.ProductVersion -replace '[^0-9.].*$')
    $zweig = '{0}.{1}' -f $ver.Major, $ver.Minor
    $status = if (-not $fix.ContainsKey($zweig)) { 'KEIN UPDATE VERFÜGBAR (EOL)' }
              elseif ($ver -ge $fix[$zweig]) { 'gepatcht' } else { 'VERWUNDBAR' }
    [pscustomobject]@{ Pfad = $exe; Version = $ver; Status = $status }
}

Für die Suche nach PHP auf allen Servern im Netz eignet sich das Inventarskript aus unserem Beitrag zum Supportende von PHP 8.2 – es sucht per WinRM nach php.exe und php-cgi.exe und liest die Version aus.

Linux

php -v                                   # CLI – nicht zwingend die Web-Version!
ls /etc/php/ 2>/dev/null                 # Debian/Ubuntu: installierte Zweige
systemctl list-units 'php*-fpm*'         # laufende FPM-Dienste
apachectl -M 2>/dev/null | grep -i php   # mod_php aktiv?

# Distributionspakete: maßgeblich ist der Changelog bzw. das Advisory der Distribution
apt changelog php8.2-fpm 2>/dev/null | grep -m3 -i -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm 2>/dev/null   | grep -m3 -i -E 'CVE-2026-10961[89]'

Welche Version nutzt die Website wirklich?

Die Kommandozeilen-Version kann von der Version abweichen, mit der der Webserver arbeitet. Sicher ist nur die Anzeige der Web-Umgebung: In WordPress unter Werkzeuge → Website-Zustand → Bericht → Server, sonst über eine kurzzeitig abgelegte phpinfo()-Seite (Zugriff nur intern, danach sofort löschen) mit Blick auf „PHP Version“ und „Server API“.

Schritt 2: Patchen

Windows Server mit IIS

1. Von windows.php.net den x64 Non Thread Safe (NTS)-Build des eigenen Zweigs laden (8.5.12 bzw. 8.4.27 mit VS17; 8.3.36 bzw. 8.2.35 mit VS16) und die SHA256-Prüfsumme vergleichen.
2. IIS stoppen: net stop w3svc (alternativ nur den betroffenen Anwendungspool).
3. Bestehenden PHP-Ordner sichern, z. B. C:\PHP\8.4 nach C:\PHP\8.4_alt umbenennen.
4. Neuen Build in denselben Pfad entpacken – dann bleiben FastCGI-Eintrag und Handler unverändert. php.ini aus der Sicherung zurückkopieren. Zusätzliche Erweiterungen (z. B. sqlsrv) nur in der zur Version passenden Fassung verwenden.
5. IIS starten: net start w3svc.
6. Prüfen, dass keine php-cgi.exe mit altem Stand mehr läuft und die Web-Umgebung die neue Version meldet.
7. Die Sicherung erst nach einigen Tagen Betrieb löschen.

# Laufen noch PHP-Prozesse mit altem Binary?
Get-Process php-cgi -ErrorAction SilentlyContinue |
    Select-Object Id, Path, @{n='Version';e={$_.MainModule.FileVersionInfo.ProductVersion}}, StartTime

# Laufende IIS-Worker-Prozesse
& "$env:windir\system32\inetsrv\appcmd.exe" list wps

Linux

# Debian/Ubuntu
apt update && apt install --only-upgrade 'php*'
systemctl restart php8.4-fpm            # alle FPM-Dienste neu starten
systemctl restart apache2               # bei mod_php zwingend

# RHEL/Rocky/Alma
dnf upgrade 'php*' && systemctl restart php-fpm httpd

# Container: Images neu bauen, nicht nur neu starten
docker compose build --pull && docker compose up -d

PHP 8.1 und älter

Für End-of-Life-Versionen gibt es keine offiziellen Releases. Die Möglichkeiten in absteigender Reihenfolge: auf einen unterstützten Zweig aktualisieren; ein Paket der Distribution oder eines kommerziellen LTS-Anbieters mit Backport einsetzen; die vom PHP-Team bereitgestellten Quellcode-Backports selbst kompilieren. Ist nichts davon kurzfristig möglich, nehmen Sie das System vom Internet und setzen Sie die Sofortmaßnahmen um.

Schritt 3: Sofortmaßnahmen, bis gepatcht ist

Die folgenden Maßnahmen stammen aus dem PHP-Advisory und den Empfehlungen von CERT-EU. Sie verringern die Angriffsfläche, beseitigen die Lücken aber nicht.

Sofortmaßnahmen unter IIS

Unter IIS gelten die Werte zentral in der php.ini, auf die PHPRC der FastCGI-Anwendung zeigt. Für das Beenden der Prozesse nach jeder Anfrage gibt es kein pm.max_requests; die Entsprechung sind instanceMaxRequests in der FastCGI-Konfiguration und die Umgebungsvariable PHP_FCGI_MAX_REQUESTS. Die folgende Notfallkonfiguration ist unsere Übertragung der FPM-Empfehlung auf IIS – sie kostet spürbar Leistung und sollte nach dem Patch wieder zurückgenommen werden:

# php.ini (Pfad aus PHPRC) – Notfallwerte
#   session.upload_progress.enabled = 0
#   post_max_size = 32M
#   upload_max_filesize = 30M
#   fatal_error_backtraces = 0        ; nur PHP 8.5

Import-Module WebAdministration
$php = 'C:\PHP\8.4\php-cgi.exe'
# Jeder php-cgi-Prozess bedient nur noch eine Anfrage (Notbetrieb!)
Set-WebConfigurationProperty -Filter "system.webServer/fastCgi/application[@fullPath='$php']" `
    -Name instanceMaxRequests -Value 1
Set-WebConfigurationProperty -Filter "system.webServer/fastCgi/application[@fullPath='$php']/environmentVariables/environmentVariable[@name='PHP_FCGI_MAX_REQUESTS']" `
    -Name value -Value '1'

# Request-Größe vor PHP begrenzen (Bytes) – passend zu post_max_size
Set-WebConfigurationProperty -PSPath 'IIS:\' -Filter 'system.webServer/security/requestFiltering/requestLimits' `
    -Name maxAllowedContentLength -Value 33554432

net stop w3svc; net start w3svc

Schritt 4: Angriffe erkennen

Bestätigte Indikatoren (IoCs) für erfolgreiche PHP2Shell-Angriffe gibt es zum Stand dieses Beitrags nicht. Die Lage ist uneinheitlich: watchTowr beobachtet seit dem 21.10. Angriffe auf Honeypots, Cloudflare meldet Angriffsverkehr, CrowdStrike sah bis zum 23.10. nur Tests und erfolglose Versuche, und das BSI kannte am 22.10. keine erfolgreiche Ausnutzung in der Breite. CrowdStrike weist zudem darauf hin, dass viele öffentliche Exploits nur Abstürze erzeugen und für zuverlässige Codeausführung an Version und Build angepasst werden müssen.

Unabhängig von der Lücke erkennen Sie eine erfolgreiche Übernahme an den Folgen. Darauf sollten Sie achten:

Windows: Hat PHP Prozesse gestartet?

# Voraussetzung: Überwachung "Prozesserstellung" aktiv (Ereignis 4688), idealerweise mit Befehlszeile
$start = Get-Date '2026-10-20'
Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4688; StartTime = $start } -ErrorAction SilentlyContinue |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        $d = @{}; $x.Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
        if ($d.ParentProcessName -match '\\php(-cgi)?\.exe$') {
            [pscustomobject]@{
                Zeit     = $_.TimeCreated
                Eltern   = $d.ParentProcessName
                Prozess  = $d.NewProcessName
                Befehl   = $d.CommandLine
                Benutzer = $d.SubjectUserName
            }
        }
    } | Format-Table -AutoSize -Wrap

# Neue oder geänderte PHP-Dateien im Webverzeichnis seit dem 20.10.
Get-ChildItem -Path D:\Web, C:\inetpub -Recurse -Include *.php, *.phtml, *.phar -File -ErrorAction SilentlyContinue |
    Where-Object { $_.LastWriteTime -ge $start -or $_.CreationTime -ge $start } |
    Select-Object FullName, CreationTime, LastWriteTime, Length | Sort-Object LastWriteTime -Descending

Linux

# Neue/geänderte PHP-Dateien seit dem 20.10.
find /var/www -type f \( -name '*.php' -o -name '*.phtml' -o -name '*.phar' \) -newermt '2026-10-20' -ls

# Abstürze und Speicherfehler
journalctl -u 'php*-fpm*' --since '2026-10-20' | grep -E -i 'SIGSEGV|signal 11|exited on signal'
grep -h -i 'Allowed memory size' /var/log/php*/*.log /var/log/apache2/error.log 2>/dev/null | wc -l

# Prozesse unterhalb von PHP-Workern
ps -eo pid,ppid,user,cmd --forest | grep -B1 -A3 -E 'php-fpm|apache2|httpd' | grep -E 'sh -c|bash|curl|wget|nc '

Was Sie nach dem Patch tun sollten

• Geheimnisse rotieren, wenn ein System vor dem Patch aus dem Internet erreichbar war und die Protokolle Auffälligkeiten zeigen. CVE-2026-109619 erlaubt laut Qualys das Auslesen von Speicherinhalten des Workers.
• Notfallwerte zurücknehmen: memory_limit = -1 und instanceMaxRequests = 1 bzw. pm.max_requests = 1 sind keine Dauerlösung. session.upload_progress.enabled = 0 können Sie beibehalten, wenn Ihre Anwendungen keine Upload-Fortschrittsanzeige nutzen – bis zum nächsten regulären Release ist das wegen CVE-2026-115560 ohnehin empfohlen.
• PHP-Bestand bereinigen: Alte Installationen, Testumgebungen und vergessene XAMPP-Ordner entfernen.
• PHP 8.2 ersetzen: Der Zweig endet am 31.12.2026. Wer jetzt ohnehin anfasst, plant gleich den Umstieg auf 8.4.
• Nächstes Release verfolgen: Der Fix für CVE-2026-115560 und mögliche weitere Korrekturen kommen mit dem nächsten regulären Release.
• Härtung umsetzen: Minimal berechtigte Anwendungspools bzw. FPM-Benutzer, kein Schreibrecht im Webverzeichnis, keine Skriptausführung in Upload-Ordnern, Begrenzung der Anfragegröße vor PHP. Die RCE läuft mit den Rechten des Workers – je weniger dieser darf, desto kleiner der Schaden.

Fallstricke aus der Praxis

Compliance-Bezug

• NIS2 / BSIG: Für besonders wichtige und wichtige Einrichtungen ist eine erhebliche Kompromittierung meldepflichtig (Frühwarnung innerhalb von 24 Stunden). Dokumentieren Sie Prüfung, Patchzeitpunkt und Ergebnis der Suche nach Kompromittierungsspuren. Art. 21 Abs. 2 der NIS2-Richtlinie fordert ausdrücklich den Umgang mit Schwachstellen.
• DSGVO: Werden personenbezogene Daten abgegriffen, kann eine Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden erforderlich sein (Art. 33).
• BSI IT-Grundschutz: OPS.1.1.3 Patch- und Änderungsmanagement, APP.3.2 Webserver, APP.3.1 Webanwendungen, DER.2.1 Behandlung von Sicherheitsvorfällen.
• CIS Controls v8: Control 7 (Continuous Vulnerability Management) und Safeguard 7.7 (Remediate Detected Vulnerabilities).

Fazit

PHP2Shell ist ernst – aber beherrschbar. Die Lücken sitzen im PHP-Kern, betreffen jede Betriebsart und sind ab Werk angreifbar. Gleichzeitig ist die zuverlässige Ausnutzung nach heutigem Stand anspruchsvoll, und die Korrekturen liegen seit dem 21.10. vor. Die Reihenfolge ist klar: alle PHP-Installationen finden, auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren, sämtliche Prozesse neu starten, bis dahin Upload-Fortschritt abschalten und Anfragen begrenzen – und nach Spuren suchen, wenn ein System vor dem Patch erreichbar war. Wer noch PHP 8.1 oder älter betreibt, hat spätestens jetzt keinen Grund mehr, den Umstieg aufzuschieben.

Quellen: php.net – Sicherheitsrelease und Hinweise · CERT-EU Advisory 2026-018 · BSI-Cybersicherheitswarnung · watchTowr – PHP2Shell FAQ · Qualys · CrowdStrike · Unit 42 · Huntress · Akamai