CVE-2026-109618 & CVE-2026-109619: PHP2Shell - unauthentifizierte RCE in PHP (CVSS 9.2)

Diese Woche in unserer Serie InSEKurity of the Week: kein Bug in einem Produkt, das auf PHP läuft, sondern ein Bug in PHP selbst. Am 21. Oktober 2026 hat das PHP-Projekt die Notfall-Releases 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, um zwei kritische Schwachstellen zu schließen: CVE-2026-109618 und CVE-2026-109619, die Forscher zu einem Exploit namens PHP2Shell verkettet haben. Beide werden mit CVSS 4.0 9.2 bewertet, beide sind ohne Authentifizierung erreichbar, und das PHP-Security-Team fasst das Ergebnis in einem Satz zusammen: unauthentifizierte Remote Code Execution mit den Rechten des Web-Workers.

Was diesen Fall vom üblichen „kritische RCE in einer Web-Anwendung” unterscheidet, ist der Ort des Bugs. Beide Schwachstellen liegen im Request-Lebenszyklus des Interpreters — darin, wie PHP mit Speichermangel umgeht, und darin, welchen Zustand ein Worker von einem Request in den nächsten mitnimmt. Auf Apache mit mod_php hat PHP einen Exploit-Pfad bestätigt, bei dem der bösartige Request seine Arbeit erledigt, bevor irgendein Anwendungscode läuft. Ihre Login-Seite, der CSRF-Check Ihres Frameworks und Ihre sorgfältig reviewten Controller werden nie gefragt. Wenn der Server den Request parst, ist der Server betroffen.

Und die Veröffentlichung lief nicht nach Plan. Die CVE-IDs wurden am 20. Oktober geleakt, PHP zog das Release um einen Tag vor, Cloudflare hatte WAF-Regeln Stunden vor dem Patch live, und Honeypot-Betreiber meldeten Exploit-Versuche, bevor die gefixten Tarballs auf php.net lagen. Öffentlicher Proof-of-Concept-Code erwies sich als deutlich weniger zuverlässig als die Schlagzeilen — aber „schwer zuverlässig auszunutzen” ist eine Aussage über die PoCs dieser Woche, nicht über die der nächsten.

🚨 Zusammenfassung

CVE-IDs: CVE-2026-109618 („RCE via OOM corruption”) und CVE-2026-109619 („RCE via stale global state”), zusammen bekannt als PHP2Shell
CVSS-4.0-Score: 9.2 Critical für beide (bewertet vom PHP-Security-Team), Vektor CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Weitere Bewertungen: Red Hat stuft das Problem als Important ein (CVSS 3.1 8.1); laut Red Hat bewertet NVD es mit 9.8
CWE: CWE-416: Use After Free, CWE-755: Improper Handling of Exceptional Conditions, CWE-824: Access of Uninitialized Pointer, CWE-1325, CWE-1419
Hersteller-Advisories: GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp, veröffentlicht am 2026-10-21
Betroffene Software: PHP unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12; sämtliche Versionen von 7.4, 8.0 und 8.1 (kein offizielles Release, nur Source-Backports); der verwundbare Codepfad reicht zurück bis PHP 5.4.0 (2012)
Betroffene SAPIs: Alles, was HTTP ausliefert — Apache mod_php, PHP-FPM, php-cgi, FrankenPHP und LiteSpeed. PHP bewertet das Risiko für mod_php am höchsten
Angriffsvektor: Netzwerk — ein präparierter multipart/form-data-Request an einen beliebigen PHP-Endpunkt
Authentifizierung erforderlich: Nein. Authentifizierung auf Anwendungsebene hilft nicht, weil PHP den bösartigen Request verarbeitet, bevor die Anwendung es tut
Impact: Remote Code Execution als Web-Worker-Benutzer (z. B. www-data) sowie Memory Disclosure von Daten anderer Requests
Patch-Status: Verfügbar für 8.2-8.5; Linux-Distributionen und LTS-Anbieter erhielten die Patches vorab und liefern Backports, die häufig die alte Upstream-Versionsnummer behalten
Workarounds: PHP hat Konfigurationsänderungen veröffentlicht, die die Angriffsfläche verkleinern, eine Installation aber nicht sicher machen
Ausnutzungsstatus: Exploit-Versuche in freier Wildbahn beobachtet (Amazon, Cloudflare, watchTowr), darunter ein Versuch vier Tage vor der Veröffentlichung. Öffentliche PoCs funktionieren Berichten zufolge nur gegen eng begrenzte Kombinationen aus OS, PHP-Version und Webserver
CISA KEV: Nicht gelistet (geprüft gegen KEV-Katalogversion 2026.10.23). CISA hat am 2026-10-21 einen Alert mit der Aufforderung zum sofortigen Patchen veröffentlicht

🖥️ Was ist PHP?

PHP ist die serverseitige Skriptsprache hinter einem sehr großen Teil des Webs. PHP ist kein einzelnes Produkt, das man in einer Asset-Liste findet — es ist eine Runtime, eingebettet in andere Produkte: WordPress, Drupal, Joomla, Magento/Adobe Commerce, Shopware, WooCommerce, Nextcloud, MediaWiki, Roundcube, phpMyAdmin, WHMCS und jede hauseigene Laravel- oder Symfony-Anwendung. Wiz überschrieb seine Analyse dieser Bugs mit „70% des Internets” betroffen; Cortex Xpanse von Palo Alto Networks zählte mehr als 22,6 Millionen exponierte Instanzen, die verwundbar sein könnten.

PHP läuft auf eine von wenigen Arten innerhalb eines Webservers, den sogenannten SAPIs. Bei mod_php wird der Interpreter in jeden Apache-Worker-Prozess geladen. Bei PHP-FPM nimmt ein separater Pool langlebiger Worker-Prozesse Requests von nginx oder Apache über FastCGI entgegen. FrankenPHP und LiteSpeed (LSAPI) sind neuere Alternativen. Allen gemeinsam ist eine Eigenschaft, die hier entscheidend ist: Ein Worker-Prozess startet nicht für jeden Request neu — er verarbeitet Hunderte oder Tausende Requests nacheinander und setzt seinen internen Zustand dazwischen zurück.

Typische Einsatzszenarien

Content-Management-Systeme und Unternehmenswebsites (WordPress, Drupal, Joomla, TYPO3)
E-Commerce-Plattformen mit Kunden- und Zahlungsdaten (Magento/Adobe Commerce, Shopware, WooCommerce)
Collaboration- und Filesharing-Plattformen (Nextcloud) sowie Webmail (Roundcube)
Hosting-Control-Panels und Abrechnungssysteme (Plesk, WHMCS) sowie Admin-Tools (phpMyAdmin)
Individuelle Business-Anwendungen auf Basis von Laravel, Symfony und ähnlichen Frameworks

Warum ein Engine-Bug anders ist

Hat ein CMS-Plugin eine RCE, patcht man das Plugin. Hat der Interpreter eine, ist jede Anwendung auf diesem Interpreter gleichzeitig exponiert — auch solche mit völlig sauberem Code. Forscher von Calif meldeten unauthentifizierte Codeausführung gegen Standardinstallationen von Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony und WHMCS. Der verwundbare Code versteckt sich außerdem an Stellen, die in keinem Inventar als „PHP” auftauchen: Container-Images, Appliances und Anwendungen, die ihren eigenen Interpreter mitbringen.

🔍 Technische Analyse

Beschreibung der Schwachstelle

PHP behandelt bestimmte fatale Zustände — vor allem Speichermangel — indem es die aktuelle Operation per longjmp() abbricht und direkt in das Request-Cleanup springt. Das ist schnell und einfach, bedeutet aber, dass eine Operation auf halbem Weg liegen bleiben kann. PHP2Shell missbraucht zwei Folgen dieses Designs:

CVE-2026-109618 — RCE via OOM corruption. Erreicht PHP sein Speicherlimit, während interne Request-Daten nur teilweise initialisiert sind, behandelt das Request-Cleanup die halbfertigen Daten später als gültig.
CVE-2026-109619 — RCE via stale global state. Request-eigener Zustand in Worker-weiten Globals kann weiterleben, nachdem sein Speicher bereits freigegeben wurde. Ein späterer Request auf demselben Worker kann diesen veralteten Pointer nutzen, bevor die normale Initialisierung ihn zurücksetzt — ein Use-after-free über Request-Grenzen hinweg.

Beide lassen sich durch einen präparierten multipart/form-data-Request auslösen — denselben Request-Typ, den jedes HTML-Upload-Formular sendet.

Root-Cause-Analyse

Zähler werden vor der Allokation aktualisiert, die fehlschlagen kann (CVE-2026-109618). Datadog Security Labs hat den Referenzfall auf das Einfügen in Hash-Tabellen in _zend_hash_str_add_or_update_i() (Zend/zend_hash.c) zurückgeführt, das genutzt wird, während PHP Formularfelder in $_POST umwandelt. Die Funktion erhöht die Elementzähler der Tabelle, bevor sie den neuen Key alloziert. Überschreitet diese Allokation memory_limit, löst PHP einen Fatal Error aus und bricht das Einfügen ab — zurück bleibt ein gezählter Bucket, dessen Key und Value nie geschrieben wurden.
Das Cleanup vertraut dem, was es vorfindet. Beim Request-Shutdown zerstört PHP $_POST, indem es jeden gezählten Bucket besucht und dessen Inhalt als PHP-Wert interpretiert. Der uninitialisierte Bucket enthält, was zuvor in diesem Speicher lag — und das kann ein Angreifer per Heap-Grooming beeinflussen.
Limits verhindern den OOM nicht. Das Advisory nennt mehrere Verhaltensweisen beim Multipart-Parsing, die einen Request in den Speichermangel treiben, obwohl er scheinbar innerhalb der Limits bleibt: eine fehlende oder unbrauchbare Content-Length, unbegrenzt viele Header pro Part sowie leere File-Controls, die nicht gegen max_file_uploads zählen, aber trotzdem Metadaten-Arrays erzeugen. Verschachtelte Feldnamen wie files[a][b][c] erreichen den verwundbaren String-Key-Pfad.
mod_php führt das Cleanup auch nach fehlgeschlagenem Startup aus. Unter Apache mod_php läuft der Shutdown selbst dann, wenn der Request-Startup fehlschlug — die Korruption ist also erreichbar, bevor irgendein Anwendungscode ausgeführt wird. PHP-FPM beendet den Child-Prozess bei fehlgeschlagenem Startup, was genau diese Sequenz blockiert — PHP hält FPM über andere Pfade für anfällig, meldet für diese CVE aber keinen vollständigen FPM-Exploit.
Zustand, der seinen Request überlebt (CVE-2026-109619). Fehler-, Session-, Objekt- und Extension-Zustand in Globals wird nicht immer zurückgesetzt, bevor der Request-Heap freigegeben wird. Ein Fatal Error (OOM, Execution Timeout, fehlgeschlagenes require, nicht abgefangener Fehler) kann eine Operation abbrechen, bevor ihr Reset läuft; späte Shutdown-Diagnosen können den Fehlerzustand sogar erneut befüllen, nachdem er geleert wurde. Ein späterer Request auf demselben Worker liest dann freigegebenen Speicher. PHP hat zwei Konsumenten bestätigt: fatal_error_backtraces in PHP 8.5 (standardmäßig aktiv, bestätigte RCE auf mod_php) und Session Upload Progress (standardmäßig aktiv, funktioniert auch ohne session_start(), bestätigte RCE auf mod_php und PHP-FPM).

Das Muster hinter beiden CVEs ist dasselbe: ein Fehlerpfad, der den Prozess in einem Zustand hinterlässt, den der normale Pfad nie erwartet hat, gefolgt von Code, der annimmt, dass der normale Pfad gelaufen ist. Der Fix ersetzt das sofortige longjmp() bei OOM durch ein Soft Limit, das den Fehler bis zum nächsten sicheren Punkt verzögert, plus ein Hard Limit, das den Worker per _exit() beendet, statt das Cleanup auszuführen — und setzt Request-eigenen globalen Zustand früher zurück.

Angriffsvektor

Die öffentliche Forschung beschreibt drei Phasen. Der folgende Request zeigt die Gestalt, die Datadog zu Detection-Zwecken dokumentiert hat — er ist kein Exploit:

# NUR ILLUSTRATIV -- Request-GESTALT zur Detection und Log-Auswertung.
# Basiert auf Datadog Security Labs' Beschreibung oeffentlicher PoCs; KEIN funktionsfaehiger Exploit.
# Die Signale: ein Multipart-Body mit PHP_SESSION_UPLOAD_PROGRESS, Hunderte
# Parts, tief verschachtelte, maschinell erzeugte Feldnamen und uebergrosse Fuellwerte.

POST /index.php HTTP/1.1
Host: www.example.com
Content-Type: multipart/form-data; boundary=----XYZ
Cookie: PHPSESSID=<vom Angreifer gewaehlter Wert>

------XYZ
Content-Disposition: form-data; name="PHP_SESSION_UPLOAD_PROGRESS"

x
------XYZ
Content-Disposition: form-data; name="files[R00001][a][a][a]"

<Fuelldaten>
------XYZ
... (~900 weitere Parts in unter 1 MB, bis memory_limit erschoepft ist)

Die unterbrochene Operation erreichen. Ein präparierter Request treibt PHP während der Request-Initialisierung in einen Allokationsfehler, bevor das Zielskript läuft.
Den Restspeicher kontrollieren. Heap-Grooming bestimmt, worauf der abgebrochene Bucket oder der veraltete Pointer zeigt. Wiz hat eine Memory-Disclosure-Technik beschrieben, die Heap-Daten im PHPSESSID-Response-Cookie zurückliefert und so die Adressen bereitstellt, die zum Aushebeln von ASLR nötig sind.
Cleanup in Codeausführung verwandeln. Das Shutdown-Cleanup wird auf einen Shell-Befehlsaufruf umgelenkt, der als Web-Worker-Benutzer läuft. In Datadogs Labor (mod_php, Apache prefork, memory_limit=16M) lief die vollständige Kette in etwa 3,1 Sekunden durch, konnte ein gewöhnliches HTTP 200 zurückgeben und musste den Worker nicht zum Absturz bringen.

Mehrere Worker senken die Erfolgsquote pro Request, weil der Folge-Request des Angreifers auf demselben Worker landen muss — sie beseitigen die Bedingung aber nicht.

Ausnutzung in freier Wildbahn

2026-10-17 — Amazon Threat Intelligence beobachtet einen Exploit-Versuch gegen sein MadPot-Honeypot-Netzwerk, vier Tage vor der Veröffentlichung.
2026-10-20 — CVE-IDs und Details werden vor der für den 22. Oktober geplanten Veröffentlichung in sozialen Medien geleakt; watchTowr bestätigt öffentlich, dass die Bugs echt sind.
2026-10-21, 03:02 UTC — Cloudflares WAF-Regeln blockieren Exploit-Versuche, rund neun Stunden vor Veröffentlichung des Patches; Cloudflare meldet ab 07:43 UTC „early attacks emerging”.
2026-10-21 — watchTowr meldet Exploit-Versuche gegen beide CVEs in seinem Attacker-Eye-Honeypot-Netzwerk; Amazon meldet weitere Versuche von offenbar mehreren Akteuren.
Zuverlässigkeit ist die offene Frage. Das PHP-Security-Team erklärte, es habe unter den PoCs zum Zeitpunkt der Veröffentlichung „keine funktionsfähigen Exploits identifiziert”. Rapid7 stellte fest, dass jeder öffentliche PoC nur für eine bestimmte Kombination aus OS, PHP-Version und Webserver funktionierte; ein von Sansec zitierter Forscher fand heraus, dass die meisten zusätzlich eine Local-File-Inclusion-Lücke im Ziel benötigten. Tenable warnt, dass manch kursierender „Exploit”-Code selbst mit Malware versetzt ist.
2026-10-25 — Unit 42 zieht ein früheres Update zurück, das einen Einbruch bei einer Regierungsbehörde mit PHP2Shell in Verbindung brachte; der initiale Zugriffsvektor ließ sich nicht bestätigen.
Kein CISA-KEV-Eintrag in Katalogversion 2026.10.23 und zum Zeitpunkt der Erstellung keine bestätigte öffentliche Kompromittierung, die diesen CVEs zugeordnet ist.

Post-Exploitation-Impact

Codeausführung als Web-Worker (www-data, apache, nginx) — genug, um jede Datei zu lesen, die die Anwendung lesen kann, einschließlich .env-Dateien, wp-config.php, Datenbank-Zugangsdaten und API-Keys.
Memory Disclosure anderer Requests: Das Leak-Primitiv kann Passwörter, Session-Tokens, API-Keys und potenziell TLS-Private-Keys offenlegen, die derselbe Worker verarbeitet.
Datenbankzugriff mit den Zugangsdaten der Anwendung — Kundendaten, Bestellungen, zahlungsnahe Daten auf E-Commerce-Plattformen.
Web-Shells und Persistenz in beschreibbaren Upload- oder Cache-Verzeichnissen, die den Patch überleben, wenn niemand hinschaut.
Payment Skimming in Shops: Eingeschleustes Checkout-JavaScript ist die klassische Monetarisierung kompromittierter Magento- und WooCommerce-Installationen.
Pivoting von einem Webserver in der DMZ ins interne Netz sowie laterale Bewegung zwischen Mandanten im Shared Hosting, wo eine PHP-Installation viele Kunden bedient.

📊 Impact-Bewertung

Unmittelbarer Impact

Unauthentifizierte RCE gegen die Runtime, nicht gegen die Anwendung: Sauberer, vollständig gepatchter Anwendungscode schützt nicht.
Authentifizierung und WAF-Logik in der Anwendung greifen nicht — der bösartige Request wird verarbeitet, bevor Ihr Code geladen ist.
Stiller Erfolg ist möglich: Ein Angriff kann mit HTTP 200 und ohne Absturz enden. Ein vollständiger Versuch hinterlässt unter Umständen nur zwei bis vier Memory-Exhaustion-Fehler auf einem Worker.
Verstecktes Inventar: Mitgelieferte Interpreter in Containern und Appliances tauchen nicht in dpkg -l auf dem Host auf.

Betroffene Versionen

PHP-Branch	Betroffen	Erstes gefixtes Release
8.5	< 8.5.12	8.5.12
8.4	< 8.4.27	8.4.27
8.3	< 8.3.36	8.3.36
8.2	< 8.2.35	8.2.35 (Branch-EOL 2026-12-31)
7.4, 8.0, 8.1	Alle	Kein offizielles Release — PHP hat minimale Source-Backports veröffentlicht; Paket einer Distribution / eines LTS-Anbieters nutzen oder upgraden
5.4 - 7.3	Alle	Kein Fix — upgraden

Distributionspakete enthalten den Fix häufig ohne Änderung der Upstream-Versionsnummer. Einige Beispiele aus den Trackern der Hersteller:

Distribution	Paket	Gefixte Version
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1 (DSA-6574-1)
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1 (DLA-4848-1)
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28
Ubuntu 20.04 LTS (ESM)	php7.4	7.4.3-4ubuntu2.29+esm5

Gibt php -v auf Ubuntu 24.04 also 8.3.6 aus, heißt das nicht, dass Sie verwundbar sind — und nur bei einem selbst kompilierten Build beweist die Ausgabe 8.3.36 überhaupt etwas.

Ein Folgeproblem, CVE-2026-115560, hat PHP am 2026-10-23 veröffentlicht. Es setzt eine ungewöhnliche Konfiguration voraus (eine Anwendung, die session.serialize_handler zur Laufzeit auf php umstellt, bei aktivem Upload Progress); PHP veröffentlicht das vollständige Advisory mit dem nächsten regulären Release und empfiehlt bis dahin session.upload_progress.enabled=0.

Betroffene Umgebungen

Apache mit mod_php — höchstes Risiko; der bestätigte Exploit-Pfad vor der Anwendung. Verbreitet auf Debian/Ubuntu-LAMP-Stacks und im Shared Hosting.
PHP-FPM hinter nginx oder Apache — über den Session-Upload-Progress-Pfad bestätigt ausnutzbar; Red Hat weist darauf hin, dass Standard-RHEL-Deployments FPM verwenden, was die Ausnutzung in der Praxis erschwert, aber nicht unmöglich macht.
Shared Hosting und Control Panels (Plesk, cPanel-artige Setups), wo eine einzige Kompromittierung viele Kunden treffen kann.
Container-Images auf Basis von FROM php:* — das offizielle Docker-Image php erhält für 8.1 und älter keinen Fix, und laufende Container behalten das alte Binary, bis sie neu gebaut und ausgerollt werden.
PHP-Versionen am Lebensende (7.x, 8.0, 8.1), die in Legacy-Fachanwendungen noch weit verbreitet sind.

Angreiferprofile

Opportunistische Massenscanner — sobald ein portabler Exploit auftaucht, ist das internetweite Besprühen jedes PHP-Endpunkts billig.
Skimming-Gruppen im Magecart-Stil, die Magento-, Shopware- und WooCommerce-Shops wegen Kartendaten angreifen.
Initial Access Broker und Ransomware-Affiliates, für die ein Webserver in der DMZ ein Brückenkopf zum Weiterverkaufen oder Pivotieren ist.
Gezielte Angreifergruppen, die PHP-basierte Webmailer, Filesharing-Lösungen und Intranet-Portale als Einstiegspunkt in Behörden- und Unternehmensnetze nutzen.

🛡️ Mitigationsstrategien

Sofortmaßnahmen (Priorität 1)

Jede PHP-Runtime inventarisieren — und welche SAPI das Web bedient. Die CLI-Version ist nicht zwingend die, die Apache oder FPM ausführt.

# Version des CLI-Interpreters -- kann von der des Webservers abweichen.
php -v

# Debian/Ubuntu: installierte PHP-Pakete mit exakter Paketversion.
dpkg -l 'php*' | grep '^ii'

# RHEL/AlmaLinux/Rocky/Fedora: installierte PHP-Pakete.
rpm -qa 'php*'

# Ist mod_php in Apache geladen? (zuerst Debian/Ubuntu, dann RHEL-Familie)
apache2ctl -M 2>/dev/null | grep -i php
httpd -M 2>/dev/null | grep -i php

# Welche PHP-FPM-Dienste laufen?
systemctl list-units --type=service 'php*-fpm*'

Prüfen, ob Ihr Distributionspaket den Backport bereits enthält. Versionsnummern allein können täuschen (siehe Tabelle oben); das Paket-Changelog nicht.

# Debian/Ubuntu -- php8.3 an Ihren installierten Branch anpassen. Anzahl > 0 = gefixt.
zgrep -c CVE-2026-109618 /usr/share/doc/php8.3-common/changelog.Debian.gz

# RHEL/AlmaLinux/Rocky -- gibt die Changelog-Zeilen mit den CVEs aus, wenn gefixt.
rpm -q --changelog php-common | grep -E 'CVE-2026-10961[89]'

Patchen — das ist der einzige vollständige Fix. Auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisieren oder auf das zurückportierte Paket Ihres Anbieters. PHP 8.1 und älter: Fix einer Distribution oder eines LTS-Anbieters nutzen oder auf einen unterstützten Branch upgraden.
```
# Debian/Ubuntu -- Security-Updates fuer alle installierten Pakete einspielen.
sudo apt update && sudo apt upgrade

# RHEL/AlmaLinux/Rocky/Fedora -- alle installierten PHP-Pakete aktualisieren.
sudo dnf upgrade 'php*'
```

Jeden Worker neu starten. Ein gepatchtes Paket auf der Platte bewirkt nichts, solange alte Worker den alten Code im Speicher halten.

# Debian/Ubuntu: FPM (Version anpassen) und/oder Apache fuer mod_php neu starten.
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2

# RHEL-Familie: FPM und Apache.
sudo systemctl restart php-fpm httpd

# Pruefen, dass nichts mehr die alten Bibliotheken nutzt.
sudo needrestart -r l           # Debian/Ubuntu: Dienste auflisten, die einen Neustart brauchen
sudo dnf needs-restarting -s    # RHEL-Familie: Dienste auflisten, die einen Neustart brauchen

Container neu bauen und ausrollen. Prüfen Sie, was tatsächlich läuft, nicht was im Dockerfile steht:

# PHP-Version in jedem laufenden Container ausgeben (oder "no php").
docker ps --format '{{.Names}}' | while read -r c; do
  printf '%s: ' "$c"
  docker exec "$c" php -r 'echo PHP_VERSION, PHP_EOL;' 2>/dev/null || echo 'no php'
done

Wenn Sie heute nicht patchen können: Angriffsfläche verkleinern. PHP stellt klar, dass diese Einstellungen eine Installation nicht sicher machen — sie blockieren nur die bestätigten Pfade. Setzen Sie sie dort, wo Anwendungen sie nicht überschreiben können, und starten Sie danach jeden Worker neu.

; PHP-FPM-Pool, z. B. /etc/php/8.3/fpm/pool.d/www.conf (Debian/Ubuntu-Layout).
; php_admin_*-Werte koennen von der Anwendung nicht per ini_set() ueberschrieben werden.

; CVE-2026-109618: den steuerbaren memory_limit-Fehler entfernen.
; Nebenwirkung: Ein Request kann nun den gesamten Speicher belegen -- mit einem
; Container-/cgroup-Limit kombinieren. NICHT stattdessen RLIMIT_AS / RLIMIT_DATA nutzen.
php_admin_value[memory_limit] = -1

; CVE-2026-109619 (und CVE-2026-115560): Session Upload Progress deaktivieren.
php_admin_flag[session.upload_progress.enabled] = off

; Nur PHP 8.5: Fatal-Error-Backtraces deaktivieren (bestaetigter RCE-Pfad).
php_admin_flag[fatal_error_backtraces] = off

# Apache mit mod_php -- dieselben Einstellungen in der VHost- oder Server-Konfiguration.
# Nicht in .htaccess und nicht per ini_set(): Sie muessen vor dem Request-Parsing greifen.
php_admin_value memory_limit -1
php_admin_flag session.upload_progress.enabled off
# Nur PHP 8.5:
php_admin_flag fatal_error_backtraces off

PHP empfiehlt außerdem eine konservative post_max_size (8M ohne Uploads, 32M mit) mit upload_max_filesize darunter sowie Limits am Proxy für dekodierte Body-Größe, Anzahl der Parts, Header pro Part und Verschachtelungstiefe — auch für Requests ohne brauchbare Content-Length.

Multipart am Edge blockieren, wo Sie es sich leisten können. Jeder bekannte Trigger ist ein multipart/form-data-Request. Sansec hat diese Notlösungen veröffentlicht; sie brechen Datei-Uploads und manche Checkout-Formulare, entfernen Sie sie also nach dem Patchen wieder:

# nginx -- im server {}- oder location {}-Block der PHP-Site.
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

# Apache (mod_rewrite) -- Multipart-Request-Bodies mit 403 abweisen.
RewriteEngine On
RewriteCond %{HTTP:Content-Type} multipart/form-data [NC]
RewriteRule ^ - [F]

Detection-Maßnahmen

Zuverlässige Netzwerk-IoCs gibt es noch nicht; die Spuren finden sich in PHP-Error-Logs, Webserver-Error-Logs und der Prozess-Abstammung. Datadog weist darauf hin, dass in Unknown on line 0 bedeutet, dass PHP während der Request-Initialisierung gescheitert ist — bevor irgendein Skript lief.

# Fataler OOM beim Request-Startup. Mit mod_php auf Debian/Ubuntu landen PHP-Fehler
# standardmaessig im Apache-Error-Log; bei FPM das konfigurierte error_log pruefen.
grep -E 'Allowed memory size of [0-9]+ bytes exhausted.*Unknown on line 0' /var/log/apache2/error.log

# Abstuerze von Apache-Workern (Segfaults) -- AH00052 ist Apaches "child pid ... exit signal"-Meldung.
grep 'AH00052' /var/log/apache2/error.log

# Prozessbaum aller Prozesse des Web-Benutzers -- eine Shell unterhalb eines
# PHP-/Apache-Workers ist der staerkste Indikator fuer eine erfolgreiche Ausnutzung.
ps -u www-data -o pid,ppid,lstart,cmd --forest

# Sigma-Regel -- Shell, gestartet von einem PHP ausliefernden Web-Worker (Linux Process Creation).
# Mit sigma-cli fuer Ihr SIEM konvertieren; Anwendungen ausnehmen, die legitim exec() nutzen.
title: Shell Spawned by PHP Web Worker (possible PHP2Shell post-exploitation)
status: experimental
description: Detects sh/bash/dash started by Apache, PHP-FPM, FrankenPHP or LiteSpeed PHP workers.
logsource:
  product: linux
  category: process_creation
detection:
  selection_parent_name:
    ParentImage|endswith:
      - '/apache2'
      - '/httpd'
      - '/frankenphp'
      - '/lsphp'
  selection_parent_fpm:
    ParentImage|contains: '/php-fpm'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
  condition: (selection_parent_name or selection_parent_fpm) and selection_child
falsepositives:
  - Applications that legitimately call exec(), system() or proc_open()
level: high

Weitere Signale, nach denen sich in WAF- oder Proxy-Logs mit erfassten Request-Bodies suchen lässt: Multipart-Requests, die PHP_SESSION_UPLOAD_PROGRESS oder PHPSESSID als Formularfeld enthalten, wo die Anwendung sie nie nutzt; Hunderte Parts in einem kleinen Body; tief verschachtelte Feldnamen wie files[R00001][a][a][a]; <?php oder |O: in Upload-Dateinamen; sowie Set-Cookie: PHPSESSID=-Response-Werte, die ungewöhnlich lang sind oder Binärdaten enthalten. Eine Häufung von zwei bis vier Memory-Exhaustion-Fehlern auf einem Worker in kurzer Zeit, gefolgt von Ruhe, verdient eine Untersuchung auch ohne Absturz — und das Fehlen von Log-Einträgen beweist keine Sicherheit.

Langfristige Sicherheitsverbesserungen

Weg von mod_php. PHP in jedem Apache-Worker auszuführen, hat diesem Bug seinen stärksten Exploit-Pfad verschafft. PHP-FPM mit einem eigenen Pool pro Anwendung begrenzt sowohl die Ausnutzbarkeit als auch den Schadensradius.
Runtimes inventarisieren, nicht nur Anwendungen. Erfassen Sie Interpreter-Versionen in Containern, Appliances und mitgelieferten Installationen. Eine Liste der CMS-Versionen hat diese Woche niemandem verraten, welche Server PHP 8.1 ausführen.
PHP am Lebensende ablösen. 7.4, 8.0 und 8.1 erhielten hier nur minimale Source-Backports; der nächste Engine-Bug bekommt womöglich nicht einmal das. PHP 8.2 selbst erreicht sein Lebensende am 2026-12-31.
Least Privilege für den Web-Worker. Schreibgeschützte Code-Verzeichnisse, keine Shell für das Dienstkonto, ausgehende Egress-Filterung, damit eine Reverse Shell nicht nach Hause telefonieren kann, und Secrets, die zur Laufzeit injiziert werden, statt in lesbaren Konfigurationsdateien zu liegen.
Pipelines, die wirklich neu bauen. Auf einen alten Digest gepinnte Container-Images bleiben für immer verwundbar; machen Sie Base-Image-Updates und Redeployments zur Routine, nicht zur Notfallarbeit.
Loggen, was Sie beim nächsten Mal brauchen. Leiten Sie PHP-Error-Logs, Webserver-Error-Logs und Process-Creation-Telemetrie vom Host weg; diese Woche waren sie die einzigen Orte, an denen Spuren auftauchten.

⚠️ Warum ist das kritisch?

Es ist die Runtime, nicht die App. Jede PHP-Anwendung auf einem betroffenen Interpreter ist exponiert, egal wie gut ihr eigener Code geschrieben ist.
Keine Authentifizierung, bevor Ihr Code läuft. Auf mod_php ist der bestätigte Pfad abgeschlossen, bevor die Anwendung den Request überhaupt sieht.
Die Standardkonfiguration reicht. PHP hat RCE auf mod_php mit Standard-Input- und Speicherlimits validiert; Session Upload Progress und die Backtraces in PHP 8.5 sind standardmäßig aktiv.
Vierzehn Jahre Releases. Der verwundbare Codepfad reicht bis PHP 5.4.0 zurück — Legacy-Systeme, die niemand anfasst, sind betroffen und oft nicht zu fixen.
Die Veröffentlichung wurde geleakt. Versuche wurden vier Tage vor dem Patch und Stunden vor dem Release beobachtet; ein ruhiges Patch-Fenster gab es nicht.
Versionsnummern lügen in beide Richtungen. Zurückportierte Distributionspakete sehen alt aus, sind aber gefixt; selbst gebaute Binaries und Container sehen auf dem Papier aktuell aus, sind es aber womöglich nicht.
Stiller Erfolg. Ein Exploit kann HTTP 200 zurückgeben, keinen Absturz hinterlassen und nur eine Handvoll OOM-Zeilen in einem Log, das kaum ein Team liest.
Der unzuverlässige PoC von heute ist der portable von morgen. Forscher erwarten bereits weitere Varianten desselben Fehlerpfad-Musters.

📅 Timeline und Disclosure

2026-08-01 — Calif findet bei einem PHP-Audit mehrere RCE-Pfade.
2026-08-11 — Calif meldet den ersten Bug an das PHP-Security-Team; die koordinierte Veröffentlichung beginnt.
2026-08-24 — Wiz Research meldet die Schwachstellen unabhängig davon an PHP.
2026-10-17 — Amazon Threat Intelligence beobachtet einen Exploit-Versuch gegen seine MadPot-Honeypots.
2026-10-20 — CVE-IDs und Details werden vor der für den 22. Oktober geplanten Veröffentlichung geleakt; watchTowr bestätigt die Bugs; PHP kündigt ein Notfall-Release für den 21. Oktober, 14:00 UTC, an; CERT-EU veröffentlicht das Advisory 2026-018.
2026-10-21 — Cloudflare-WAF-Regeln ab 03:02 UTC aktiv; PHP veröffentlicht 8.5.12, 8.4.27, 8.3.36 und 8.2.35 mit den Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp sowie Source-Backports für 7.4, 8.0 und 8.1; CISA veröffentlicht einen Alert; Ubuntu veröffentlicht USN-8948-1; mehrere niederländische Websites, darunter die des NCSC, gehen vorsorglich offline.
2026-10-22 — Rapid7 veröffentlicht seine PoC-Analyse: Öffentliche Exploits funktionieren nur unter engen Bedingungen.
2026-10-23 — PHP veröffentlicht ein informatives Advisory zu CVE-2026-115560; die CISA-KEV-Katalogversion 2026.10.23 listet die PHP2Shell-CVEs nicht.
2026-10-25 — Unit 42 zieht die Zuordnung eines Einbruchs bei einer Regierungsbehörde zu PHP2Shell zurück.

📚 Ressourcen und Referenzen

🤝 SEKurity Unterstützt Sie

Die meisten Vulnerability-Management-Prozesse sind um Produkte herum organisiert: das CMS, der Shop, die VPN-Appliance. PHP2Shell erinnert daran, dass auch die Schicht darunter Angriffsfläche ist — und dass gerade diese Schicht am seltensten einen Verantwortlichen hat. Das Web-Team verantwortet WordPress, das Plattform-Team das Base-Image; für den PHP-8.1-Interpreter, der vor drei Jahren in einen Container gebacken wurde, ist niemand zuständig.

Die sinnvollen Fragen dieser Woche sind konkret. Welche Ihrer Server laufen mit mod_php, welche mit FPM? Welche PHP-Binaries stecken in Ihren Containern und Appliances, und wann wurden diese Images zuletzt neu gebaut? Hätten Ihre Logs vier OOM-Fehler auf einem Worker in der Nacht auf Mittwoch gezeigt — und hätte jemand sie gelesen? Und wenn ein Angreifer tatsächlich als www-data auf Ihrem Shop-Server landet: Was kann dieses Konto lesen, und wohin kann es sich verbinden?

Wir testen Web-Anwendungen und die Infrastruktur darunter aus der Position, in der ein echter Angreifer beginnt — unauthentifiziert, aus dem Internet — und verfolgen einen Brückenkopf bis zu dem, was er tatsächlich wert ist. Wenn Ihre PHP-Landschaft noch nie unterhalb der Anwendungsschicht betrachtet wurde, ist diese Woche der richtige Zeitpunkt, damit anzufangen.

Unsere Leistungen

Penetration Testing: Web-Anwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Web-Anwendungen und Web-Infrastruktur ist unser Antrieb.

Quellen

PHP — Security Advisory, Release-Ankündigungen und informatives Advisory (Archiv Oktober 2026) — gefixte Versionen 8.5.12/8.4.27/8.3.36/8.2.35, Liste der betroffenen SAPIs, mod_php mit höchstem Risiko, vorläufige Mitigationen (memory_limit=-1, session.upload_progress.enabled=0, fatal_error_backtraces=0, post_max_size), Source-Backports für 7.4/8.0/8.1, EOL-Datum von 8.2, informatives Advisory zu CVE-2026-115560
GitHub — GHSA-w8hw-w9fx-j79w (CVE-2026-109618) — CVSS-Vektor, CWEs, longjmp()-OOM-Root-Cause, Multipart-OOM-Trigger, Analyse pro SAPI, Soft/Hard-OOM-Fix, Credits
GitHub — GHSA-6wmf-4rv5-p3rp (CVE-2026-109619) — Root Cause „stale global state”, bestätigte Pfade über fatal_error_backtraces und Session Upload Progress, Mitigationen
Datadog Security Labs — PHP2Shell: detection, analysis, and remediation — Root Cause in _zend_hash_str_add_or_update_i(), Exploit-Phasen, Labor-Laufzeit, Request-Indikatoren, Log-Signaturen, Prozess-Abstammung
Rapid7 — CVE-2026-109618 and CVE-2026-109619: Critical Unauthenticated RCE in PHP — CVSS-Vektor, Analyse der PoC-Zuverlässigkeit, Exploit-Versuche, Mitigationsempfehlungen
Tenable — php2shell FAQ — Timeline inkl. Amazon-MadPot-Versuch, Leak und vorgezogenes Release, CISA-Alert, KEV-Status, Warnung vor mit Malware versetzten PoCs, Credits
watchTowr — PHP2Shell FAQ — Versuche in freier Wildbahn über Attacker Eye, betroffene Legacy-Versionen, Leak-Timeline
Sansec — PHP2Shell: PHP RCE — Disclosure-Timeline, Ursprung in PHP 5.4.0, von Calif getestete Anwendungen, Notlösungen zum Blockieren von Multipart, Befehle zur Backport-Prüfung, Zeitpunkt der ersten Angriffe laut Cloudflare
Unit 42 — Threat Brief: CVE-2026-109618, CVE-2026-109619 — 22,6 Millionen exponierte Instanzen, Rücknahme der Einbruchs-Zuordnung am 2026-10-25
Red Hat — CVE-2026-109618 — Bewertung Important, CVSS 3.1 8.1, NVD 9.8, PHP-FPM als RHEL-Standard
Debian Security Tracker — CVE-2026-109618 und Ubuntu — CVE-2026-109618 — zurückportierte Paketversionen
PPC Land — Cloudflare blocks php2shell exploits 9 hours before PHP flaws went public — Zeitpunkt der WAF-Regeln
Wiz — CVE-2026-109618 — Reichweite der betroffenen Runtime
CISA — Known Exploited Vulnerabilities Catalog — KEV-Status (Katalogversion 2026.10.23)
The Hacker News — CISA Flags Two Actively Exploited Critical Flaws in Collabora Online and Arista VeloCloud — weitere KW43-Kandidaten, die für die Themenauswahl betrachtet wurden
EntryZero — Top 5 Hacker-relevant Vulnerabilities (wöchentliches Briefing) — wöchentliches Schwachstellen-Briefing, das für die Themenauswahl herangezogen wurde

InSEKurity of the Week (CW43/2026): PHP2Shell – unauthentifizierte RCE in PHP (CVE-2026-109618, CVE-2026-109619)