CVE-2026-115560: Neue PHP-RCE-Lücke ohne Patch, das Expositionsfenster wird länger

Was ist passiert

Am 21. Oktober 2026 hat PHP Notfall-Releases (8.5.12, 8.4.27, 8.3.36 und 8.2.35) für die beiden kritischen PHP2Shell-Lücken CVE-2026-109618 und CVE-2026-109619 veröffentlicht. Innerhalb eines Tages stieg die Zahl der Angriffsversuche in die Millionen.

Zwei Tage später, am 23. Oktober, gab PHP eine dritte Lücke bekannt: CVE-2026-115560, eine Remote-Code-Execution-Schwachstelle (RCE) im Session-Handling. Die Releases vom 21. Oktober schließen sie nicht, und ein Notfall-Patch ist nicht geplant. Der Fix kommt mit dem nächsten regulären Bugfix-Release von PHP, zusammen mit dem vollständigen Security Advisory.

Was diese Lücke anders macht

Um es klar zu sagen: Diese Lücke ist deutlich enger gefasst als PHP2Shell. Eine Anwendung ist nur dann betroffen, wenn alle drei Bedingungen erfüllt sind:

1. Konfiguration: session.serialize_handler steht auf php_binary oder php_serialize.

2. Code: Die Anwendung stellt den Wert zur Laufzeit per ini_set() wieder auf php um, bevor sie session_start() aufruft.

3. Standardwert unverändert: session.upload_progress.enabled ist weiterhin aktiv, was dem PHP-Standard entspricht.

PHP selbst hält diese Konstellation für unwahrscheinlich, und Angriffe sind bisher nicht bekannt. Aber „unwahrscheinlich" heißt nicht „ausgeschlossen", aus zwei Gründen:

• Der riskante Aufruf muss nicht in Ihrem eigenen Code stehen. Er kann in einer Composer-Abhängigkeit unter vendor/ stecken, wo kaum ein Team nachsieht.

• Fast alles ist noch unbekannt. Betroffene Versionen, CVSS-Score und Ursache sind nicht veröffentlicht. Angreifer lesen dasselbe Advisory wie Sie, und das PHP-Session-Handling ist derzeit der meistuntersuchte Code im Netz.

Für Entscheider: drei Schritte in dieser Woche

1. Prüfen Sie, ob PHP2Shell überall gepatcht ist. Jeder Server, jede Umgebung. CVE-2026-115560 darf die Behebung der bereits aktiv angegriffenen Lücken nicht verzögern.

2. Prüfen Sie, ob die Gegenmaßnahme überall greift. Eine einzige Konfigurationszeile deckt sowohl CVE-2026-109619 als auch die neue Lücke ab. Stellen Sie sicher, dass sie produktiv ist und nicht nur geplant.

3. Fragen Sie, wie lange Sie exponiert bleiben. Es ist die dritte PHP-RCE-Lücke in drei Tagen, und der nächste Fix richtet sich nach dem Release-Kalender von PHP, nicht nach Ihrem. Wenn der Patch Ihre einzige Verteidigung ist, bestimmt jemand anderes, wie lange Sie angreifbar sind.

Für technische Teams: prüfen und absichern

Betroffenheit prüfen

Durchsuchen Sie Konfiguration und Code, einschließlich vendor/, nach Verweisen auf den Session-Serializer:

grep -rn "serialize_handler" /etc/php* /etc/httpd /etc/apache2 2>/dev/null
grep -rn "serialize_handler" /var/www --include="*.php" --include=".htaccess" --include=".user.ini"

Prüfen Sie anschließend die tatsächlich aktiven Werte jeder Laufzeitumgebung, denn CLI und FPM können sich unterscheiden:

php -i | grep -E "session.serialize_handler|session.upload_progress.enabled"

Sie sind wahrscheinlich betroffen, wenn die Konfiguration php_binary oder php_serialize zeigt und der Code ini_set('session.serialize_handler', 'php') aufruft. PHP hat nicht erklärt, ob php_value-Direktiven in .htaccess oder .user.ini denselben Pfad auslösen. Behandeln Sie sie daher ebenfalls als verdächtig.

Heute absichern

session.upload_progress.enabled = 0

• Setzen Sie den Wert in der php.ini, im PHP-FPM-Pool oder in der Webserver-Konfiguration. Verlassen Sie sich nicht auf ini_set() oder .user.ini.

• Starten Sie alle PHP-Worker neu und prüfen Sie das Ergebnis mit php -i oder phpinfo() aus dem Pool, den Ihre Anwendung tatsächlich nutzt.

• Haben Sie die Einstellung bereits am 21. Oktober wegen PHP2Shell gesetzt, lassen Sie sie bestehen.

• Native Upload-Fortschrittsbalken von PHP funktionieren dann nicht mehr. Die meisten modernen Frontends messen den Fortschritt ohnehin im Browser.

Die Rolle von CYBERDEFENSE.AI

Drei PHP-RCE-Lücken in drei Tagen, eine davon noch ohne Patch. Bei jedem Schritt mussten klassische Schutzmaßnahmen auf etwas warten: einen Patch, eine Signatur, eine neue Blockierregel, eine Konfigurationsänderung. Jede Wartezeit öffnet ein Expositionsfenster, und genau dort sind Angreifer am schnellsten.

Die präventive WAF von CYBERDEFENSE.AI wartet nicht. Sie analysiert das Verhalten Ihrer Anwendungen mithilfe künstlicher Intelligenz in Echtzeit, ohne Signaturen, Regeln oder reaktive Patches. Das bedeutet:

• Für PHP2Shell war kein Update nötig, und für CVE-2026-115560 ist auch keines nötig. Der Schutz war bereits aktiv, bevor die Lücken bekannt wurden.

• Ausnutzungsversuche fallen als abweichendes Verhalten auf. Automatisierte Scanner, die Tausende Websites abgrasen, und Anfragen, die nicht zur normalen Nutzung Ihrer Anwendung passen, werden erkannt und blockiert.

• Bedrohungsdaten werden plattformweit geteilt. IP-Adressen, die bereits anderswo bei Angriffen aufgefallen sind, werden gestoppt, bevor sie Sie erreichen.

Eine zusätzliche Schutzschicht, kein Ersatz: Patchen Sie weiter. Mit einer präventiven Verteidigung vor Ihren Anwendungen ist die Zeit zwischen Veröffentlichung und Behebung aber keine Zeit mehr, in der Sie angreifbar sind.

Das Wichtigste in Kürze

• CVE-2026-115560 ist eine neue, noch ungepatchte RCE-Lücke in PHP. Die PHP2Shell-Patches decken sie nicht ab.

• Betroffen sind nur bestimmte Session-Konfigurationen, doch der auslösende Code kann in Abhängigkeiten von Drittanbietern stecken.

• Setzen Sie noch heute session.upload_progress.enabled=0 auf Serverebene und aktualisieren Sie, sobald das nächste PHP-Release erscheint.

• Patch-basierte Sicherheit lässt Sie so lange ungeschützt, wie der Patch auf sich warten lässt. Präventiver Schutz schließt dieses Fenster.