Ein NAS für den Fernzugriff, ein veröffentlichter Container-Port oder ein früher nur vorübergehend geöffnetes Gateway: Solche Dienste werden leicht übersehen. Bei PHP2Shell entscheiden drei Dinge: Was ist erreichbar, welche Laufzeit verarbeitet die Webanfragen und welche weiteren Ziele erreicht dieser Dienst?
Die ersten beiden Beiträge dieser Reihe beschreiben die PHP-Sicherheitslage und unsere Reaktion sowie die Bestandsprüfung mit Unterstützung durch KI. Hier geht es um die praktische Prüfung bei Unternehmen und privaten NAS-Betreibern. Ein Markenname ersetzt kein Inventar. Ebenso wenig beweist eine aktuelle Firmware, dass auch jedes Paket und jeder laufende Container aktualisiert wurde.
PHP2Shell betrifft die tatsächlich eingesetzte Web-Laufzeit
CVE-2026-109618 und CVE-2026-109619 können eine Codeausführung ohne vorherige Anwendungsanmeldung ermöglichen; die Bewertung nach CVSS v4.0 liegt jeweils bei 9,2. Das PHP-Projekt veröffentlichte am 21. Oktober 2026 die korrigierten Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Anbieter können eigene korrigierte Pakete mit zurückportierten Änderungen bereitstellen. Maßgeblich ist deshalb das jeweilige Advisory, nicht nur eine Versionszahl.
Eine Login-Seite bietet hier keine automatische Entwarnung. Geprüft werden muss der Interpreter, der die Webanfragen tatsächlich bearbeitet, einschließlich laufender Worker. Eine aktuelle PHP-Version auf der Kommandozeile sagt darüber allein nichts aus. Das gilt für klassische Webserver ebenso wie für gebündelte Laufzeiten in Anwendungen, Appliances und Images.
Öffentlich erreichbar kann mehr sein als eine Portfreigabe
Zum Inventar gehören IPv4 und IPv6, Routerfreigaben, UPnP, DDNS-Namen, Reverse-Proxy-Ziele, Tunnel und cloudvermittelte Fernzugänge. Dabei ist jeweils der wirkliche Zugriffsweg zu klären: Eine öffentliche IP ist noch keine verwundbare Anwendung. Auch ein Hersteller-Relay ist nicht automatisch vom selben Angriffsweg erfasst. Umgekehrt kann eine vergessene Freigabe einen eigentlich internen Dienst erreichbar machen.
Webseiten, CMS, Kundenportale, Hosting-Panels sowie Backup-, Monitoring- und Verwaltungsoberflächen gehören auf diese Liste. Gleiches gilt für NAS-Plattformen, VoIP-, Kamera-, Drucker- und Steuerungssysteme. Geräte ohne relevante PHP-Komponente sind dadurch nicht automatisch von diesen beiden CVEs betroffen. Ihre öffentliche Erreichbarkeit bleibt trotzdem eine sinnvolle Sicherheitsfrage.
Synology: Betriebssystem und Pakete getrennt betrachten
Synology begrenzt die Betroffenheit auf bestimmte PHP-abhängige Pakete, darunter Web Station, WordPress, Calendar und MailStation. Die Mitteilung vom 22. Oktober nennt PHP-Paketupdates für DSM 7.4, 7.3 und ausdrücklich auch DSM 7.2, obwohl diese DSM-Version bereits ihr Lebensende erreicht hat. Für ältere DSM-Versionen empfiehlt der Hersteller, betroffene Pakete vorübergehend zu deaktivieren.
PHP wird über das Paket-Zentrum aktualisiert; MailStation benötigt zusätzlich ein manuelles Paketupdate. Das Advisory nennt für das Synology-Paket PHP 7.3 keinen Fix. Das intern von DSM verwendete PHP ist laut Hersteller anders exponiert und besitzt keine extern erreichbaren Module. Auch die Namen verdienen Aufmerksamkeit: Das Drittanbieterpaket IDrive ist nicht Synology Drive; Synology Drive wird in der Mitteilung als nicht betroffen bezeichnet.
Bei inoffiziellen DSM-Installationen über XPEnology muss die Kombination aus Gerät, Loader, DSM und Paketen einzeln geprüft werden. Dieser Weg entspricht keinem regulär unterstützten Synology-Gesamtsystem. Daraus folgt weder, dass grundsätzlich nie Updates möglich wären, noch eine pauschale Verwundbarkeit. Unsichere Updatefähigkeit ist aber ein guter Anlass, direkten Internetzugang zu begrenzen und einen verlässlich wartbaren Betrieb zu planen.
QNAP: Den inzwischen geänderten Status prüfen
Das QNAP-Advisory QSA-26-18 führt seit seiner Aktualisierung vom 24. Oktober Korrekturen für mehrere QTS-, QuTS-hero- und QuTScloud-Zweige auf. Andere dort gelistete Anwendungen stehen weiterhin auf „Fixing“. Weder „QNAP hat noch keinen Patch“ noch „alles ist erledigt“ beschreibt diesen Bestand korrekt. Entscheidend sind das konkrete Produkt, sein Versionszweig und die zugehörige korrigierte Fassung. PHP in Drittanbieteranwendungen oder eigenen Containern wird nicht automatisch durch ein QNAP-Systemupdate repariert.
Bei Containern sind zwei getrennte Fragen zu beantworten
Erstens: Ist die Runtime im laufenden Container korrigiert? Ein aktualisierter Host ersetzt kein altes Image. Basis-Image, zusätzliche Pakete und tatsächlich laufende Bereitstellung müssen zusammenpassen. Ein neues Image im lokalen Bestand hilft erst, wenn der Dienst mit der korrigierten Fassung neu bereitgestellt wurde und die Funktionsprüfung bestanden hat.
Zweitens: Welche Rechte und Netzwerkwege besitzt der Dienst? Docker-Bridge-Netze erlauben grundsätzlich ausgehende Verbindungen; Container desselben Bridge-Netzes können miteinander kommunizieren. Welche internen Ziele erreichbar sind, hängt unter anderem von Routing und Firewallregeln ab. Ein kompromittierter Container übernimmt deshalb nicht automatisch das gesamte LAN. Gemeinsam genutzte Zugangsdaten, unnötige Host-Mounts, zusätzliche Privilegien oder ein eingebundener Docker-Socket können die Folgen jedoch erheblich erweitern. Eigene Netze, gezielte Egress-Regeln und minimale Rechte brauchen eine konkrete Prüfung.
Sieben Prüfungen für die nächste Arbeitsrunde
- Zugänge erfassen: Geräte, Anwendungen, veröffentlichte Ports und Vermittlungsdienste mit Verantwortlichen dokumentieren. IPv6 und vergessene temporäre Freigaben einschließen.
- Laufzeiten zuordnen: Betriebssystem, Pakete, Plugins und Web-PHP pro Dienst erfassen. Herstellerhinweise und Wartungsstatus prüfen.
- Korrigieren und verifizieren: Geeignete Updates oder neue Images einspielen, betroffene Dienste ordnungsgemäß neu starten und die tatsächlich aktive Fassung kontrollieren.
- Exposition reduzieren: Nicht benötigte öffentliche Verwaltungszugänge schließen. VPN oder ein vertrauenswürdiges Administrationsnetz können den Zugang begrenzen; auch dahinter bleiben Updates erforderlich.
- Wege und Rechte testen: Datenbank-, NAS-, Backup- und Managementzugänge auf den benötigten Umfang beschränken. Regeln betriebssicher ändern und legitime Anwendungen anschließend prüfen.
- Spuren und Wiederherstellung prüfen: Auffällige Zugriffe, Konten und ausgehende Verbindungen bewerten. Unabhängige, gegen unbefugte Änderung geschützte Sicherungen und getestete Wiederherstellung vorhalten; Snapshots allein ersetzen das nicht.
- Ausnahmen nachhalten: Systeme ohne verfügbare Korrektur mit Zuständigkeit, Übergangsmaßnahme und Ersatz- oder Stilllegungsplan dokumentieren.
Ein Patch beendet nicht automatisch die Incident-Prüfung
Sophos verweist auf einen von Amazon Threat Intelligence beobachteten Ausnutzungsversuch bereits am 17. Oktober, vor der öffentlichen Bekanntgabe. Bei tatsächlich exponierten Systemen gehört daher auch die frühere Aktivität zur Bewertung. Ein erfolgreiches Update beweist nicht, dass vorher kein unbefugter Zugriff stattgefunden hat. Bei Verdachtszeichen ist eine geordnete Incident-Bearbeitung mit geeigneter Spurensicherung und kontrollierter Wiederherstellung erforderlich.
Zusätzlich weist PHP seit dem 23. Oktober auf einen seltenen, konfigurationsabhängigen weiteren Fall beim Session-Upload-Fortschritt hin. Aktuelle Herstellerhinweise bleiben deshalb auch nach dem ersten Update relevant. Allgemeine Konfigurationsänderungen ohne Kenntnis ihrer Betriebsfolgen sind keine gute Abkürzung.
Was nicht notwendig öffentlich sein muss, sollte bis zur Prüfung nicht öffentlich erreichbar sein. Das reduziert die Angriffsfläche und ersetzt die Korrektur nicht. DAXS unterstützt dabei, Dienste zuzuordnen, Maßnahmen zu priorisieren und ihre Wirksamkeit nachvollziehbar zu prüfen. Besprechen Sie Ihre konkrete Umgebung mit uns.
Quellen: PHP: Sicherheitsmeldungen und korrigierte Versionen · ENISA: PHP-Anwendungen identifizieren und Exposition begrenzen · Synology: betroffene Pakete und DSM-Versionen · Synology-SA-26:14 · QNAP QSA-26-18: produktbezogener Korrekturstatus · Docker: Eigenschaften von Bridge-Netzen · Sophos: Exposition, Aktivität und Incident-Prüfung · NCSC-NL: Übersicht zu PHP-Abhängigkeiten · Red Hat: Laufzeiten, Backports und weitere Hinweise.