ByteRay GmbH
Hopfenstraße 8
80335 München
z
z
z
z
i
i
z
z
Wir durchleuchten digitale
Risiken.
Sprechen Sie direkt mit einem Security-Engineer: unverbindlich, technisch, konkret.
Lieber gleich einen Termin?
Erstgespräch buchen
PHP2Shell: Zwei kritische Lücken im PHP-Kern erlauben unauthentifizierte Codeausführung auf nahezu jedem Webserver. Patches seit 21.10.2026, Exploit öffentlich.
Unsere DFIR-Bereitschaft ist rund um die Uhr erreichbar — auch ohne bestehenden Vertrag.
+49 89 2000 7683Betroffen ist jede PHP-Installation, die Webanfragen verarbeitet, unabhängig vom SAPI: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Team stuft das Risiko bei mod_php am höchsten ein, weil dort ein unauthentifizierter Request den Angriff auslösen kann, bevor überhaupt Anwendungscode läuft. Welche Anwendung auf PHP läuft, spielt keine Rolle. Ein ungepatchter Server mit statischer Firmenwebsite ist genauso angreifbar wie ein Shop.
Nicht betroffen sind reine CLI-Nutzungen ohne Web-Erreichbarkeit (Cron-Jobs, Build-Server) und Systeme ohne PHP. Die Lücke liegt im Request-Handling.
| PHP-Zweig | Status | Betroffen | Behobene Version |
|---|---|---|---|
| 8.5 | Aktiver Support | < 8.5.12 | 8.5.12 |
| 8.4 | Aktiver Support | < 8.4.27 | 8.4.27 |
| 8.3 | Aktiver Support | < 8.3.36 | 8.3.36 |
| 8.2 | Nur Sicherheitsupdates, EOL 31.12.2026 | < 8.2.35 | 8.2.35 |
| 8.1, 8.0, 7.4 | End of Life | alle | Kein offizielles Release. Minimale Source-Backports des PHP-Teams auf GitHub, Distributions-Backports (Debian, Ubuntu, RHEL/SUSE) laufen an. |
| 7.3 und älter, 5.x | End of Life | alle | Kein Patch. Nur Migration oder Abschaltung. |
Drei Hinweise aus der Praxis: Erstens laufen Linux-Distributionen eigene Versionsnummern. Ubuntu 24.04 liefert weiterhin „8.3.6“, die Behebung steht nur im Paket-Changelog. Zweitens hat das volunteer-betriebene Repository rpms.remirepo.net am Patchtag keine Updates. Drittens ist PHP 8.2 in neun Wochen End of Life, das Update auf 8.2.35 kauft nur Zeit bis Jahresende.
Die Versionsprüfung muss den Web-SAPI treffen, nicht nur das CLI. php -v allein reicht nicht, wenn FPM oder mod_php eine andere Version laden.
# Alle installierten PHP-Pakete (Debian/Ubuntu bzw. RHEL/SUSE)
dpkg -l 'php*' | grep '^ii'
rpm -qa 'php*'
# Welcher Web-SAPI läuft tatsächlich?
ps -eo comm,args | grep -E 'php-fpm|lsphp|php-cgi|frankenphp'
apache2ctl -M 2>/dev/null | grep -i php # mod_php?
# Version des laufenden FPM-Workers
php-fpm8.3 -v # Binary-Name je nach Distribution anpassen
# Bei Distributions-Backports: steht die CVE im Changelog?
apt changelog php8.3-fpm 2>/dev/null | grep -E 'CVE-2026-10961[89]'
rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]'Für Falcon-Betreiber liefert Spotlight die Betroffenheit ohne eigenen Scan, sobald der Content aktualisiert ist:
cve.id:['CVE-2026-109618','CVE-2026-109619']Wer die Inventarisierung über NG-SIEM fahren will, findet im Abschnitt Erkennung & IOCs unsere Scoping-Query, die jeden Linux-Host mit PHP-Interpreter auflistet.
Beide Schwachstellen sitzen nicht in einer Erweiterung, sondern im Request-Lebenszyklus der PHP-Engine selbst. Nach Angaben der Entdecker waren die zugrunde liegenden Fehler seit Jahrzehnten im Code. Dass sie ausnutzbar sind, musste erst über eine sehr lange Kette von Schritten nachgewiesen werden. 2026 ist das drei Parteien unabhängig voneinander gelungen.
Wenn PHP während der Verarbeitung eines Requests das memory_limit erreicht, bricht die Engine mitten in der Arbeit ab. Interne Datenstrukturen des Requests sind dann nur teilweise initialisiert. Beim anschließenden Aufräumen behandelt PHP diese ungültigen Daten als gültig. Ein Angreifer, der den Speicherverbrauch über die Request-Größe steuert (Multipart-Uploads, viele Formularfelder, verschachtelte Strukturen), steuert damit auch, wo der Abbruch passiert. Nach vorliegenden Analysen lässt sich der Fehler außerdem zum Auslesen von Arbeitsspeicher nutzen, ähnlich wie bei Heartbleed: Zugangsdaten, Session-Tokens und Konfigurationswerte anderer Requests desselben Workers können abfließen, auch ohne Codeausführung. Verwundbar ist unter anderem der Session-Upload-Progress-Mechanismus, der zwei Zeiger in Hash-Tabellen zwischenspeichert.
Request-eigener interner Zustand überlebt, nachdem der dahinterliegende Speicher bereits freigegeben wurde. Verarbeitet derselbe Worker den nächsten Request, greift PHP auf diesen veralteten Zustand zu, bevor die reguläre Initialisierung ihn zurücksetzt. Bestätigte Pfade sind die Session-Fortschrittsmeldung bei Uploads (session.upload_progress, standardmäßig aktiv) und auf PHP 8.5 die Backtrace-Erzeugung bei Fatal Errors, gekoppelt mit einer Typverwechslung im OPcache. Jeder vom Angreifer auslösbare Fatal Error oder Timeout ist ein möglicher Einstieg.
Ein öffentlich kursierendes Exploit-Tool, nach dem die Lücke benannt ist, verkettet beide Fehler zu einem einzigen Angriff ohne Authentifizierung. Sansec hat damit nach eigenen Angaben Codeausführung gegen Magento 2.4.9 und zehn weitere PHP-Anwendungen bestätigt. Das Ergebnis ist Befehlsausführung mit den Rechten des PHP-Prozesses, in der Praxis also www-data mit Schreibzugriff auf das Web-Root.
Das ist kein Produktproblem, das ist ein Inventarproblem. Bei Log4Shell musste man wissen, wo Java-Bibliotheken liegen. Hier muss man wissen, wo überall PHP Webanfragen entgegennimmt. In den Umgebungen, die wir betreuen, ist das deutlich mehr, als die Asset-Liste hergibt: die Marketing-Website beim Agentur-Hoster, das Intranet-Wiki aus 2017, das Monitoring-Frontend, das Ticket-System, die Appliance mit eingebettetem PHP, deren Hersteller selbst noch keinen Patch hat. Die Firmenwebsite ist dabei meist das geringste Problem, weil sie extern betrieben wird. Das interne Zeug ist das Problem.
End-of-Life ist diesmal nicht abstrakt. PHP 7.4 und 8.1 laufen im deutschen Mittelstand in großer Zahl, weil Anwendungen darauf festgenagelt sind. Dafür gibt es ab heute offiziell kein Release, nur Source-Backports und das, was die Distributionen liefern. Wer auf einer EOL-Version hängt, hat jetzt drei Optionen: Distributions-Backport prüfen, selbst bauen oder das System hinter ein VPN nehmen, bis die Migration steht. Ignorieren ist keine.
Der Patch beendet den Angriff, nicht den Vorfall. Die Details waren rund 20 Stunden vor dem Release öffentlich, Exploit-Tooling inklusive. Wer ein exponiertes System in diesem Fenster betrieben hat, muss nach dem Patch nach Webshells suchen. Zusätzlich kann CVE-2026-109618 Speicherinhalte preisgeben. Auf einem Shared-Hosting-Worker liegen darin die Sessions und Zugangsdaten anderer Mandanten. Wer Secrets in PHP-Konfigurationen hält, sollte Rotation einplanen, nicht nur Patching.
Zu den Workarounds. Das PHP-Team nennt explizit, dass die Gegenmaßnahmen einzelne Angriffspfade schließen und eine Installation nicht sicher machen. Das BSI geht weiter und spricht von keinen zuverlässigen Workarounds. Wir halten beides für richtig: session.upload_progress.enabled=0 und memory_limit=-1 senken die Angriffsfläche messbar und sind in Minuten gesetzt. Sie sind eine Brücke bis zum Patch, kein Ersatz. Eine WAF-Regel auf das Feld PHP_SESSION_UPLOAD_PROGRESS fängt nur den bekannten Pfad und nur Angreifer, die den öffentlichen PoC unverändert nutzen.
Zum Zeitpunkt. Das Timing zwischen Leak, Patch und Massenscan ist bei Log4Shell und MOVEit dasselbe gewesen: Die Opportunisten brauchen Stunden, die Ransomware-Gruppen Tage. Die nächsten 72 Stunden entscheiden, ob aus einem Patch-Thema ein Incident-Thema wird.
session.upload_progress.enabled=0 und memory_limit=-1 per php_admin_value im FPM-Pool oder in der Apache-Konfiguration setzen, auf 8.5 zusätzlich fatal_error_backtraces=0. Nicht über ini_set() oder .user.ini, das greift zu spät. post_max_size klein halten (8M ohne Uploads, 32M mit). Alle Worker neu starten. Kein RLIMIT_AS oder RLIMIT_DATA als Ersatz, das löst den verwundbaren Pfad selbst aus.PHP_SESSION_UPLOAD_PROGRESS, ungewöhnlich große oder tief verschachtelte Requests, 5xx-Spitzen. PHP-FPM-Logs auf gehäufte Allowed memory size exhausted und child exited on signal 11.wp-config.php, .env, LocalConfiguration.php, API-Keys, Session-Secrets. Bei Shared Hosting: auch die anderen Mandanten betrachten.Ein Exploit gegen die PHP-Engine hinterlässt auf dem Endpunkt kaum eigene Spuren. Was Spuren hinterlässt, ist das, was danach kommt: ein PHP-Worker, der eine PHP-Datei schreibt oder eine Shell startet. Genau dort setzen wir an. Beide Queries unten sind im ByteRay CQL Hub veröffentlicht und laufen in Falcon NG-SIEM (Modul Insight, Linux-Sensor).
Liefert pro Linux-Host und PHP-Binary die Anzahl der Ausführungen und den letzten Zeitpunkt. Das ist die Arbeitsliste für das Patching. Zur Query im CQL Hub
#event_simpleName=ProcessRollup2 event_platform=Lin
| FileName=/^(php(-fpm|-cgi)?[0-9.]*|lsphp[0-9.]*)$/i // add other PHP SAPIs used in your environment
| groupBy([aid, ImageFileName], function=[count(as=Executions), max(@timestamp, as=LastSeen)], limit=max)
| match(file="aid_master_main.csv", field=aid, include=[ComputerName], strict=false)
| LastSeen := formatTime("%Y-%m-%d %H:%M:%S", field=LastSeen)
| table([ComputerName, aid, ImageFileName, Executions, LastSeen], limit=20000)Hinweise: Der Pfad verrät den Zweig (php-fpm8.2, /opt/remi/php83/), nie den Patchstand. Build-Hosts mit reinem CLI tauchen ebenfalls auf. mod_php läuft innerhalb von httpd/apache2 und wird hier nicht erfasst, dafür vom Selbstcheck oben.
cve.id:['CVE-2026-109618','CVE-2026-109619']Ergebnis gegen die Scoping-Liste legen. Hosts, die in der Query auftauchen, aber nicht in Spotlight, haben entweder keinen Sensor-Vulnerability-Scan oder eine Distribution, deren Backport-Versionsnummer noch nicht im Content ist. Beides manuell nachziehen.
Die aussagekräftigste Suche. Nach Codeausführung ist das Schreiben einer neuen PHP-Datei ins Web-Root der übliche Weg, den Zugang zu behalten. Zur Query im CQL Hub
in(#event_simpleName, values=["NewScriptWritten", "WebScriptFileWritten"])
| event_platform=Lin
| ContextBaseFileName=/^(php(-fpm|-cgi)?[0-9.]*|lsphp[0-9.]*|httpd|apache2)$/i
| TargetFileName=/\.(php[0-9]?|phtml|phar|inc)$/i
// exclude known update/cache paths here, e.g. | TargetFileName!=/\/wp-content\/cache\//i
| groupBy([aid, ContextBaseFileName, TargetFileName, SHA256HashData], function=[count(as=Writes), min(@timestamp, as=FirstSeen), max(@timestamp, as=LastSeen)], limit=max)
| match(file="aid_master_main.csv", field=aid, include=[ComputerName], strict=false)
| FirstSeen := formatTime("%Y-%m-%d %H:%M:%S", field=FirstSeen)
| LastSeen := formatTime("%Y-%m-%d %H:%M:%S", field=LastSeen)
| table([ComputerName, aid, ContextBaseFileName, TargetFileName, SHA256HashData, Writes, FirstSeen, LastSeen], limit=20000)Tuning: CMS- und Plugin-Updates, Template-Caches (Twig, Smarty, Blade) und Composer-Läufe aus dem Web-Prozess schreiben legitim PHP-Dateien. Matomo legt nach jedem Upgrade leere index.php-Stubs in Cache-Ordner. Diese Pfade über die auskommentierte Zeile ausschließen. SHA256HashData war in unseren Tests durchgängig 0, nicht als Allowlist-Kriterium verwenden.
Eine ausgeführte Webshell zeigt sich daran, dass der PHP- oder Apache-Prozess eine Shell oder Aufklärungsbefehle startet. Im Normalbetrieb ist das bei den meisten Anwendungen die Ausnahme, bei einigen (Backup-Plugins, Image-Konvertierung) die Regel. Deshalb hier als Ausgangspunkt, nicht als Alarmregel:
#event_simpleName=ProcessRollup2 event_platform=Lin
| ParentBaseFileName=/^(php(-fpm|-cgi)?[0-9.]*|lsphp[0-9.]*|httpd|apache2)$/i
| FileName=/^(sh|bash|dash|whoami|id|uname|curl|wget|nc|ncat|python3?|perl)$/i
| groupBy([ComputerName, ParentBaseFileName, FileName, CommandLine], limit=max)Ohne Sensor bleiben die Logs. Suchmuster: Multipart-POSTs mit dem Formularfeld PHP_SESSION_UPLOAD_PROGRESS, gehäufte Requests an beliebige PHP-Endpunkte mit ungewöhnlicher Content-Length, in den FPM-Logs Allowed memory size of ... exhausted und child ... exited on signal 11 (SIGSEGV) in zeitlicher Nähe. Einzelne Treffer sind Rauschen, Serien aus derselben Quelle sind ein Befund.
Die Queries oben stammen von uns, sind in echten Umgebungen gelaufen und stehen im CQL Hub frei zur Verfügung, inklusive YAML für das eigene Regelwerk.
Wer Falcon selbst betreibt, kann das eins zu eins übernehmen. Wer einen Verdacht hat oder die Inventarisierung nicht allein stemmt, erreicht uns rund um die Uhr.
Gezielte Prüfung Ihrer PHP-Systeme auf Webshells, Persistenz und Hinweise auf abgeflossene Zugangsdaten, mit Fokus auf das Zeitfenster seit dem 20.10.2026. Ergebnis ist eine klare Aussage zur Betroffenheit und eine Liste der Secrets, die rotiert werden müssen. Umfang und Dauer legen wir im Kick-off fest.
Bei gefundener Webshell, verdächtigen Prozessen oder einem Hoster, der nicht antwortet: +49 89 2000 7683. Rund um die Uhr, auch ohne bestehenden Vertrag.
Sie setzen CrowdStrike Falcon ein, aber nicht mit uns? Wir fahren Scoping-Query und Spotlight-Abgleich gegen Ihren Bestand, liefern eine belastbare Patch-Liste und binden die Webshell-Erkennung als gepflegte Regel in Ihr NG-SIEM ein.
Ja, sofern das darunterliegende PHP nicht gepatcht ist. Die Schwachstellen liegen in der PHP-Engine, nicht in der Anwendung. Ein Update von WordPress oder eines Plugins ändert nichts. Entscheidend ist die PHP-Version auf dem Server beziehungsweise beim Hoster.
Für die Lücke selbst ja, wenn alle Worker neu gestartet wurden. Offen bleibt die Frage, ob zwischen dem Leak am 20.10. und dem Patch eine Webshell abgelegt oder Speicher ausgelesen wurde. Lassen Sie sich Patchzeitpunkt und Neustart bestätigen und prüfen Sie das Web-Root auf neue PHP-Dateien.
Offizielle Releases gibt es dafür nicht mehr. Das PHP-Team stellt minimale Source-Backports auf GitHub bereit, Debian, Ubuntu, Red Hat und SUSE liefern Backports über ihre Paketquellen. Prüfen Sie, ob Ihr Paket die CVE im Changelog führt. Wenn kein Backport erreichbar ist: System vom Internet trennen, Workarounds setzen und die Migration terminieren.
Nein. Das PHP-Team schreibt ausdrücklich, dass es keine vollständigen Gegenmaßnahmen gibt. session.upload_progress.enabled=0 und memory_limit=-1 schließen die bekannten Pfade und sind als Brücke sinnvoll, mehr nicht.
Ein Exploit-Tool und Proof-of-Concepts sind seit dem 20.10.2026 öffentlich, Sansec hat Codeausführung gegen gängige Anwendungen bestätigt, Cloudflare und watchTowr melden erste Angriffsversuche. Das BSI führte die Ausnutzung am Vormittag des 21.10. noch als unbestätigt. Wir behandeln sie als gegeben: Bei einer unauthentifizierten RCE in dieser Verbreitung mit öffentlichem Tooling ist Massenscanning eine Frage von Stunden.
Ja. PHP unter IIS (php-cgi über FastCGI) oder Apache für Windows ist genauso betroffen. Windows-Binaries der gepatchten Versionen liegen auf php.net. Unsere beiden NG-SIEM-Queries sind auf Linux-Telemetrie zugeschnitten, das Muster (PHP-Prozess schreibt PHP-Datei) lässt sich für Windows mit event_platform=Win und php-cgi.exe nachbauen.
Wenn ein exponiertes System ungepatcht lief, während der Exploit öffentlich war: ja. CVE-2026-109618 kann Arbeitsspeicher des Workers preisgeben, darin liegen Datenbank-Passwörter und Sessions. Rotation kostet eine Stunde, der Alternativfall kostet mehr.
