PHP-Notfallupdate: 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen kritische RCE-Lücken, erste Angriffsversuche gemeldet

Das PHP-Projekt hat am 21. Oktober 2026 die angekündigten Notfallupdates veröffentlicht: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen zwei kritische Schwachstellen (CVE-2026-109618 und CVE-2026-109619, je CVSS v4.0 9.2), die laut PHP eine Remote Code Execution ohne Anmeldung ermöglichen können. Betroffen ist jede PHP-Installation, die Webanfragen verarbeitet, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Admins sollten heute patchen, Sicherheitsfirmen melden erste Angriffsversuche. Nicht betroffen sind Systeme ohne PHP; reine CLI-Skripte nennt PHP nicht als Risikogruppe.

Stand: 21.10.2026, 20:45 Uhr. Updates erschienen, Debian, Ubuntu und Docker Hub liefern korrigierte Pakete und Images, auch der Tag latest. watchTowr und Cloudflare berichten von ersten Angriffsversuchen, ein CISA-KEV-Eintrag fehlt noch. Die GitHub-Advisories sind seit 13:34 UTC öffentlich, die CVE-Einträge in der NVD seit 14:17 UTC.

Liveticker

• 21.10., 20:45 Uhr: Sicherheitsfirmen melden erste Angriffe. watchTowr beobachtet laut eigener FAQ seit dem 21. Oktober Ausnutzungsversuche gegen beide Lücken in seinem Honeypot-Netz und hat beide Schwachstellen nach eigenen Angaben nachgestellt (watchTowr). Cloudflare-CTO Dane Knecht schrieb, man sehe erste Angriffe, und hat WAF-Regeln für alle Kunden ausgerollt, ausdrücklich nur als Notbehelf (Cloudflare). Tenable fasst beide Angaben zusammen (Tenable). Eine unabhängige Bestätigung durch BSI oder CISA steht aus, der KEV-Katalog listet die CVEs weiterhin nicht.
• 21.10., 20:45 Uhr: Auf Docker Hub liefert jetzt auch der Tag latest PHP 8.5.12 aus (geprüft über das Registry-Manifest).
• 21.10., 18:45 Uhr: Das BSI stuft die Lage in seinem Sicherheitshinweis (Version 1.1) mit Kritikalität 3 von 4 ein, nennt einen öffentlichen Proof of Concept und hält eine kurzfristige Ausnutzung für wahrscheinlich. Bestätigte Angriffe kennt das BSI nicht, Berichte über Angriffsversuche in sozialen Medien seien unbestätigt. Wer nicht sofort patchen kann, soll eine vorübergehende Trennung vom Internet erwägen (BSI).
• 21.10., 18:45 Uhr: Ein Eintrag im CISA-Katalog KEV fehlt bisher. Cisco Talos hat bis 14:00 UTC keine Ausnutzung beobachtet (Talos). Laut PHP Foundation kursieren seit einem versehentlich veröffentlichten Video der Entdecker mehrere PoCs, funktionsfähige Exploits habe das Sicherheitsteam bis zur Veröffentlichung aber nicht gefunden (PHP Foundation).
• 21.10., 18:45 Uhr: Ubuntu stuft beide CVEs als „Critical“ ein und hat mit USN-8948-1 und -2 korrigierte Pakete veröffentlicht, darunter php8.1 8.1.2-1ubuntu2.28 (22.04), php8.3 8.3.6-0ubuntu0.24.04.13 (24.04) und php8.5 8.5.4-0ubuntu1.5 (26.04) (Ubuntu). Debian liefert php8.4 8.4.27-1~deb13u1 für Trixie (DSA-6574-1) und php8.2 8.2.35-1~deb12u1 für Bookworm (DLA-4848-1); Forky und Sid sind noch offen (Debian).
• 21.10., 18:45 Uhr: Auf Docker Hub stehen die Tags 8.5.12, 8.4.27, 8.3.36 und 8.2.35 von library/php seit 17:40 bis 18:35 Uhr bereit. 8.4-fpm zeigt auf 8.4.27, 8-apache auf 8.5.12. latest zog etwas später nach (Docker Hub).

Was ist passiert?

Am 20. Oktober hatte das PHP-Sicherheitsteam das Update für 14:00 UTC angekündigt. Mit den Releases folgte das Advisory „Critical remote code execution vulnerabilities, update now“. Die beiden Lücken laut PHP:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w), „RCE via OOM corruption“: Ein Speicherüberlauf (Out of Memory) unterbricht PHP, während interne Anfragedaten nur teilweise initialisiert sind. Das Aufräumen der Anfrage behandelt diese Daten danach als gültig. Auslösen lässt sich das unter anderem über präparierte Multipart-Anfragen.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), „RCE via stale global state“: Interner Zustand einer Anfrage überlebt die Freigabe seines Speichers. Eine spätere Anfrage an denselben Worker greift darauf zu (Use after free).

Was gesichert ist und was nicht

Offiziell bestätigt sind inzwischen die CVE-Nummern, die watchTowr vorab genannt hatte, sowie die Einstufung als Remote Code Execution. Laut Advisory wurde für CVE-2026-109618 eine vollständige Codeausführung über HTTP gegen mod_php mit Standardlimits nachgewiesen, und zwar bevor Anwendungscode läuft. Für CVE-2026-109619 nennt PHP bestätigte Codeausführung gegen mod_php und über den Session-Pfad auch gegen FPM. Für FPM bei CVE-2026-109618 gibt es laut Advisory noch keinen vollständigen Exploit, der Quellcode spricht aber für Anfälligkeit.

Nicht bestätigt bleiben die von watchTowr genannte Bewertung mit CVSS 10 (offiziell 9.2) und die Betroffenheit von PHP 5 und 6. Zu Angriffen in freier Wildbahn macht PHP keine Angabe. watchTowr und Cloudflare melden erste Angriffsversuche, das BSI kannte in seinem Hinweis noch keine bestätigte Ausnutzung, öffentliche PoCs gibt es.

Wer ist betroffen?

• PHP 8.5 vor 8.5.12, korrigiert in 8.5.12
• PHP 8.4 vor 8.4.27, korrigiert in 8.4.27
• PHP 8.3 vor 8.3.36, korrigiert in 8.3.36
• PHP 8.2 vor 8.2.35, korrigiert in 8.2.35

PHP 8.1 und älter erhalten vom Projekt keine Releases mehr. Wegen der Schwere hat das Sicherheitsteam aber minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt. Distributionen und LTS-Anbieter hatten die Patches vorab. Das Fremd-Repository rpms.remirepo.net erhält laut PHP heute keine Updates. Auf Docker Hub stehen die korrigierten Versions-Tags von library/php seit dem frühen Abend bereit.

Wie kritisch ist das?

Akut kritisch für öffentlich erreichbare PHP-Anwendungen. Der Angriffspfad ist eine präparierte HTTP-Anfrage ohne Anmeldung, die Codeausführung mit den Rechten des Webserver-Workers ermöglicht. Das höchste Risiko sieht PHP bei mod_php. Die technischen Details sind öffentlich, und laut watchTowr und Cloudflare laufen bereits erste Angriffsversuche. Ungepatchte, öffentlich erreichbare Systeme sollten deshalb noch heute aktualisiert oder vorübergehend vom Netz genommen werden.

Was Admins jetzt tun sollten

• Version prüfen: php -v auf der Kommandozeile reicht nicht, die Version von FPM oder mod_php zusätzlich etwa per php-fpm -v (Binärname je nach Distribution versioniert) oder über die Paketverwaltung abgleichen, auch in Containern und Hosting-Panels.
• Distributionspakete einspielen, sobald der Hersteller sie bereitstellt, und dessen Security-Tracker beobachten; Distributionen patchen oft ohne neue Upstream-Versionsnummer.
• Docker-Images neu ziehen und neu bauen, danach Container neu erstellen. Am besten feste Tags wie 8.4.27 nutzen und die Version im Container prüfen, weil Sammel-Tags zeitversetzt nachziehen.
• PHP-FPM, Apache und alle Worker neu starten, damit keine alten Prozesse weiterlaufen.
• Öffentlich erreichbare Systeme mit mod_php zuerst patchen.
• Wer nicht sofort aktualisieren kann: PHP nennt Übergangsmaßnahmen wie memory_limit=-1 per php_admin_value, ein niedriges post_max_size und session.upload_progress.enabled=0. Diese senken das Risiko nur für einzelne Pfade und machen eine Installation laut PHP nicht sicher.
• Installationen mit PHP 8.1 oder älter auf einen unterstützten Zweig migrieren oder beim LTS-Anbieter nach Backports fragen.

Einordnung

Die vorab durchgesickerten Angaben haben sich in den Kernpunkten bestätigt. Für kleine Unternehmen und Hoster zählt jetzt Tempo: WordPress, Nextcloud und Shopsysteme laufen fast immer auf einem der betroffenen Zweige. Wer seine PHP-Version nicht selbst verwaltet, sollte beim Hoster nachfragen, ob die Updates eingespielt sind.

Passende Anleitungen auf S-EDV

• PHP-Version unter WordPress aktualisieren und Kompatibilität prüfen: hilfreich, wenn das Update einen Versionssprung erfordert.
• KeyHelp: PHP-Versionen für viele Kunden auf einmal umstellen: für Hosting-Server mit vielen Kundenkonten.

Quellen

• watchTowr: FAQ zu CVE-2026-109618 und CVE-2026-109619 (aktualisiert 21.10.2026)
• Dane Knecht (Cloudflare) zu WAF-Regeln und ersten Angriffen (21.10.2026)
• Tenable: FAQ zu php2shell (aktualisiert 21.10.2026)
• BSI: Sicherheitshinweis PHP, Version 1.1 (21.10.2026)
• PHP Foundation: Hintergrund zum Sicherheitsrelease
• Cisco Talos: Zwei kritische RCE-Lücken im PHP-Kern
• Debian Security Tracker: CVE-2026-109618
• Ubuntu: CVE-2026-109618
• Docker Hub: offizielles PHP-Image
• php.net: Security advisory zu den kritischen RCE-Lücken (21.10.2026)
• GitHub Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NVD: CVE-2026-109618
• NVD: CVE-2026-109619
• php.net: ChangeLog PHP 8
• php.net: Upcoming Critical PHP Security Release (20.10.2026)
• BleepingComputer: PHP warns admins of two critical flaws
• LWN.net: Critical PHP security update coming