- Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Lücken geschlossen, CVE-2026-109618 und CVE-2026-109619, gemeinsam „PHP2Shell“ genannt. Beide erlauben Codeausführung aus der Ferne und sind mit CVSS 4.0 9.2 bewertet.
- Schon am Morgen, Stunden vor dem Patch, haben wir die Funktion abgeschaltet, über die die bekannten Angriffe laufen. Kurz vor der Veröffentlichung haben wir PHP vorsorglich ganz vom Netz genommen.
- Jedes System ging erst wieder online, als dort nachweislich die gepatchte Version lief. Das Plesk-Panel blieb aus, bis Plesk am Morgen des 22. Oktober ein eigenes Update geliefert hatte.
- Angriffsspuren haben wir nicht gefunden. Behauptungen, das Update reiche nicht aus, haben wir selbst nachgeprüft. Bestätigt hat sich keine davon.
Eine Lücke in PHP betrifft nicht eine Anwendung, sondern fast alle: WordPress, Nextcloud, Shops, Foren, Webmailer. Entsprechend schnell haben wir reagiert. Dieser Beitrag beschreibt, was wir wann getan haben und was wir dabei selbst geprüft haben.
Was die Lücken sind
Beide Fehler stecken im Kern von PHP und betreffen die Zeit zwischen zwei Anfragen. Ein PHP-FPM-Prozess bearbeitet nacheinander viele Anfragen. Zwischen ihnen muss er seinen Zustand vollständig aufräumen.
- CVE-2026-109618 (RCE via OOM corruption): Geht PHP der Speicher aus, bricht es die laufende Anfrage über einen Sprung ab. An manchen Stellen bleibt dabei Speicher in einem halb fertigen Zustand zurück, den das spätere Aufräumen dennoch liest. Laut Sicherheitshinweis des PHP-Projekts lässt sich das gezielt auslösen und bis zur Codeausführung treiben.
- CVE-2026-109619 (RCE via stale global state): Globale Zeiger verweisen kurzzeitig in den Speicher einer Anfrage. Werden sie nicht sauber zurückgesetzt, liest die nächste Anfrage bereits freigegebenen Speicher. Auch hier beschreibt der Hinweis des PHP-Projekts Codeausführung als Folge.
Behoben sind beide in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (Changelog von PHP 8). Der zentrale Fix trägt den Titel „Avoid state corruption via bailout“. Die CVE-Einträge: CVE-2026-109618 und CVE-2026-109619.
Der Ablauf mit Uhrzeiten
Das PHP-Projekt hatte am 20. Oktober angekündigt, dass am Folgetag ein Sicherheitsrelease für zwei kritische Lücken erscheint, geplant für 16:00 Uhr deutscher Zeit. Details gab es vorab nicht. Wir haben die Zeit bis dahin genutzt.
| Zeit (MESZ) | Was passiert ist |
|---|---|
| 21.10., ab 07:30 | Erste Schutzmaßnahme: session.upload_progress abgeschaltet, zuerst auf unserer Webseite, danach Schritt für Schritt im Webhosting, bei Nextcloud und den Mailservern. |
| 21.10., bis 14:00 | Firewall-Regel gegen den bekannten Angriffsweg im Webhosting eingerichtet und getestet. Alle Updates eingespielt, die schon verfügbar waren. |
| 21.10., 15:36 | PHP veröffentlicht die gepatchten Versionen, früher als angekündigt. |
| 21.10., 15:37 | Wir nehmen PHP auf unseren Systemen vorsorglich vom Netz. Geplant war das für 15:45. Nach der Veröffentlichung eines Patches beginnen erfahrungsgemäß sofort die Massenscans. |
| 21.10., 16:03 | Unsere Webseite läuft wieder, mit gepatchtem PHP. |
| 21.10., 16:22–16:46 | Mailserver, Webhosting, Nextcloud und die meisten Anwendungen sind wieder online, jeweils erst nach Prüfung der laufenden Version. |
| 21.10., gegen 17:45 | Nahezu alle übrigen Anwendungen sind wieder online, nachdem ihre Images neu gebaut waren. |
| 22.10., 01:56 | Plesk stellt Version 18.0.81.4 mit gepatchtem Panel-PHP bereit. |
| 22.10., 06:36 | Nach eigener Prüfung schalten wir das Plesk-Panel wieder ein. |
Für die meisten Dienste bedeutete das eine Unterbrechung zwischen einer halben und einer ganzen Stunde. Wir haben das bewusst in Kauf genommen: Nach unserer Regel geht kein System ohne nachweislich gepatchtes PHP wieder online.
Was wir getan haben
Nach dem Release haben wir alle PHP-Installationen in unserer Verantwortung aktualisiert: das Webhosting unter Plesk und KeyHelp, die Nextcloud-Instanzen, die Webmailer der Mailserver, unsere eigene Webseite und interne Anwendungen. Auch die älteren PHP-Versionen 7.4, 8.0 und 8.1, die Plesk noch mitliefert, haben die zugehörigen Updates erhalten.
Ein Update allein reichte uns nicht. Deshalb gelten zusätzlich drei Schutzschichten:
session.upload_progressist überall aus und gesperrt. Die öffentlich beschriebenen Angriffsketten nutzen diese Funktion, um Daten in die Sitzung zu schreiben. Wir haben sie serverweit abgeschaltet und mitphp_admin_flagso festgesetzt, dass weder eine.user.ininoch eine Domain-Einstellung sie wieder einschalten kann.- PHP-Prozesse werden regelmäßig erneuert. Mit
pm.max_requests = 500beendet sich jeder Prozess nach spätestens 500 Anfragen. Zustand, der zwischen Anfragen hängen bleibt, lebt damit nicht beliebig lange. - Die Web Application Firewall blockt den Angriffsweg. Eigene ModSecurity-Regeln weisen Anfragen ab, die das Feld
PHP_SESSION_UPLOAD_PROGRESSmitschicken, auch in einer Variante mit verschleiertem Content-Type.
Dazu kommt eine Überwachung, die alle zehn Minuten nach PHP-Abstürzen sucht, nach Shells, die ein Web-PHP-Prozess startet, und nach Konfigurationen, die upload_progress wieder einschalten.
Warum das Plesk-Panel offline war
Die Verwaltungsoberfläche von Plesk läuft nicht mit dem PHP der Webseiten, sondern mit einer eigenen, fest eingebauten PHP-Version. Bei uns war das am 21. Oktober PHP 8.4.25, also ungepatcht, mit eingeschaltetem upload_progress und von außen erreichbar. Selbst austauschen lässt sich dieses PHP nicht.
Wir haben das Panel deshalb abgeschaltet, bis Plesk ein Update liefert. Das kam mit Plesk 18.0.81.4 am Morgen des 22. Oktober. Vor dem Wiedereinschalten haben wir geprüft, dass das Panel tatsächlich mit PHP 8.4.27 läuft, und upload_progress auch dort zusätzlich abgeschaltet. Die Webseiten selbst liefen in dieser Zeit normal, nur die Anmeldung im Panel war nicht möglich.
Was wir selbst überprüft haben
Schon am Abend des 21. Oktober kursierten in sozialen Netzwerken und auf GitHub Behauptungen, das Update helfe nicht oder es gebe bereits Umgehungen. Wir haben uns auf keine davon verlassen, sondern jede selbst nachgeprüft.
- Laufende Version statt Paketliste: Eine installierte Version sagt nichts darüber, was ein laufender Prozess wirklich ausführt. Wir haben jeden PHP-Pool direkt abgefragt, welche Version er meldet und ob
upload_progressaus ist. Dabei fiel etwa auf, dass auf einem System das PHP der Webseiten aktuell war, das der Kommandozeile aber nicht. - Der Fix selbst: Wir haben verglichen, ob die veröffentlichten Versionen den zentralen Fix tatsächlich enthalten. Die betroffenen Quelldateien sind in allen vier Release-Zweigen identisch gepatcht.
- Eigener Labortest: Auf einem gepatchten PHP 8.4.27 landet bei eingeschaltetem
upload_progressein vom Angreifer gewählter Dateiname in der Sitzungsdatei. Mit ausgeschalteter Funktion entsteht gar keine Sitzungsdatei. Genau dieser Schritt fehlt den bekannten Angriffsketten dann.
Die unbestätigten Behauptungen
- „Restketten“ nach dem Patch: Mehrere öffentliche Repositorys zeigen angebliche Angriffe gegen gepatchtes PHP. Wir haben den Code gelesen. Jede dieser Ketten setzt mindestens eines voraus: eingeschaltetes
upload_progress, eine noch ungepatchte Version wie 8.4.26 oder eine zusätzliche Schwachstelle in der Anwendung selbst, etwa unsicheresunserialize(). Gegen unsere Konfiguration greift keine davon. - Ein „Nachbesserungs“-Patch: Ein Pull Request im PHP-Repository versprach zusätzliche Härtung gegen beide Lücken. Er wurde noch am selben Abend geschlossen und nicht übernommen. Ein weiterer, älterer Vorschlag zur Sitzungsbehandlung ist offen, spielt aber bei ausgeschaltetem
upload_progresskeine Rolle. - Exploit-Archive: Teilweise wurden „scharfe“ Exploits zum Herunterladen angeboten, unverschlüsselt und von zweifelhafter Herkunft. Solche Archive enthalten bei Lücken dieser Größe oft selbst Schadsoftware. Wir haben sie nicht heruntergeladen und keinen fremden Exploit-Code auf unseren Servern ausgeführt.
Angriffsspuren
Wir haben Zugriffs-, Fehler- und Firewall-Protokolle nach den bekannten Mustern durchsucht. Gefunden haben wir Scans. Am 21. Oktober um 16:22 Uhr schickte zum Beispiel ein Scanner, der sich selbst als PHP2Shell-Scanner auswies, eine präparierte Anfrage an unser Webhosting. Die Firewall hat sie blockiert, und das PHP dahinter war zu diesem Zeitpunkt bereits gepatcht. Hinweise auf eine erfolgreiche Ausnutzung haben wir nicht gefunden.
Was noch offen ist
Die neuen Versionen 8.4.27 und 8.5.12 bringen einen eigenen Fehler mit: In bestimmten Fällen kann die SimpleXML-Erweiterung abstürzen (GH-24488). Eine Korrektur ist in Arbeit. Bei uns ist der Absturz bisher nicht aufgetreten. Unsere Überwachung achtet darauf, und wir spielen die Folgeversionen ein, sobald sie erscheinen.
Was das für dich bedeutet
Webhosting, Nextcloud und Mail: Du musst nichts tun. Die Updates und die Härtung sind eingespielt. Eine Ausnahme: Falls deine Anwendung einen Upload-Fortschrittsbalken über session.upload_progress nutzt, zeigt er jetzt keinen Fortschritt mehr an. Der Upload selbst funktioniert weiter.
Eigener vServer oder Rootserver: Hier bist du selbst zuständig. Prüfe den laufenden PHP-FPM-Dienst, nicht nur php -v auf der Kommandozeile. Mindestens nötig sind 8.2.35, 8.3.36, 8.4.27 oder 8.5.12. Starte PHP-FPM danach neu und setze session.upload_progress.enabled = Off. Wer Plesk oder ein anderes Panel mit eigenem PHP betreibt, braucht zusätzlich das Update des Panel-Herstellers.
Fragen zu deinem Server beantworten wir gern über unser Ticketsystem.
