Status: Störung, laufend
Betroffen: Kunden-Webserver mit PHP, Shared Webspaces
Beginn: 21.10.2026, 15:35 Uhr
Voraussichtliches Ende: nach Einspielen der PHP-Patches
Worum es geht
In PHP gibt es zwei kritische Schwachstellen:
CVE-2026-109618 (CVSS 9.2)
CVE-2026-109619 (CVSS 9.2)
Angreifer könnten darüber aus der Ferne Schadcode auf Webservern ausführen. Sie bräuchten dafür weder eine Anmeldung noch ein Zutun eines Nutzers. Betroffen sind alle PHP-Versionen bis mindestens PHP 5. Das PHP-Projekt hat die Sicherheitsupdates am 21. Oktober um 16:00 Uhr veröffentlicht. Das BSI rechnet mit einer breiten Ausnutzung innerhalb weniger Stunden danach.
Updates
Nächstes Update: sobald die ersten Server wieder online sind.
Update 21.10.2026, 17:15 Uhr MESZ
Die Plesk-Update-Server sind weiterhin überlastet. php.net hat inzwischen bestätigt, dass auch für einige PHP-Versionen ohne regulären Support ein Update bereitgestellt wird: 7.4, 8.0 und 8.1. Dieses Update ist jedoch noch nicht über Plesk verfügbar. Da viele Inhalte weiterhin auf diese veralteten Versionen angewiesen sind, verzögert sich die Problemlösung weiter.
Update 21.10.2026, 16:30 Uhr MESZ
Die Plesk-Update-Server sind aktuell komplett überlastet und nur sporadisch erreichbar, weshalb sich das Ausrollen der Sicherheitsupdates weiter verzögert.
Update 21.10.2026, 16:15 Uhr MESZ
Zwischenzeitlich hat PHP erste Fixes zur Verfügung gestellt, die aktuell nach und nach ausgerollt werden. Auch seitens Plesk sind bereits erste Fixes verfügbar, allerdings noch nicht für alle PHP-Versionen. Zudem sind die meisten Update-Mirrors derzeit stark überlastet.
Auch die Plesk-Verwaltungsoberfläche selbst ist von der Sicherheitslücke betroffen. Dafür ist ein gesonderter Patch notwendig, der nach aktuellem Stand noch nicht verfügbar ist.
Update 21.10.2026, 16:10 Uhr MESZ
Das PHP-Projekt hat die Sicherheitsupdates veröffentlicht. PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 schließen beide Schwachstellen. Betroffen sind laut PHP-Team alle PHP-Installationen, die Webanfragen beantworten, darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Am größten ist das Risiko bei mod_php: Dort reicht eine einzige Anfrage ohne Anmeldung, noch bevor Code der Website ausgeführt wird.
Vollständig schützt nur das Update. PHP 8.1 und ältere Versionen bekommen vom PHP-Projekt keine regulären Updates mehr.
Wir spielen die Updates jetzt auf unseren Servern ein und prüfen jeden Server einzeln. Bis dahin bleiben Kunden-Webserver und Shared Webspaces offline. Der E-Mail-Empfang läuft weiter.
Update zur PHP-Bedrohungslage, 21.10.2026, 15:35 Uhr MESZ
Aufgrund der anhaltenden Bedrohungslage und in der Zwischenzeit bestätigten Angriffen auf Live-Systeme haben wir unsere Shared Webspaces vorübergehend deaktiviert. Derzeit liegt noch kein Patch des Herstellers vor, sodass keine alternative Lösung zur Absicherung der Systeme besteht. Die vorübergehende Deaktivierung ist daher aktuell der einzig sichere Weg, um die auf den Servern gespeicherten Kundendaten zu schützen.
Aus demselben Grund haben wir zeitgleich auch die Kunden-Webserver vorsorglich vom Netz genommen. Websites und Anwendungen auf diesen Servern sind bis auf Weiteres nicht erreichbar. Wir spielen die Patches ein, sobald sie erscheinen, prüfen jeden Server und schalten ihn danach wieder frei.
Der E-Mail-Empfang für Postfächer, die auf den Webspaces liegen, ist weiterhin gewährleistet.
Wir beobachten die Lage eng und reaktivieren die Webspaces, sobald der Patch verfügbar und die Sicherheit der Systeme wieder gewährleistet ist. Bei dringenden Anliegen sind wir per Ticket und Telefon für Sie erreichbar.
Update 21.10.2026, gegen 11:00 Uhr
Das BSI warnt mit Kritikalität 3 / Orange vor zwei Schwachstellen in PHP. Wir prüfen, welche Kunden-Webserver betroffen sind.
Technische Details
Für Administratoren, die es genau wissen wollen, hier die Angaben des PHP-Teams.
CVE-2026-109618: Was passiert technisch?
Remote-Code-Ausführung über einen Speicherfehler (Out of Memory). Stößt PHP an seine Speichergrenze, kann die Fehlerbehandlung PHP unterbrechen, während interne Anfragedaten erst teilweise angelegt sind. Das anschließende Aufräumen der Anfrage behandelt diese unvollständigen Daten dann als gültig. Ausführliche Beschreibung im GitHub-Advisory GHSA-w8hw-w9fx-j79w.
CVE-2026-109619: Was passiert technisch?
Remote-Code-Ausführung über veralteten globalen Zustand. Interner Zustand einer Anfrage kann erhalten bleiben, obwohl sein Speicher bereits freigegeben ist. Eine spätere Anfrage im selben Worker-Prozess kann diesen veralteten Zustand verwenden, bevor er regulär zurückgesetzt wird. Ausführliche Beschreibung im GitHub-Advisory GHSA-6wmf-4rv5-p3rp.
Was Administratoren tun können, wenn sie nicht sofort aktualisieren können
Nur das Update schützt vollständig. Die folgenden Maßnahmen des PHP-Teams verkleinern die Angriffsfläche, machen eine Installation aber nicht sicher. Gegen CVE-2026-109618: memory_limit=-1 so setzen, dass Anwendungen den Wert nicht überschreiben können, etwa per php_admin_value im FPM-Pool oder in der Apache-Konfiguration. post_max_size niedrig halten, 8M ohne Datei-Uploads, sonst 32M, und upload_max_filesize darunter. Größenlimits für Anfragen am Webserver oder Proxy durchsetzen und Container- oder cgroup-Limits nutzen, aber kein RLIMIT_AS oder RLIMIT_DATA. Gegen CVE-2026-109619: session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration setzen und alle Worker neu starten. ini_set() und .user.ini reichen dafür nicht. Unter PHP 8.5 zusätzlich fatal_error_backtraces=0. Für PHP 7.4, 8.0 und 8.1 stellt das PHP-Team minimale Backports als Quellcode bereit. Das Paket-Repository rpms.remirepo.net erhält heute keine Updates.