Wenn Sie die Website Ihres Unternehmens nach der PHP2Shell-Lücke auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 aktualisiert haben, war das richtig, deckt aber nicht alles ab. Am 23. Oktober 2026 veröffentlichte das PHP-Projekt eine neue Warnung zu einer dritten Lücke, CVE-2026-115560, die das Update vom 21. Oktober nicht behebt. Sie setzt eine ungewöhnliche Konfiguration voraus, und PHP stuft sie als unwahrscheinlichen Angriffsweg ein, doch die vorübergehende Lösung ist einfach: Bitten Sie Ihr Team oder Ihren Hoster heute, session.upload_progress.enabled auf 0 zu setzen und PHP neu zu starten, und lassen Sie sich danach schriftlich bestätigen, dass das Update vom 21. Oktober wirklich eingespielt wurde.

Was hat PHP am 23. Oktober angekündigt?

Zwei Tage nach dem Notfall-Release veröffentlichte das Projekt eine kurze Informationsmeldung zur Anzeige des «Upload-Fortschritts» in Sessions, also der Funktion, die Nutzern zeigt, wie weit das Hochladen einer großen Datei ist. Laut Meldung kann diese Funktion in einem bestimmten Fall einen Weg zur Ausführung von Code aus der Ferne öffnen. Die Korrektur soll mit dem nächsten regulären Release kommen, nicht als Notfall-Update, zusammen mit einer vollständigen Sicherheitsmeldung zur Lücke.

Für Unternehmer zählen zwei Punkte. Erstens ist das eine eigene Lücke, eine der vier genannten Versionen allein genügt also nicht. Zweitens stand dieselbe vorübergehende Maßnahme bereits in der Sicherheitsmeldung zu CVE-2026-109619 vom 21. Oktober. Hat Ihr Team sie damals umgesetzt, ist nichts Neues nötig: Lassen Sie sie bestehen.

Ist Ihre Website betroffen?

Laut der PHP-Warnung tritt das Problem nur auf, wenn drei Bedingungen zusammenkommen:

  • Die PHP-Konfiguration setzt session.serialize_handler auf php_binary oder php_serialize.
  • Der Anwendungscode stellt ihn zur Laufzeit mit ini_set() vor dem Start der Session auf php um.
  • Die Upload-Fortschrittsanzeige für Sessions ist weiterhin aktiv, was standardmäßig der Fall ist.

Die meisten Websites tun das nicht. Das Problem: Ein Inhaber weiß selten, was jede Zeile in einem vor Jahren gebauten System oder in einem alten Plugin tut. Die sicherste Wahl lautet daher: Zeigt Ihre Website beim Hochladen von Dateien keinen Fortschrittsbalken, macht das Abschalten der Funktion nichts kaputt und schließt die Tür. Ist sie darauf angewiesen, fragen Sie Ihre Entwickler, ob der Code diese Einstellung zur Laufzeit ändert.

Drei Tage später: Prüfen Sie, ob das Update vom 21. Oktober wirklich angekommen ist

Die ursprünglichen Lücken, CVE-2026-109618 und CVE-2026-109619, bleiben das größere Risiko. Die Nationale Cybersicherheitsbehörde Saudi-Arabiens (NCA) gab dazu die Warnung Nr. 2026-7949 heraus, und die US-Behörde CISA riet, alle PHP-Systeme zu erfassen, zuerst die aus dem Internet erreichbaren zu patchen und ein System vom Netz zu nehmen, wenn es sich nicht sofort patchen lässt. CISA erklärte, zum Zeitpunkt der Veröffentlichung keine erfolgreiche Ausnutzung beobachtet zu haben, was nicht heißt, dass die Zeit für Sie arbeitet.

Drei Punkte, die viele übersehen:

  • Neu starten, nicht neu laden. Das Bulletin von Red Hat hält fest, dass Konfigurationsänderungen einen Neustart der PHP-Prozesse erfordern und ein bloßes Neuladen nicht reicht.
  • Die Versionsnummer kann auf Linux-Servern abweichen. Die PHP-Ankündigung sagt, dass Linux-Distributionen die Patches vorab erhalten haben. Sie sehen also womöglich eine andere Nummer als etwa 8.5.12, obwohl die Korrektur drin ist. Verlangen Sie von Ihrem Hoster eine schriftliche Bestätigung, nicht nur eine Nummer. Red Hat weist darauf hin, dass RHEL 8, 9 und 10 alle betroffen sind.
  • Die Art, wie PHP läuft, verändert das Risiko. Das PHP-Projekt sieht das höchste Risiko bei mod_php unter Apache, während Red Hat die Ausnutzung mit dem Standard-PHP-FPM in der Praxis für schwieriger hält. Schwieriger heißt nicht unmöglich, das Update ist also in beiden Fällen nötig.

5 Fragen, die Sie heute an Ihren Hoster oder Ihr Team schicken

  1. Welche PHP-Version läuft auf jeder unserer Websites und jedem System, und enthält sie die Korrekturen vom 21. Oktober 2026?
  2. Wurden die PHP-Prozesse nach dem Update neu gestartet und nicht nur neu geladen?
  3. Haben wir session.upload_progress.enabled auf 0 gesetzt? Wenn nicht, brauchen wir die Funktion wirklich?
  4. Ändert der Code unserer Website session.serialize_handler zur Laufzeit?
  5. Haben wir eine Website auf 8.1 oder älter? Diese Zweige werden nicht mehr unterstützt, und die Tabelle der unterstützten Versionen zeigt, dass die Sicherheitsunterstützung für 8.2 am 31. Dezember 2026 endet.

Die Sicht von Origami

Drei Warnungen in drei Tagen sind nach einer schweren Lücke normal: Wenn Forscher einen Teil der Sprache durchleuchten, finden sie auch, was daneben liegt. Es sagt aber auch etwas über Unternehmen. Wer am 21. gepatcht und das Thema abgehakt hat, verpasst die Warnung vom 23. Sicherheit ist hier laufende Begleitung, keine Aufgabe, die man einmal erledigt.

In saudischen Unternehmen sehen wir, dass die schwierige Frage nicht «Was ist die Lücke?» lautet, sondern «Wer bei uns liest an einem Freitagmorgen eine PHP-Warnung und weiß, welcher Server unserer ist?». Bei Origami bauen wir Websites und Systeme und überwachen ihre Updates vom ersten Tag an. Wenn Sie Ihre Website prüfen oder diese Einstellungen ohne Ausfallzeit umsetzen lassen möchten, kontaktieren Sie uns.

Fazit

Das Update vom 21. Oktober ist unverzichtbar und bleibt das Wichtigste; die neue Warnung ändert daran nichts. Ergänzen Sie heute einen günstigen Schritt: Schalten Sie die Upload-Fortschrittsanzeige ab, wenn Sie sie nicht brauchen, starten Sie PHP neu und holen Sie eine schriftliche Bestätigung Ihres Hosters ein. Achten Sie dann auf das nächste reguläre PHP-Release, das die endgültige Korrektur für CVE-2026-115560 bringt.

Quellen