CVE-2026-109618 / -109619 – Kritische PHP-RCE

Was steckt dahinter?

CVE-2026-109618 — OOM-Corruption

Bei einem Out-of-Memory-Fehler bricht verwundbares PHP den aktuellen Kontext über longjmp() ab. Geschieht das, während Request-Daten erst teilweise initialisiert sind, kann der Shutdown-Pfad später ungültige Daten lesen oder als gültige Strukturen interpretieren.

Relevant ist dabei auch der Unterschied zwischen Request-Größe und internem Speicherbedarf. Zahlreiche Multipart-Header oder verschachtelte Felder können deutlich mehr Speicher beanspruchen, als ihre übertragene Größe vermuten lässt. Ein kleines post_max_size allein garantiert deshalb keine Absicherung.

Der Fix verändert die OOM-Behandlung: Ein verzögerter Soft-OOM an einem sicheren VM-Punkt beziehungsweise ein unmittelbarer Prozessabbruch bei einer höheren Grenze verhindert den problematischen Rückweg durch den Cleanup.

Details: GHSA-w8hw-w9fx-j79w — RCE via OOM corruption.

CVE-2026-109619 — Use-after-free

PHP-Worker bearbeiten typischerweise mehrere Anfragen nacheinander. Dabei darf global erreichbarer Zustand nicht weiter auf Speicher einer bereits beendeten Anfrage zeigen. Genau diese Grenze wird hier verletzt: Nach Freigabe des Request-Speichers können veraltete Referenzen bestehen bleiben.

Das ist ein Use-after-free. Dafür braucht es sowohl einen Pfad, der den ungültigen Zustand hinterlässt, als auch einen späteren Zugriff auf diesen Zustand. Upload-Progress ist ein bestätigter Pfad; Fehlerdiagnostik während früher Initialisierungsphasen ein weiterer. Bei PHP 8.5 spielen außerdem Fatal-Error-Backtraces eine Rolle.

Mehr Worker oder Worker-Recycling machen aus einer verwundbaren Installation keine gepatchte Installation. Sie können die Bedingungen einer Angriffskette beeinflussen, beseitigen aber den Fehler nicht.

Details: GHSA-6wmf-4rv5-p3rp — RCE via stale global state.

Bin ich betroffen?

Das PHP-Projekt nennt PHP-FPM, Apache mit mod_php, CGI, FrankenPHP und LiteSpeed als grundsätzlich zu prüfende Web-Betriebsarten. Die konkreten Angriffspfade unterscheiden sich.

Codeausführung erfolgt zunächst mit den Rechten des Web-Workers. Ob daraus Zugriff auf andere Kunden, Secrets oder den Host entsteht, hängt von Dateirechten, Mounts, Prozessisolation und erreichbaren Diensten ab. Eine PHP-RCE bedeutet daher nicht automatisch Root-Zugriff. Im Shared Hosting ist die Kundentrennung trotzdem ein wesentlicher Teil der Risikobewertung.

Abgrenzung der Angriffspfade: GHSA-w8hw-w9fx-j79w — RCE via OOM corruption und GHSA-6wmf-4rv5-p3rp — RCE via stale global state.

PHP 8.1 und älter erhalten keine regulären Projekt-Releases mehr. Die bereitgestellten minimalen Source-Backports für 7.4, 8.0 und 8.1 helfen Paketbauern, verlängern aber nicht den regulären Support. Für solche Installationen braucht es einen belastbaren Nachweis des Paketlieferanten oder eine Migration.

Bei distributionsgepflegten Paketen zählt die vollständige Paketversion. Ubuntu 24.04 LTS liefert den Fix beispielsweise als 8.3.6-0ubuntu0.24.04.13; Debian 13 als 8.4.27-1~deb13u1. Die nackte Upstream-Nummer ist damit kein ausreichender Prüfmaßstab.

Paketnachweise: Ubuntu USN-8948-1 und Debian DSA-6574-1 — php8.4; Upstream: PHP Security Advisory — 21 October 2026.

Schnellcheck auf dem System

Die folgenden Befehle lesen lokale Versions-, Konfigurations- und Prozessinformationen. Die Beispiele verwenden rg (ripgrep); Paketabfragen gelten für Debian/Ubuntu.

# CLI-Version und geladene Konfiguration
php -v
php --ini

# Einstellungen dieses CLI-Binarys
php -r 'foreach ([
    "memory_limit",
    "post_max_size",
    "session.upload_progress.enabled",
    "fatal_error_backtraces"
] as $key) {
    printf("%s=%s\n", $key, var_export(ini_get($key), true));
}'

# Laufende Web-Worker und Startzeiten
ps -eo user,pid,lstart,args | rg '[p]hp-fpm|[p]hp-cgi|[a]pache2|[h]ttpd'

# Vollständige Paketversionen (Debian/Ubuntu)
dpkg-query -W -f='${Package} ${Version}\n' \
  'php*' 'libapache2-mod-php*' 2>/dev/null

Pro virtuellem Host sollte die Zuordnung zu Socket, FPM-Pool oder Container dokumentiert werden. Bei Plesk zusätzlich die Handler unter /opt/plesk/php/ berücksichtigen. Den effektiven Web-Kontext über einen intern beschränkten Diagnoseweg prüfen; eine öffentliche phpinfo()-Seite würde unnötig Konfigurationsdetails offenlegen.

Sofortmaßnahme: PHP aktualisieren

Der dauerhafte Fix ist das Update der tatsächlich verwendeten PHP-Installation. Dazu gehören auch getrennte Handler, FPM-Pools, Container und ältere Laufzeitumgebungen.

1. Zuordnung prüfen: Welche Website läuft über welches Binary, welchen Pool oder welches Image?
2. Gepatchten Build installieren: Upstream-Sicherheitsrelease oder vom Paketlieferanten dokumentierter Backport.
3. Worker erneuern: Betroffene FPM-Dienste beziehungsweise Apache neu starten; bei Containern den Dienst mit dem korrigierten Image neu erstellen.
4. Wirksamkeit prüfen: Paketversion, laufende Prozesse und Web-Handler kontrollieren und einen Funktionstest durchführen.

Hinweise je Umgebung

Die Befehle sind Beispiele für die jeweils genannte Paketquelle und Betriebsart. Sie werden auf dem eigenen System ausgeführt und können eine kurze Unterbrechung verursachen. Vorher Kompatibilität und Wiederherstellbarkeit klären. Wenn der Kandidat noch keinen Fix enthält, ist ein erfolgreiches Upgrade kein Sicherheitsnachweis.

# Paketlisten aktualisieren und angebotene Version prüfen
sudo apt update
apt-cache policy php8.4-fpm php8.4-cli php8.4-common

# Installierte Pakete aktualisieren (keine Neuinstallation)
sudo apt install --only-upgrade php8.4-fpm php8.4-cli php8.4-common

# FPM-Worker erneuern
sudo systemctl restart php8.4-fpm
systemctl status php8.4-fpm --no-pager

# Beispiel: Ubuntu-Pakete mit FPM
sudo apt update
apt-cache policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
sudo systemctl restart php8.3-fpm

# Installierte Paketversion kontrollieren
dpkg-query -W -f='${Package} ${Version}\n' php8.3-fpm php8.3-common

# Beispiel: separates Plesk-Binary prüfen
/opt/plesk/php/8.3/bin/php -v

# Systemweite FPM-Dienste erfassen
systemctl list-units --all --type=service | rg 'php.*fpm|plesk.*fpm'

# Aktuellen Dienst und Image prüfen
docker compose -f compose.yml ps
docker compose -f compose.yml images

# Korrigiertes Image laden und nur den PHP-Dienst neu erstellen
docker compose -f compose.yml pull php-web
docker compose -f compose.yml up -d --no-deps --force-recreate php-web

# Binary innerhalb der neuen Instanz prüfen
docker compose -f compose.yml exec php-web php -v

Übergangsmaßnahmen ohne sofortiges Update

Wenn das Update nicht sofort möglich ist, lässt sich die Exposition einzelner Pfade reduzieren. Für die bestätigten Session-Pfade nennt PHP:

; Vor Request-Parsing wirksam setzen, danach alle Worker neu starten
session.upload_progress.enabled = 0
; Zusätzlich für PHP 8.5
fatal_error_backtraces = 0

Geeignet sind php.ini oder passende Server-/FPM-Pool-Einstellungen. ini_set() im Anwendungscode und bei FPM eine .user.ini kommen für diese frühen Pfade zu spät.

Für den OOM-Pfad nennt PHP auch administrativ erzwungenes memory_limit=-1. Das entfernt die kontrollierbare PHP-Speichergrenze, lässt aber andere Allokationsfehler möglich. Gleichzeitig fällt eine normale Begrenzung des Speicherverbrauchs weg. Diese Maßnahme erfordert deshalb eine bewusste Prüfung von Isolation und Verfügbarkeit.

Request-Größe, Feldanzahl, Multipart-Teile, Header und Verschachtelung am Frontend begrenzen. Container-/cgroup-Limits können die Verfügbarkeit eingrenzen; RLIMIT_AS und RLIMIT_DATA sollen laut PHP nicht als Ersatz verwendet werden, weil sie gerade den verwundbaren Allokationsfehler auslösen können.

Maßnahmen und Grenzen: PHP Security Advisory — 21 October 2026 und CERT-EU Security Advisory 2026-018.

Nach dem PHP-Update

Nach dem Rollout sollte für jede Website feststehen, welcher korrigierte Build ihre Anfragen verarbeitet. Dabei vier Dinge getrennt prüfen:

• Paket oder Image: Vollständige Version beziehungsweise Digest gegen das Hersteller-Advisory abgleichen.
• Laufende Prozesse: Startzeiten kontrollieren; alte Worker dürfen keine Anfragen mehr bearbeiten.
• Web-Kontext: Tatsächlichen Handler und effektive Konfiguration über einen intern beschränkten Diagnoseweg prüfen.
• Anwendung: Login, Uploads, Hintergrundjobs und typische Requests testen.

# Beispiel nach einem FPM-Neustart
systemctl show php8.3-fpm -p ActiveEnterTimestamp -p MainPID
ps -eo user,pid,lstart,args | rg '[p]hp-fpm|[a]pache2|[h]ttpd'

Temporäre Einstellungen erst nach bestätigter Patch-Abdeckung kontrolliert auf die gewünschten Betriebswerte zurücksetzen. Das betrifft besonders ein zwischenzeitlich aufgehobenes memory_limit. Alte Images in Rollback- und Skalierungspfaden ebenfalls aktualisieren.

Angriffslage und Incident Response

Technisch nachgewiesene Ausnutzbarkeit, öffentliches Exploit-Konzept und bestätigte Kompromittierung im produktiven Betrieb sind unterschiedliche Aussagen. Dieser Beitrag leitet aus der Demonstration eines Exploits keine Zahl bereits übernommener Systeme ab.

Für die eigene Prüfung OOM-Ereignisse, Worker-Crashes und auffällige Multipart-Anfragen zeitlich mit neuen Dateien, Kindprozessen oder ausgehenden Verbindungen korrelieren. Einzelne Fehler sind kein Beweis für einen Angriff; unauffällige Logs sind ebenso wenig ein Beweis für Unversehrtheit. Bei konkretem Verdacht Artefakte sichern und Incident Response einleiten. Ein Update schließt die Lücke, entfernt aber keine bereits eingerichtete Persistenz.

Quellen & weiterführende Links

Stand: 21. Oktober 2026. Für spätere Updates die aktuellen Hersteller-Advisories und vollständigen Paketversionen prüfen.

• PHP Security Advisory — 21 October 2026
• GHSA-w8hw-w9fx-j79w — RCE via OOM corruption
• GHSA-6wmf-4rv5-p3rp — RCE via stale global state
• Ubuntu USN-8948-1
• Debian DSA-6574-1 — php8.4
• CERT-EU Security Advisory 2026-018