PHP2Shell in OT-Anlagen: warum die Lücke Jahre bleibt
Kurz gesagt: PHP2Shell wird seit der Veröffentlichung am 21. Oktober 2026 breit angegriffen, erste Versuche gab es schon ab dem 17. Oktober. Ein Login schützt nicht, und für PHP 8.1 und älter gibt es keine offiziellen Updates. In Anlagen steckt PHP in den Weboberflächen von Steuerungen über Industrie-Router und Firewalls bis hin zu Ladesäulen und Energietechnik, deren Firmware selten aktualisiert wird. Betreiber sollten diese Weboberflächen jetzt vom Internet trennen. Verwundbare PHP-Weboberflächen werden in Anlagen aller Voraussicht nach bis weit nach 2030 zu finden sein.
Am 21. Oktober 2026 hat das PHP-Team zwei kritische Lücken geschlossen, die unter dem Namen PHP2Shell laufen (CVE-2026-109618 und CVE-2026-109619, CVSS v4.0 jeweils 9,2). Beide erlauben es, aus der Ferne und ohne Anmeldung Schadcode auszuführen. Das BSI warnt mit Stufe 3 (Orange). Diskutiert wird bislang vor allem über Webseiten und Onlineshops. Aus Sicht der OT-Cybersecurity in Rosenheim interessiert dagegen vor allem, was in den Anlagen passiert. Und zwar bei Betreibern und Maschinenbauern in Bayern, Salzburg und Tirol genauso wie im ganzen DACH-Raum.
Die Angriffe laufen bereits
Breite Angriffsversuche gibt es längst, erfolgreiche Einbrüche sind dagegen noch nicht belegt. Amazon hat den ersten Angriffsversuch auf seine Honeypots am 17. Oktober gesehen, vier Tage vor der Veröffentlichung, und spricht inzwischen von breiter Ausnutzung. Cloudflare zählte Tausende Versuche in den zehn Stunden vor der Ankündigung, Hunderttausende zwei Stunden danach und inzwischen Millionen.
Die US-Behörde CISA hatte bei Veröffentlichung noch keine Ausnutzung beobachtet. Belegt sind Massenscans und Angriffsversuche. Wie viele davon erfolgreich waren, ist offen.
Dabei verarbeitet PHP die präparierte Anfrage, bevor die eigentliche Anwendung überhaupt startet. Ein Passwort an der Weboberfläche hält den Angriff nicht auf.
Der fehlerhafte Code stammt laut Sansec aus PHP 5.4, also aus dem Jahr 2012. Seitdem hat PHP seinen Weg in sehr viele Geräte gefunden.
Wo PHP in OT-Geräten steckt
Belegt ist PHP im Webinterface bei den folgenden Geräten. Ob und wie ein Gerät von PHP2Shell betroffen ist, bewertet der jeweilige Hersteller.
- Steuerungen und HMI: WAGO PFC100, WAGO PFC200, WAGO CC100, WAGO Edge Controller, WAGO Touch Panel 600 (Standard, Advanced, Marine); Kunbus Revolution Pi mit PiCtory
- Router und Switches: NetModule NB800, NB1601, NB1800, NB1810, NB2800, NB2810, NB3701, NB3800, NG800; Phoenix Contact TC ROUTER 4002T, 4102T, 4202T; TC CLOUD CLIENT 2002T, 2102T; FL SWITCH 2000er-Serie; FL NAT 2008, 2208, 2304
- Firewalls: Palo Alto PAN-OS 10.2 bis 12.2 und Panorama (betroffen bestätigt, Fix offen); OPNsense (gefixt in 26.7.7 und 26.4.2p3); Netgate pfSense (Update veröffentlicht); Juniper J-Web auf SRX und EX; Citrix, Ivanti und F5 BIG-IP nutzen laut heise ebenfalls PHP; Fortinet prüft FortiADC, FortiSIEM und FortiClient EMS, FortiOS ist nicht betroffen
- Ladesäulen: eCharge Hardy Barth cPH2 und cPP2; Salia-PLCC-Ladecontroller, der auch in Wallboxen anderer Marken steckt (laut ONEKEY mit PHP 7)
- Energie, PV, Smart Meter, Fernwirktechnik: Contec SolarView Compact; Ezylog-PV-Server; volkszaehler.org; Mitsubishi Electric smartRTU und INEA ME-RTU
- Gebäude und Zutritt: ABB Cylon Aspect (NEXUS, MATRIX-2, ASPECT-Enterprise); Schneider Electric U.motion Builder; Nice Linear eMerge E3
- Überwachung in OT-Netzen: Nagios XI, Cacti, LibreNMS, Zabbix-Frontend
Geprüft, aber ohne PHP-Beleg: Ignition, Copeland XWEB Pro, Kieback und Peter DDC4000, der Fernwärmeregler Samson TROVIS 5610, Solar-Log, Danfoss AK-SM 800A, Siemens SCALANCE und RUGGEDCOM sowie Smart-Meter-Gateways. Kein Beleg heißt nicht ausgeschlossen.
Alle Quellen und die laufenden Updates stehen im Vorfall-Lagebild zu PHP2Shell.
PHP allein macht ein Gerät noch nicht angreifbar
Ob ein Gerät tatsächlich angreifbar ist, hängt an der PHP-Version und der Betriebsart. Und daran, ob die Weboberfläche überhaupt erreichbar ist. Bewerten kann das nur der Hersteller. Den aktuellen Stand finden Betreiber in den Advisories der Hersteller und bei CERT@VDE.
Warum die Lücke in Anlagen Jahre bleibt
Dass solche Lücken lange nachwirken, ist nicht neu. Bei Log4Shell schätzte Kaspersky Ende 2021, dass mindestens zehn Prozent aller Steuerungssysteme weltweit betroffen sein könnten. Laut Tenable waren knapp ein Jahr später noch 72 Prozent der Organisationen verwundbar. Die php-cgi-Lücke CVE-2024-4577 nutzte Ransomware wenige Tage nach dem Patch und noch ein Jahr später. Bei Contec SolarView wurde eine PHP-Lücke in diesem PV-Monitoring ein Jahr nach dem Exploit von Mirai ausgenutzt. 2024 wurden in Japan 800 Geräte für Bankbetrug gekapert.
Bei PHP2Shell dürfte es ähnlich laufen, nur in Etappen. Bis Ende 2026 dominieren Massenscans und Botnetze. Am stärksten im Fokus stehen dabei Firewalls und VPN-Zugänge, weil sie den Weg ins Netz öffnen. In den Jahren 2027 und 2028 liefern die großen Hersteller Updates, die Betreiber aber nur im Wartungsfenster einspielen. Erschwerend kommt hinzu: PHP 8.2 läuft Ende 2026 aus, 8.3 Ende 2027. Ab 2029 bleibt ein Restbestand, vor allem Geräte ohne Herstellerpflege. Genau diesen nutzen dann Botnetze und Kriminelle.
Am längsten verwundbar bleiben aller Voraussicht nach Ladecontroller mit PHP 7, PV-Logger, Fernwirkstationen bei Wasser und Fernwärme, Gebäudeautomation und Zutrittskontrolle sowie Industrierouter in Maschinen, die ohne Wartungsvertrag laufen. Für Produktion und Instandhaltung heißt das: Der Router im Schaltschrank, über den der Maschinenhersteller seit Jahren per Fernwartung zugreift, gehört ganz oben auf die Liste.
Was der CRA für Maschinenbauer bedeutet
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden als Frühwarnung melden, binnen 72 Stunden ausführlich. Das gilt auch für Maschinenbauer, wenn die Lücke in einer zugekauften Steuerung oder einem Router steckt. Wer nicht weiß, wo PHP verbaut ist, kann nicht fristgerecht melden. Bei Meldeprozess und Lieferantenabfrage unterstützen wir mit CRA as a Service.
Was Betreiber jetzt sofort tun sollten
- Weboberflächen von Steuerungen, Fernwartungsroutern und Firewalls vom Internet trennen und nur über VPN oder Jump Host erreichbar machen.
- Firewalls zuerst: OPNsense und pfSense aktualisieren, bei PAN-OS das Management bis zum Fix auf vertrauenswürdige interne Adressen begrenzen.
- Geräte mit Weboberfläche inventarisieren, mit Firmware-Stand, und beim Hersteller nach PHP-Version und Update-Termin fragen. Wo diese Übersicht fehlt, hilft ein OT-Asset-Inventar.
- Exponierte Systeme ab dem 17. Oktober auf Auffälligkeiten prüfen. Wer dabei Spuren findet, erreicht unsere OT-Notfallhilfe.
Langfristig absichern
Für die Zeit nach dem Notfall orientieren sich Betreiber am besten an den SANS Five ICS Cybersecurity Critical Controls. Auf PHP2Shell angewendet heißt das: ein ICS-spezifischer Notfallplan und eine verteidigbare Architektur mit eigenem Management-Netz. Hinzu kommen passive Angriffserkennung im OT-Netz (siehe Angriffserkennung (SzA)), sicherer Fernzugriff mit Mehrfaktor-Anmeldung und ein risikobasiertes Schwachstellen-Management mit SBOM beim Einkauf. Herstellerhinweise laufend mit dem eigenen Inventar abzugleichen, ist mit KI-Unterstützung inzwischen auch für kleine Teams machbar.
In der IT bald erledigt, in der Anlage noch lange nicht
In der IT dürfte PHP2Shell aller Voraussicht nach in wenigen Wochen weitgehend abgearbeitet sein. In Anlagen bleibt die Lücke dagegen bis weit nach 2030 bestehen: Die Geräte laufen lange und werden selten aktualisiert. Zumal kaum jemand weiß, dass überhaupt PHP darin steckt. Betreiber sollten deshalb keinesfalls warten, bis der Hersteller ein Update liefert. Wer die Weboberflächen jetzt abschottet, nimmt den größten Teil des Risikos heraus, auch bevor das Update kommt.
Max Gilg, OT-Cybersecurity-Experte aus Rosenheim, OT-Cyber.de
Quellen: PHP-Advisory, BSI-Warnung 2026-297981-1032, CISA-Alert vom 21.10.2026, Amazon Threat Intelligence, Cloudflare, SANS ISC, Sansec, Palo Alto Advisory CVE-2026-109618, Fortinet FG-IR-26-186, Cisco cisco-sa-php-october26, OPNsense, NCSC-NL php2shell, ONEKEY, heise, Dragos, Kaspersky ICS CERT, Tenable, VulnCheck. Alle Einzelquellen im Lagebild.
Häufige Fragen
Was ist PHP2Shell und warum betrifft es OT-Anlagen?
PHP2Shell sind zwei kritische PHP-Lücken (CVE-2026-109618 und CVE-2026-109619, CVSS v4.0 jeweils 9,2), die Schadcode aus der Ferne ohne Anmeldung erlauben. In Anlagen steckt PHP in den Weboberflächen von Steuerungen, Industrie-Routern, Firewalls, Ladesäulen und Energietechnik, deren Firmware selten aktualisiert wird.
Schützt ein Passwort an der Weboberfläche der Steuerung vor PHP2Shell?
Nein. PHP verarbeitet die präparierte Anfrage, bevor die Anwendung startet. Ein Login hält den Angriff nicht auf. Die Weboberfläche muss vom Internet getrennt und nur über VPN oder Jump Host erreichbar sein.
Darf der Servicetechniker weiter per Fernwartung auf die Weboberfläche des Routers zugreifen?
Nur über VPN oder Jump Host, nicht direkt aus dem Internet. Langfristig empfiehlt Max Gilg sicheren Fernzugriff mit Mehrfaktor-Anmeldung (SANS Critical Control 4, Secure Remote Access). Industrierouter in Maschinen ohne Wartungsvertrag zählen zu den Geräten, die am längsten verwundbar bleiben.
Was bedeutet PHP2Shell für Maschinenbauer unter dem Cyber Resilience Act?
Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden als Frühwarnung und binnen 72 Stunden ausführlich melden, auch wenn die Lücke in einer zugekauften Steuerung oder einem Router steckt. Wer nicht weiß, wo PHP verbaut ist, kann nicht fristgerecht melden.