Kritische Sicherheitslücken in PHP (CVE-2026-109618 und CVE-2026-109619): was wir getan haben

Am 21. Oktober hat das PHP-Team die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht, die zwei als PHP2Shell bekannte kritische Sicherheitslücken schließen: CVE-2026-109618 und CVE-2026-109619, beide mit einer Bewertung von 9,2 von 10. Sie erlauben es, mit einer einfachen Anfrage an die Website Code auf einem Server auszuführen, ohne Benutzername oder Passwort, und betreffen praktisch jede PHP-Installation, ganz gleich mit welcher Anwendung: WordPress, PrestaShop, Laravel oder eine selbst programmierte Website.

Sie müssen nichts tun: Alle PHP-Versionen auf unseren Servern, von 5.2 bis 8.5, sind seit den frühen Morgenstunden des 22. Oktober korrigiert.

Am 23. Oktober hat PHP vor einem dritten Weg gewarnt, CVE-2026-115560, für den es noch keine Korrektur gibt. Auf unseren Servern war er bereits seit dem 21. geschlossen: Wir erklären es weiter unten.

Wenn Ihre Website PHP 8.2, 8.3, 8.4 oder 8.5 verwendet, sehen Sie dieselbe Nummer, die PHP veröffentlicht hat, zum Beispiel 8.5.12. Bei einer älteren Version sehen Sie die gewohnte, zum Beispiel 7.4.33, und das ist normal: PHP veröffentlicht für diese Zweige keine neuen Versionen, und CloudLinux, das die von uns verwendeten PHP-Versionen pflegt, baut die Korrektur dort ein, ohne die Nummer zu ändern. Die Tabelle weiter unten zeigt die korrigierte Version jedes Zweigs. Wir erklären, was wir getan haben.

Bevor die Korrektur erschien

PHP hatte am Vortag angekündigt, die Korrektur am 21. um 16:00 Uhr spanischer Zeit zu veröffentlichen, und die Details sind vorzeitig durchgesickert. Wir haben nicht auf den Patch gewartet: Wir verfolgen Sicherheitshinweise über alle Kanäle, nicht nur über die offiziellen, und sobald die ersten inoffiziellen Berichte kursierten:

• Haben wir auf allen Servern die PHP-Funktion deaktiviert, über die der bestätigte Teil des Angriffs eindrang: die Fortschrittsverfolgung von Datei-Uploads in der Session. Das haben wir in allen PHP-Versionen getan, die wir anbieten, von 5.2 bis 8.5, und Konto für Konto geprüft, dass sie deaktiviert war.
• Haben wir der Web Application Firewall aller Server eigene Regeln hinzugefügt, die bekannte Angriffsversuche abweisen, bevor sie PHP erreichen. Dazu kommen die Regeln, die CloudLinux in Imunify360 ausgerollt hat.

Keine dieser Maßnahmen ändert etwas an Ihrer Website. Das Einzige, was nicht mehr funktioniert, ist der Fortschrittsbalken von Anwendungen, die ihn mit dieser PHP-Funktion berechnet haben, was sehr selten ist: Die meisten berechnen ihn im Browser.

Diese Maßnahmen verringern das Risiko, ersetzen das Update aber nicht. Das sagt auch das PHP-Team selbst, und deshalb haben wir es eingespielt, sobald es verfügbar war.

Das Update

Unsere Server verwenden die PHP-Versionen, die CloudLinux pflegt. Wir haben die korrigierten Versionen eingespielt, sobald sie erschienen sind, und seit den frühen Morgenstunden des 22. Oktober ist die Korrektur auf allen Servern in allen Versionen installiert, die wir anbieten: von 5.2 bis 8.5.

Von 8.2 bis 8.5 ist die Nummer jetzt die, die PHP mit der Korrektur veröffentlicht hat: zum Beispiel 8.5.12. In den älteren Versionen baut CloudLinux die Korrektur ein, ohne die Versionsnummer zu ändern, deshalb zeigt PHP weiterhin die gewohnte an: zum Beispiel 7.4.33.

Für 8.2, 8.3, 8.4 und 8.5 hat CloudLinux die Korrektur zunächst ohne neue Nummer veröffentlicht, und diese Pakete haben wir am 21. und 22. installiert: Wenn Sie an diesen Tagen 8.5.11 auf Ihrer Website gesehen haben, war sie bereits korrigiert. Danach hat CloudLinux dieselben Korrekturen mit den Nummern von PHP veröffentlicht, und auch diese haben wir installiert: Sie ändern die Nummer, nicht den Schutz, der bereits seit dem 22. bestand. In den Worten von CloudLinux: „If you have already installed the fixed packages from our earlier updates (for example alt-php85 8.5.11-5), your servers are already protected against CVE-2026-109618 and CVE-2026-109619. This update only brings the version numbers in line with PHP.net“. Das heißt: Wer die früheren Pakete wie 8.5.11-5 bereits hatte, war geschützt, und die neuen gleichen nur die Nummer an die von PHP an. CloudLinux erklärt das in seinem Hinweis zu diesen Sicherheitslücken.

Für das Update mussten Sie nichts tun, und der Dienst wurde dabei nicht unterbrochen.

Der Hinweis vom 23. Oktober: CVE-2026-115560

Am 23. Oktober hat das PHP-Team vor einem weiteren Weg gewarnt, Code auf dem Server auszuführen: CVE-2026-115560. Die Versionen vom 21. beheben ihn nicht: Die Korrektur kommt mit der nächsten PHP-Version. Es ist ein anderer Weg, und was diese Versionen korrigieren, CVE-2026-109618 und CVE-2026-109619, bleibt korrigiert.

Ausnutzen lässt er sich nur in einer ungewöhnlichen Kombination: Die Anwendung ändert in ihrem eigenen Code das Format, in dem PHP die Session speichert, und zusätzlich ist die Fortschrittsverfolgung von Datei-Uploads in der Session aktiviert. Bis die Korrektur kommt, empfiehlt PHP, diese Funktion zu deaktivieren, und stellt klar, dass wer das bereits nach dem Hinweis vom 21. getan hat, nichts weiter tun muss.

Das ist bei uns der Fall: Es ist dieselbe Funktion, die wir am 21. Oktober auf allen Servern und in allen PHP-Versionen von 5.2 bis 8.5 deaktiviert haben, und sie ist weiterhin deaktiviert. Die Regeln der Web Application Firewall, die wir an diesem Tag hinzugefügt haben, weisen außerdem Anfragen ab, die sie zu nutzen versuchen, bevor sie PHP erreichen. Sie müssen nichts tun. Sobald PHP und CloudLinux die Korrektur veröffentlichen, spielen wir sie genauso ein wie diese.

Und wenn meine Website eine ältere PHP-Version verwendet?

Das PHP-Projekt korrigiert nur die Versionen, die es selbst pflegt: ab 8.2. Für 8.1, 7.x und 5.x veröffentlicht es keine neuen Versionen. Bei den meisten Hostern bleibt eine Website mit PHP 7.4 heute ungeschützt.

Bei Hostsuar nicht. CloudLinux pflegt Sicherheitspatches für alle Versionen, die wir anbieten, von 5.2 bis 8.5, und hat diese beiden Sicherheitslücken auch in den älteren geschlossen. Die Korrektur ist dort bereits installiert, genauso wie in den übrigen: Ihre Website ist geschützt, ohne dass Sie die Version wechseln.

Die von Ihnen genutzte Version aktuell zu halten, ist unsere Aufgabe, deshalb müssen Sie wegen dieser Sicherheitslücken die PHP-Version nicht wechseln. Wenn Sie eines Tages auf eine neuere umsteigen möchten, wegen der Leistung oder weil ein neues Plugin es verlangt, finden Sie die verfügbaren Versionen unter Verfügbare PHP-Versionen in allen Hosting-Diensten und können die Ihrer Website unter PHP-Version einer Website mit Prüfung und Rückkehrmöglichkeit ändern ändern: Wir prüfen, ob die Website mit der neuen Version weiterhin antwortet, und wenn nicht, kehrt sie zur vorherigen zurück. Wenn Ihre Website Anpassungen braucht, um mit einer aktuellen Version zu funktionieren, schreiben Sie uns und wir sehen es uns an.

Wenn Sie PHP woanders betreiben

Wenn Sie selbst einen Server mit PHP außerhalb von Hostsuar verwalten, aktualisieren Sie ihn auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder installieren Sie das korrigierte Paket Ihrer Distribution, und starten Sie PHP neu. Für CVE-2026-115560 setzen Sie außerdem vor dem Neustart session.upload_progress.enabled = 0 in der php.ini oder in der Konfiguration von PHP-FPM: Mit ini_set() aus der Anwendung heraus wirkt es nicht. Wenn Sie Fragen dazu haben, schreiben Sie uns.