PHP2Shell: Dritte Lücke ohne Notfall-Patch, eine Einstellung schützt
25. Oktober 2026
KI-generiert, redaktionell von 8thsense ausgewählt, geprüft und freigegeben. EU AI Act, Art. 50
Kaum waren die Notfall-Updates gegen die kritischen PHP2Shell-Lücken draußen, hat das PHP-Projekt am 23. Oktober eine dritte Schwachstelle gemeldet: CVE-2026-115560. Anders als bei den ersten beiden gibt es diesmal keinen sofortigen Patch, die Korrektur kommt erst mit dem nächsten regulären Release. Bis dahin empfehlen die Entwickler, eine einzelne Funktion in der PHP-Konfiguration abzuschalten. Für Geschäftsführer mit WordPress-Website, Onlineshop oder Buchungsportal heißt das: Das Update der Vorwoche allein reicht nicht, auch die Serverkonfiguration muss stimmen.
Was das PHP-Projekt gemeldet hat
Auf php.net steht seit dem 23. Oktober ein „Informational advisory” zur Funktion Session Upload Progress. Die Empfehlung im Wortlaut: session.upload_progress.enabled=0 setzen, bis das nächste reguläre Bugfix-Release erscheint, um sich vollständig vor einem „unwahrscheinlichen RCE-Vektor” zu schützen, also vor dem Einschleusen und Ausführen von fremdem Code (Quelle: php.net). Weil diese Konstellation in der Praxis selten sei, behandle man sie im regulären Release-Zyklus und veröffentliche die vollständige Sicherheitsmeldung erst mit der nächsten Version. Wichtig: Die am 21. Oktober veröffentlichten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 beheben diese dritte Lücke nicht (Quelle: thehackernews.com). Welche Versionen betroffen sind, wie schwer die Lücke eingestuft wird und wann genau der Fix kommt, hat PHP bisher nicht gesagt.
Wann eine Website wirklich gefährdet ist
Laut PHP müssen mehrere Bedingungen zusammenkommen, damit die Lücke ausnutzbar ist:
Die Anwendung stellt in der Konfiguration den Session-Serializer auf php_binary oder php_serialize ein.
Zur Laufzeit wechselt sie per ini_set() auf den Serializer php, und zwar vor dem Start der Sitzung.
Die Funktion Session Upload Progress ist aktiv. Das ist in der Standardkonfiguration der Fall.
Elizabeth Barron, Geschäftsführerin der PHP Foundation, sagte gegenüber The Register, der Fehler erfordere „eine sehr unwahrscheinliche Kombination aus Konfiguration und spezifischem Anwendungscode” (Quelle: theregister.com). Ausnutzungen dieser dritten Lücke sind bisher nicht bekannt. Das Problem für Unternehmen: Ob ein Plugin, ein Theme oder eine ältere Eigenentwicklung genau dieses Muster verwendet, weiß kaum ein Geschäftsführer, und oft auch nicht der Hoster.
Die ersten beiden Lücken werden bereits angegriffen
Ruhe ist trotzdem nicht angebracht, denn die Lage rund um die ersten beiden Lücken (CVE-2026-109618 und CVE-2026-109619) ist ernst. Laut The Hacker News verzeichneten Amazons Honeypots bereits am 17. Oktober, vier Tage vor der Veröffentlichung, einen Angriffsversuch. Cloudflare meldete Angriffsversuche, die von Zehntausenden in den ersten 45 Minuten nach Bekanntgabe auf Millionen am Folgetag stiegen. Sophos und Arctic Wolf beobachteten Versuche, eine Variante des Mirai-Botnetzes zu installieren. Bei der Frage, ob Angriffe schon erfolgreich waren, gehen die Einschätzungen auseinander: Während Barron laut The Register keine Belege für erfolgreiche Ausnutzung vor der Veröffentlichung sieht, schreibt Mandiant-CTO Charles Carmakal, die Ausnutzung habe „möglicherweise bereits in begrenztem Umfang begonnen”. Viele öffentliche Angriffscodes seien zwar „vibe-coded” und funktionierten nicht, einige hat Mandiant aber gegen Standardinstallationen mit mod_php erfolgreich getestet, nicht jedoch gegen PHP-FPM.
Warum die Einstellung kaum Nebenwirkungen hat
Die gute Nachricht: Die empfohlene Einstellung ist nicht neu. PHP hatte sie bereits am 21. Oktober als Gegenmaßnahme für CVE-2026-109619 aufgeführt. Wer sie damals gesetzt hat, muss laut PHP nichts weiter tun. Session Upload Progress dient dazu, den Fortschritt von Datei-Uploads serverseitig abzufragen, etwa für einen Ladebalken. Viele Websites nutzen das gar nicht, moderne Upload-Formulare messen den Fortschritt meist im Browser. Trotzdem gilt: Vor dem Abschalten kurz prüfen, ob ein Bewerberportal, ein Kundenbereich mit Dokumenten-Upload oder ein Shop-Backend darauf angewiesen ist. Die Einstellung ersetzt außerdem kein Update. Die Patches vom 21. Oktober bleiben Pflicht, die Konfiguration kommt obendrauf.
Was das für Unternehmen bedeutet
PHP läuft laut netzpolitik.org auf fast 70 Prozent der Websites mit bekannter Servertechnik, darunter WordPress und TYPO3 (Quelle: netzpolitik.org). Die Tanzschule mit Online-Anmeldung, der Pflegedienst mit Bewerberformular und der Handwerksbetrieb mit WordPress-Seite sind also gleichermaßen betroffen. Die konkrete Aufgabe für diese Woche: Fragen Sie Ihren Hoster oder Webdienstleister schriftlich nach drei Punkten. Erstens, welche PHP-Version läuft und ob sie mindestens dem Stand vom 21. Oktober entspricht. Zweitens, ob session.upload_progress.enabled auf 0 steht. Drittens, wer das nächste reguläre PHP-Release einspielt und bis wann. Bei Shared Hosting lässt sich die Einstellung oft selbst über das Kundenmenü oder eine .user.ini setzen, bei eigenen Servern liegt sie ohnehin in Ihrer Verantwortung.
Die größere Lehre: Automatische Updates decken nur einen Teil ab. Sicherheitslücken, die mit KI-Unterstützung in hohem Tempo gefunden werden, landen immer häufiger als Mischung aus Patch, Konfigurationshinweis und Nachmeldung beim Betreiber. Wer dann nicht weiß, wer im Team oder beim Dienstleister zuständig ist, verliert Tage. Sinnvoll ist ein fester Ablauf mit klarer Verantwortung, ergänzt um einfache Workflow-Automation, die Sicherheitsmeldungen mit den eigenen Systemen abgleicht und gezielt die richtige Person informiert. Entscheidend ist dabei weniger das Werkzeug als jemand, der die eigene Serverlandschaft kennt und Hinweise wie diesen in konkrete Schritte übersetzt.