PHP2Shell und Cisco Produkte im Sicherheitscheck

Stand: 22. Oktober 2026, 14:34 Uhr MESZ / 12:34 Uhr UTC. Die Cisco-Einstufung bezieht sich auf Advisory-Version 1.1 mit Status „Interim“, zuletzt aktualisiert am 22. Oktober um 01:24 Uhr UTC.

Zwei kritische Sicherheitslücken in PHP beschäftigen seit dem 21. Oktober 2026 auch Netzwerk- und Security-Teams. Unter den Kennungen CVE-2026-109618 und CVE-2026-109619, gemeinsam als PHP2Shell bezeichnet, können sie die Ausführung fremden Codes ohne vorherige Anmeldung ermöglichen. Das PHP-Projekt hat Sicherheitsupdates veröffentlicht. Für Cisco-Umgebungen müssen Betreiber zusätzlich klären, welche eingebetteten Komponenten und Dienste betroffen sind. PHP-Sicherheitshinweis vom 21. Oktober 2026 [2]

Cisco bestätigt inzwischen AI Defense im hybriden On-Premises-Betrieb und Umbrella als nicht betroffen. Für weitere Produkte laufen die Untersuchungen; bestätigt verwundbare Produkte nennt das vorläufige Advisory bislang nicht. Cisco PSIRT, Version 1.1 vom 22. Oktober 2026 [1]

Was hinter den beiden PHP Sicherheitslücken steckt

Beide Lücken sind mit CVSS 4.0: 9,2 als kritisch bewertet. Weder Login noch Nutzerinteraktion sind erforderlich; die Ausnutzbarkeit hängt von Laufzeit, Konfiguration und Verarbeitungspfad ab. PHP-Advisory zu CVE-2026-109618 [3], PHP-Advisory zu CVE-2026-109619 [4]

Besonders relevant ist Apache mit mod_php: Für CVE-2026-109618 beschreibt das PHP-Projekt eine nachgewiesene Ausnutzung, die bereits vor dem eigentlichen Anwendungscode greift. Eine Loginprüfung innerhalb der Webanwendung kann diesen frühen Verarbeitungspfad daher nicht schützen. PHP-FPM darf ebenfalls nicht pauschal ausgeschlossen werden: Das zweite Advisory beschreibt nachgewiesene Session-Lifecycle-RCE auch unter FPM. Die beiden Lücken haben unterschiedliche Voraussetzungen; Aussagen über einen einzelnen Angriffspfad lassen sich nicht auf alle Installationen übertragen. Technische Details zur OOM-Lücke [3], Technische Details zum veralteten globalen Zustand [4]

Für die Risikobewertung ist außerdem entscheidend, mit welchen Rechten der Webprozess läuft. Codeausführung unter diesem Konto bedeutet zunächst Zugriff innerhalb seiner Berechtigungen. Ob daraus weitere Systeme erreichbar werden, hängt etwa von gespeicherten Zugangsdaten, Dateirechten und Netzsegmentierung ab. Eine automatische Übernahme des gesamten Unternehmensnetzes lässt sich aus dem CVSS-Wert allein nicht ableiten.

Welche Cisco Produkte werden untersucht

Auswahl aus „Products Under Investigation“, keine bestätigte Betroffenheit:

Cisco nennt noch keine produktspezifischen Fixstände und keinen vollständigen Workaround. Für nicht als „under investigation“ aufgeführte Produkte deuteten die ersten Daten laut Cisco auf fehlende Betroffenheit hin; das ist von einer ausdrücklichen Bestätigung zu unterscheiden. Weitere Plattformen stehen in der vollständigen Cisco-Produktliste [1].

Bereits ausdrücklich ausgenommen: Cisco AI Defense (hybrides On-Premises-Deployment) und Cisco Umbrella. Umbrella steht in Version 1.1 zugleich noch in der Untersuchungsliste. Die konkrete Bestätigung unter „Products Confirmed Not Vulnerable“ ist daher entscheidend; diese redaktionelle Überschneidung sollte nicht als bestätigte Verwundbarkeit gelesen werden.

Für Betreiber ergibt sich daraus eine konkrete Aufgabe: Den aktuellen Herstellerstatus mit dem eigenen Bestand verbinden. Ein Eintrag „Cisco vorhanden“ reicht nicht. Benötigt werden Produkt, vollständiger Softwarestand, Betriebsmodell und die tatsächlich erreichbaren Weboberflächen. Bei einem Cluster gehören alle Knoten in diese Erfassung; bei mehreren Standorten auch eigenständig betriebene Instanzen.

Die Priorität sollte sich zusätzlich nach dem möglichen Schaden richten. Ein administrativer Dienst kann eine hohe Bedeutung haben, selbst wenn ihn nur wenige Personen benutzen. Prüfen Sie deshalb, welche Konfigurationen, Identitäten oder Verbindungen von der jeweiligen Instanz abhängen. Diese betriebliche Bewertung ergänzt den Herstellerstatus, ohne eine noch offene technische Betroffenheit vorwegzunehmen.

Welche PHP Updates verfügbar sind

Für die unterstützten PHP-Zweige wurden folgende korrigierte Releases veröffentlicht:

Die Versionsangaben gelten für PHP selbst. Sie sind keine Cisco-Firmwarestände und kein Nachweis, dass eine bestimmte Appliance bereits korrigiert wurde. Offizielle PHP-Releases vom 21. Oktober 2026 [2]

PHP 8.1 und ältere Zweige befinden sich außerhalb des regulären Upstream-Supports. Das PHP-Team hat wegen der Schwere dieser Lücken minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereitgestellt. Distributionen und LTS-Anbieter können ebenfalls korrigierte Pakete liefern. Ein solcher Sonderfix stellt den allgemeinen Support eines alten Zweigs nicht wieder her. PHP-Projekt zu Updates und Backports [2]

Gerade bei Herstellerpaketen ist der Versionsstring allein daher kein ausreichendes Prüfkriterium. Ein zurückportierter Fix kann in einer Paketversion stecken, deren PHP-Hauptversion unverändert bleibt. Umgekehrt aktualisiert ein Host-Update nicht automatisch jede eingebettete Laufzeit oder jedes Container-Image. Der belastbare Nachweis ist die Zuordnung des tatsächlich eingesetzten Pakets beziehungsweise Produktbuilds zu beiden CVEs. NCSC-NL zur Bewertung eingebetteter Laufzeiten und Hersteller-Backports [5]

Für Cisco-Appliances empfiehlt sich deshalb der dokumentierte Updateweg des Herstellers. Ein selbst ausgetauschtes PHP-Paket in einer Appliance ist keine belastbare Betriebsstrategie: Abhängigkeiten, Integritätsprüfungen und spätere Updates müssten separat bewertet werden. Fordern Sie bei fehlender Zuordnung eine Aussage für das konkrete Produktrelease über den zuständigen Support an.

Wie Cisco Talos und Snort bei der Abwehr helfen

Cisco Talos nennt im Coverage-Abschnitt seines Beitrags die Snort-SIDs 67359, 67360 und 67375. Die Einleitung verweist ausdrücklich auf 67359 und 67360 auch im Community Ruleset. Welche Regeln im eigenen System verfügbar und wirksam sind, muss anhand des geladenen Regelpakets und der aktiven Policy geprüft werden. Cisco Talos zu PHP2Shell und Snort-Abdeckung [6]

Für den Betrieb einer passenden Cisco-Secure-Firewall-/Snort-Umgebung empfiehlt sich folgende Abnahme:

1. 01

   Regelbestand prüfen

   Enthält das installierte Paket die benötigten SIDs?

2. 02

   Policy-Zuordnung prüfen

   Durchläuft der relevante Webverkehr tatsächlich die entsprechende Intrusion Policy?

3. 03

   Aktion prüfen

   Wird ein Treffer nur protokolliert oder im vorgesehenen Betriebsmodus blockiert?

4. 04

   Sichtbarkeit prüfen

   Ist der für die Signatur relevante Inhalt am Prüfpunkt sichtbar, insbesondere bei HTTPS?

5. 05

   Ausnahmen prüfen

   Gibt es Bypass-, Trust- oder andere Regeln, die den Datenstrom an der Prüfung vorbeiführen?

6. 06

   Betrieb prüfen

   Funktionieren legitime Anfragen nach der Änderung weiterhin, und erreichen relevante Ereignisse das Monitoring?

Diese Prüfung bewertet den Schutz des Datenverkehrs. Der Patchstand der Firewall oder ihrer Managementkomponenten bleibt eine eigene Frage. Für ein Betriebsteam sind deshalb zwei getrennte Nachweise sinnvoll: einer für den verwendeten Schutzmechanismus und einer für die Fehlerbehebung im jeweiligen Zielsystem. Eine vorhandene Signatur allein schließt den Patchauftrag nicht ab.

Was Unternehmen jetzt priorisieren sollten

Die gemeinsame Mitteilung von ENISA, CERT-EU und weiteren europäischen Stellen fordert schnelle Maßnahmen und priorisiert Systeme mit Internetzugang. Sie empfiehlt außerdem die Abstimmung mit Hosting- und Dienstleistungsanbietern. Gemeinsame europäische Warnung vom 21. Oktober 2026 [7]

Ein praktikabler Ablauf für Cisco-Umgebungen verbindet diese Vorgabe mit den betrieblichen Abhängigkeiten:

Zuerst den Bestand belastbar erfassen. Führen Sie die relevanten Instanzen in einer gemeinsamen Arbeitsliste zusammen. Pro Eintrag sollten vollständige Version, erreichbare Schnittstellen, technischer Verantwortlicher, aktueller Herstellerstatus und nächster Prüftermin feststehen. Die Rubrik „unbekannt“ ist dabei nützlich: Sie macht fehlende Informationen sichtbar und verhindert, dass ein offener Fall versehentlich als erledigt gilt.

Dann unnötige Erreichbarkeit reduzieren. Administrationszugänge sollten auf die tatsächlich benötigten Quellen begrenzt sein. Prüfen Sie dabei auch interne Wege aus Clientnetzen, Partnerzugänge und VPN-Verbindungen. Bereiten Sie vor einer Einschränkung einen funktionsfähigen administrativen Rückweg vor. Sonst kann eine gut gemeinte Sperre die spätere Aktualisierung oder Wiederherstellung erschweren.

Anschließend einen konkreten Updateauftrag erstellen. Dieser benennt Zielrelease, Herstellerbeleg für beide CVEs, Voraussetzungen, Sicherung, Wartungsfenster und Funktionsprüfung. Bei mehreren Knoten gehört die dokumentierte Reihenfolge dazu. Ein Ticket mit dem Text „PHP aktualisieren“ bleibt für eine integrierte Netzwerkplattform zu ungenau.

Cloud-Dienste getrennt nachverfolgen. Halten Sie fest, welche Teile vom Anbieter und welche vom eigenen Team betrieben werden. Für den Abschluss braucht es einen nachvollziehbaren Anbieterstatus. Selbst betriebene Konnektoren, Agenten oder angrenzende Systeme benötigen gegebenenfalls eine zusätzliche Bewertung; eine Cloud-Statusmeldung deckt sie nicht automatisch ab.

Die Wiederherstellung als Sicherheitsentscheidung behandeln. Falls ein Update scheitert, muss ein Rückfallplan auch das erneut offene Risiko berücksichtigen. Ein Rollback auf einen verwundbaren Stand kann zwar Funktionen wiederherstellen, verlangt aber eine erneute Entscheidung über Erreichbarkeit und vorübergehende Isolation. Diese Bedingung gehört bereits in den Change-Plan.

Warum vorübergehende Maßnahmen das Update nicht ersetzen

Das PHP-Projekt beschreibt Maßnahmen, die einzelne Angriffspfade einschränken, aber keine vollständige Absicherung bieten. Dazu gehören session.upload_progress.enabled=0 und bei PHP 8.5 fatal_error_backtraces=0, jeweils mit Neustart aller Worker. Das Ausblenden von Fehlermeldungen beseitigt den zugrunde liegenden Speicherfehler nicht. PHP-Advisory zu Grenzen der Konfigurationsmaßnahmen [4]

Die OOM-Empfehlungen umfassen außerdem eine veränderte Speicherbegrenzung zusammen mit zusätzlichen Grenzen für Anfragen und Ressourcen. Solche Eingriffe beeinflussen auch Verfügbarkeit und Kapazität. Sie gehören in eine geprüfte Betriebsentscheidung und sind keine pauschale Anleitung für Cisco-Appliances. Für selbst verwaltete PHP-Server ist die vollständige Upstream-Anleitung maßgeblich. PHP-Advisory zur OOM-Abhilfe [3]

Ist eine zeitnahe Korrektur nicht möglich, sollte die Isolation eines exponierten Dienstes in die Entscheidung einbezogen werden. Das britische NCSC nennt die vorübergehende Außerbetriebnahme als mögliche Maßnahme, bis das Risiko wirksam behandelt werden kann. Für den konkreten Dienst sind dabei Ausfallfolgen, verbleibende Erreichbarkeit und die Dauer bis zum Fix gegeneinander abzuwägen. NCSC-Warnung zu PHP [8]

Wie sich ein möglicher Sicherheitsvorfall erkennen lässt

Cisco Talos meldete für den Stand 21. Oktober 2026, 14:00 Uhr UTC, noch keine selbst beobachtete Ausnutzung in freier Wildbahn. Diese zeitgebundene Aussage ist kein Beleg für die Unversehrtheit eines einzelnen Systems. Cisco Talos zur beobachteten Lage [6]

Für die Untersuchung empfiehlt sich eine zeitlich zusammenhängende Sicht auf Web-, Prozess- und Systemereignisse. Auffällige Anfragen allein sind noch kein Kompromittierungsnachweis. Deutlich aussagekräftiger wird die Bewertung, wenn im selben Zeitraum unerwartete Prozesse, Dateiveränderungen, neue ausgehende Verbindungen oder unautorisierte Konfigurationsänderungen auftreten. Beziehen Sie dabei den normalen Betrieb ein: Ein legitimer Import kann beispielsweise hohe Speicherauslastung erklären, ohne damit andere verdächtige Ereignisse zu entkräften.

Sichern Sie bei konkretem Verdacht die verfügbaren Protokolle und Supportdaten, dokumentieren Sie Zeitpunkte und stimmen Sie weitere Eingriffe mit dem Incident-Response-Team und dem Produktsupport ab. Ein Update behebt die Schwachstelle; es beantwortet nicht automatisch die Frage, ob zuvor bereits Zugangsdaten abgegriffen oder Änderungen vorgenommen wurden. Die Wiederfreigabe sollte daher sowohl die Fehlerbehebung als auch die Bewertung möglicher Folgen berücksichtigen.

Wann der Vorgang abgeschlossen ist

Für jede Instanz sollte am Ende eine belegte Entscheidung vorliegen: entweder eine passende Herstellerbestätigung, dass sie nicht betroffen ist, oder ein nachweislich installierter Fix für beide CVEs. Vorübergehend isolierte und weiterhin ungeklärte Systeme bleiben mit Verantwortlichem und Prüftermin offen.

Nach einem Update gehören der tatsächliche Buildstand aller relevanten Knoten, der Betriebszustand der Dienste und eine Prüfung der benötigten Funktionen in die Abnahme. Halten Sie außerdem fest, welche zeitweiligen Schutzmaßnahmen bestehen bleiben und unter welchen Bedingungen sie zurückgenommen werden dürfen. So endet der Vorgang mit einem nachvollziehbaren technischen Zustand und einer klaren betrieblichen Entscheidung.

PHP2Shell zeigt, weshalb Komponentenrisiken auch in Netzwerkumgebungen verfolgt werden müssen. Unternehmen benötigen jetzt einen aktuellen Bestand, gezielte Zugriffsbeschränkungen und einen verifizierten Updateweg. Ciscos fortlaufende Produktbewertung liefert dafür die Herstellergrundlage; die Umsetzung und der Nachweis im eigenen Betrieb bleiben die Aufgabe der verantwortlichen Teams.