PHP2Shell in der OT Warum PHP2Shell in Industrieanlagen zur Dauerbedrohung wird

In der IT ist die kritische Schwachstelle PHP2Shell binnen Stunden gepatcht. In Produktionsnetzen und Umspannwerken droht die Lücke hingegen jahre­lang offen zu bleiben, da Betreiber auf Firmware-Updates der Hersteller angewiesen sind. Für den wirksamen Schutz der OT führt deshalb kein Weg an einem präzisen Geräteinventar vorbei.

Am 17. Oktober 2026 fingen Amazon-Honeypots einen Angriffsversuch auf, der vier Tage später einen Namen bekam. Das PHP-Team kündigte am 20. Oktober ein Notfall-Release an, am Nachmittag des 21. Oktober waren die Patches da. Cloudflare zählte allein in den zehn Stunden vor der Ankündigung Tausende Versuche, danach Millionen. Am 26. Oktober nahm die US-Behörde CISA beide Lücken in ihren Katalog bekannter, ausgenutzter Schwachstellen (KEV) auf.

Was IT-Teams jetzt tun müssen, hat Daniel Thomas Heessel an dieser Stelle beschrieben: „Wer jetzt handelt, kommt noch vor die Lage“. Dieser Beitrag ergänzt den Blick auf OT und IoT. Denn die Berichterstattung dreht sich um WordPress, Webshops, Hosting. Der Weg in die OT ist kürzer als gedacht. Er geht über die Firewall vor dem Leitsystem, über den Fernwartungsrouter im Schaltschrank, über die Wallbox auf dem Betriebshof. Ende Oktober wurden die ersten Firewalls über PHP2Shell kompromittiert.

Mögliche Zero Days

Zwei kritische PHP-Schwachstellen bedrohen Millionen Webseiten

Die Lücke in Kürze

PHP2Shell sind zwei kritische Lücken im Kern von PHP, CVE-2026-109618 und CVE-2026-109619, beide mit CVSS 9.2. Eine präparierte Anfrage bringt PHP dazu, Speicher falsch aufzuräumen. Danach läuft Code mit den Rechten des Web-Workers, ohne Anmeldung, ohne Nutzerinteraktion.

Für die OT zählen drei Details mehr als der Rest:

• Ein Login schützt nicht. PHP verarbeitet die präparierte Anfrage, bevor der Code der Weboberfläche überhaupt startet. Einer der Angriffswege, session.upload_progress, ist standardmäßig aktiv.

• Alte Zweige bleiben offen. Betroffen ist alles bis zurück zu PHP 5.4, Fixes gibt es nur für 8.2 bis 8.5. Für 8.1 und älter bleibt es bei Quell-Backports und Distributionspaketen.

• Mehrere Betriebsarten sind betroffen. Gegen Apache mit mod_php ist der Angriff vollständig gezeigt, gegen PHP-FPM ist ein Pfad belegt; auch php-cgi steht auf der Liste.

Exploit-Code kursiert, auch als geleaktes Werkzeug. Seit Mitte Oktober hat sich die Lage gedreht. Am 24. Oktober wurde Codeausführung auf Honeypots belegt. Am 26. Oktober nahm die CISA beide Lücken in den KEV-Katalog auf. Ende Oktober bestätigte Palo Alto Networks die aktive Ausnutzung gegen PAN-OS-Firewalls, deren Verwaltungsoberfläche aus dem Internet erreichbar war. Die Angreifer verketteten PHP2Shell mit der Linux-Kernel-Lücke Fragnesia (CVE-2026-46300) und erlangten Root-Rechte. Dream Research zählte mindestens 25 kompromittierte Systeme, Unit 42 hat die Angriffswerkzeuge verifiziert. Auch die Hürde ASLR ist gefallen: VulnCheck entwickelte einen Exploit, der den Speicherschutz auf x86-64-Systemen umgeht, allerdings nicht öffentlich. Die Bewertungen der Lücken reichen von 8.1 bei Red Hat bis 10.0 bei watchTowr.

Das BSI warnt mit Warnstufe Orange, ebenso CERT-EU, NCSC-NL, das Schweizer BACS, FBI und NSA. Gefunden wurden die Lücken mit massiver KI-Hilfe, und auch die Angriffe auf die Firewalls waren KI-gestützt. Was KI für die Suche leistet, leistet sie auch für den Exploit.

PHP2Shell

Wer jetzt handelt, kommt noch vor die Lage

Warum die OT anders rechnet

In der IT ist PHP2Shell ein Patch-Problem. In der OT ein Inventar- und Lieferantenproblem. PHP steckt dort, wo niemand es vermutet. In Firewall-Oberflächen. In Monitoring-Tools. Im Web-Management eingebetteter Geräte.

Drei Dinge machen die Lage in Anlagen schwieriger.

• Betreiber können nicht selbst patchen. Auf einer Steuerung, einem Router oder einer Ladesäule kommt PHP mit der Firmware. Ein Update gibt es erst, wenn der Hersteller liefert, eingespielt wird es im nächsten Wartungsfenster.

• Alte Zweige, kein Fix. PHP 8.1 und älter: kein offizielles Release. Genau solche Stände laufen auf langlebiger Firmware, etwa PHP 4.4 bis 7.3 in der ABB-Gebäudeleittechnik Cylon Aspect oder PHP 5.6 in der Zutrittssteuerung eMerge E3. Eine Studie von 2016 fand in rund 8 Prozent der untersuchten Firmware-Images serverseitigen PHP-Code.

• Die passende Architektur. Ohne ASLR ist der Angriff deutlich einfacher, und manche Appliances liefern PHP genau so aus; der Sicherheitsforscher Kevin Beaumont nennt Palo-Alto-Firewall-VMs und Citrix NetScaler. Auch mit ASLR ist der Schutz nicht mehr verlässlich: VulnCheck umgeht ihn auf x86-64 und hält die Lücken auch auf ARM64-Systemen für ausnutzbar. Das entspricht dem Profil vieler Embedded-Geräte.

Die Angriffsfläche ist groß. Unit 42 zählt 22,6 Millionen exponierte PHP-Instanzen. Mallory zählte bei Shodan rund 2,6 Millionen Dienste mit sichtbarer PHP-Version. 73,5 Prozent davon, etwa 1,9 Millionen, laufen auf PHP 8.1 oder älter, also ganz ohne offiziellen Fix.

Wie lange so etwas nachhallt. Zehn Monate nach Log4Shell waren laut Tenable noch 72 Prozent der Organisationen verwundbar. Eine PHP-Lücke im PV-Monitoring Contec SolarView wurde ab März 2023 von einer Mirai-Variante ausgenutzt; VulnCheck fand damals 425 von gut 615 erreichbaren Systemen ungepatcht. OT-Cyber.de rechnet damit, dass verwundbare PHP-Oberflächen in Industrieanlagen bis weit über 2030 hinaus im Einsatz bleiben.

Fehler in der Netzwerkverarbeitung

Angreifer nutzen Linux-Schwachstelle zur Rechteausweitung

Wo PHP im Feld steckt

Seit Ende Oktober ziehen die Hersteller nach. Zu den Firewalls und Netzwerk-Appliances kamen Warnungen und Statements von WAGO, Schneider Electric, Siemens, ABB, Rockwell Automation und Phoenix Contact, über CERT@VDE auch von Festo Didactic, Welotec und METTLER TOLEDO. Die Liste wächst täglich: NCSC-NL führt inzwischen 968 Produkte, davon 215 als verwundbar (Stand 9. November). Die Tabelle trennt, was Hersteller bestätigt haben, von dem, wo PHP nur dokumentiert ist.

Was ist nach dem CRA meldepflichtig?

Nicht jeder Sicherheitsalarm startet die CRA-Meldefrist

Auch die Entwarnungen haben Grenzen. Siemens bewertet weitere Produkte noch, und „nicht betroffen“ gilt nur für die jeweils genannten Produkte, nicht für das ganze Portfolio.

Bestätigte Angriffe betreffen bisher Firewalls. Für Steuerungen, Ladesäulen oder Gebäudetechnik sind mir keine bekannt. Die Szenarien liegen trotzdem nahe. An der Ladesäule geht es um Ladevorgänge, Abrechnung und den Weg ins Backend. An der Zutrittssteuerung? Es geht um Türen.

Wie das konkret aussieht, zeigt die Analyse der eCharge-Ladecontroller durch ONEKEY. Die komplette Web-Administration besteht aus zusammengestückelten PHP-Skripten, keines davon war gegen unbefugten Zugriff geschützt. Zwei Lücken erlaubten Befehlsausführung ohne Anmeldung, über das lokale Netz und über die Cloud-Anbindung (CVE-2024-11665, CVE-2024-11666).

Die Firmware bringt eine Konfiguration für PHP 7 mit, ein Hintergrunddienst startet seine Skripte über php-cgi, eine der Betriebsarten, die PHP2Shell betrifft. Automatische Updates gab es nicht; Ende 2024 waren 313 Geräte direkt aus dem Internet erreichbar, auf unterschiedlichen Versionsständen. Genau dieses Muster macht PHP2Shell in der OT so langlebig.

Die Firewall oder der Fernwartungsrouter ist der Fuß im OT-Netz, wie die Angriffe auf PAN-OS-Firewalls zeigen. Auch intern genutzte PHP-Appliances verschaffen Angreifern einen dauerhaften Standpunkt. Schon ohne Codeausführung kann das Speicherleck Zugangsdaten preisgeben.

Proaktive Resilienz in dynamischen Bedrohungsszenarien

Patch-Management in kritischen Produktionsumgebungen

Was OT-Betreiber jetzt tun müssen

Die allgemeinen Schritte für PHP-Server, also Patchen, die Übergangsmaßnahmen des PHP-Projekts und die Log-Analyse, hat Heessel beschrieben. In der OT kommen andere Hebel dazu.

• 1. Weboberflächen aus dem Internet nehmen. Firewalls, Fernwartungsrouter, Steuerungen und Ladecontroller zuerst. BSI, CERT-EU, NCSC-UK, FBI und NSA raten: nicht sofort patchbare Systeme trennen oder hinter ein VPN stellen. Ein Login davor schützt nicht. Die Angriffe auf PAN-OS trafen genau solche Verwaltungsschnittstellen, die aus dem Internet erreichbar waren. Für Ladecontroller rät ONEKEY zusätzlich, ausgehende Verbindungen zur Hersteller-Cloud zu sperren, solange der Hersteller sie nicht ausdrücklich braucht.

• 2. Firewalls und Fernwartung zuerst patchen. OPNsense und pfSense haben geliefert, ebenso Citrix, F5 und Check Point. Palo Alto hat für alle betroffenen PAN-OS-Zweige Hotfixes veröffentlicht. Wer die Verwaltung vor dem Update aus dem Internet erreichbar hatte, prüft das Gerät zusätzlich auf eine Kompromittierung.

• 3. PHP in der Firmware finden. Alle Geräte mit Weboberfläche erfassen, inklusive Firmware-Stand. Ein Scan zeigt die Weboberfläche, selten aber die PHP-Version dahinter. Deshalb Hersteller und Integratoren schriftlich fragen: Welche PHP-Version steckt in welcher Firmware, und wann kommt das Update? Der Abgleich mit der NCSC-NL-Liste und den CERT@VDE-Advisories spart Rückfragen.

• 4. Was nicht gepatcht werden kann, wird isoliert. Eigenes Management-Netz, Zugriff nur über Jump-Host oder VPN mit MFA. Orientierung geben die fünf ICS Critical Controls von SANS. Übergangsmaßnahmen wie session.upload_progress.enabled=0 greifen nur, wo PHP in eigener Hand ist, etwa auf Monitoring-Servern; auf geschlossenen Geräten ist das Sache des Herstellers. Auf eigenen Servern bleibt die Einstellung auch nach dem Update sinnvoll, weil für eine dritte PHP-Lücke (CVE-2026-115560) noch ein Fix aussteht. Monitoring-Tools wie Zabbix oder Nagios XI nutzen meist das PHP des Betriebssystems; dort hilft das Distributions-Update.

• 5. Auf die Geräte schauen, nicht nur auf die Server. Logs rückwirkend ab 17. Oktober prüfen, wo Geräte welche liefern. Im Netz auf ungewöhnliche Multipart-Anfragen an Geräte-Weboberflächen und auf neue ausgehende Verbindungen von Controllern achten. Snort-Signaturen und ein Open-Source-Scanner stehen bereit. Eine WAF allein genügt nicht, Angreifer passen ihre Payloads bereits an WAF-Regeln an. Bei Verdacht Zugangsdaten rotieren, das Speicherleck kann sie preisgeben.

Die Richtlinien und das OT-Problem

NIS2 und § 30 BSIG verlangen Schwachstellenmanagement und dessen Nachweis, DORA dokumentierte Patch-Richtlinien. In der IT heißt Nachweis: Datum, Paketversion, Neustart. In der OT gibt es oft keine Paketversion, die der Betreiber selbst einspielen könnte.

Dort sieht der Nachweis anders aus. Welches Gerät, welche Firmware, welche PHP-Version laut Hersteller. Wann das Update kommt und was bis dahin kompensiert: Isolation, gesperrter Fernzugriff, dokumentierte Ausnahme. Ohne Aussage des Herstellers bleibt eine Lücke in der Dokumentation, die sich nicht wegpatchen lässt.

Der Cyber Resilience Act setzt genau dort an. Seit dem 11. September 2026 müssen Hersteller aktiv ausgenutzte Schwachstellen binnen 24 Stunden vormelden und binnen 72 Stunden detailliert melden. Das betrifft Hersteller von Steuerungen, Routern und Ladecontrollern, und es kann auch Maschinenbauer treffen, die eine Anlage mit verwundbarem Controller oder Router ausliefern.

Für Betreiber ist das ein Hebel. Wer beim Lieferanten nach PHP fragt, fragt nach etwas, das der Hersteller für seine Meldepflicht ohnehin im Blick haben muss. Und wer nicht weiß, wo PHP verbaut ist, kann weder patchen noch nachweisen noch fristgerecht melden.

Die IT schließt PHP2Shell in Tagen. Die OT schließt die Lücke in Jahren, oder nie, wenn niemand weiß, wo sie steckt. Das Inventar ist der erste Patch.

Über den Autor: Maximilian Gilg ist OT-Cybersecurity-Experte aus Rosenheim und seit über 15 Jahren in der Anlagentechnik tätig. Er beschäftigt sich mit der Absicherung von Energieversorgern sowie Öl- und Gas-Anlagen im DACH- und CEE-Raum.

Maschinenbauer müssen ihre Kunden NIS-2-ready machen

NIS-2 gilt für vernetzte Industrie­anlagen ohne Übergangsfrist

(ID:51013673)