Sicherheitslücke PHP2Shell Was Fertigungsunternehmen prüfen sollten

Anbieter zum Thema

Heidrive GmbH

Friedemann Wagner GmbH

SolidCAM GmbH

Zwei kritische PHP-Schwachstellen sind öffentlich, Exploits kursieren, Patches gibt es. Für Fertigungsunternehmen liegt das Risiko weniger in den Kernsystemen als in den Komponenten. Stand: 23.10.2026.

Zwei Schwachstellen (CVE-2026-109618 und CVE-2026-109619) ermöglichen laut BSI die Ausführung von Schadcode aus der Ferne. Ein Angreifer benötigt weder Benutzerkonto noch Passwort. Eine Anmeldung ist für die Ausnutzung grundsätzlich nicht erforderlich. Entscheidend ist, dass ein Angreifer eine HTTP-Anfrage an einen betroffenen PHP-Webworker senden kann. Ob eine konkrete Login-Seite angreifbar ist, hängt von der jeweiligen Server- und Anwendungskonfiguration ab.

Beide Schwachstellen haben im CVSS 4.0 den Wert 9,2. Details wurden am 20. Oktober vorzeitig öffentlich, und die PHP-Entwickler haben daraufhin schneller gepatcht. Fixes gibt es in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für PHP 8.1 und ältere Versionen gibt es keine neuen offiziellen PHP-Release-Versionen mit diesem Fix. Für einige alte Zweige existieren jedoch Backports, die von Distributionen oder Herstellern als eigene Pakete ausgeliefert werden können.

Die Schwachstellen werden bereits aktiv angegriffen. AWS beobachtete einen Exploit-Versuch bereits am 17. Oktober, also vor der Offenlegung. Seit der Veröffentlichung am 21. Oktober registrieren Sicherheitsanbieter breite automatisierte Ausnutzungsversuche. Das bedeutet allerdings nicht, dass diese Versuche erfolgreich waren. CISA und das BSI kennen bislang keine erfolgreiche Ausnutzung in der Breite.

Behörden und Hersteller

1. BSI: Die Patches sollen sofort eingespielt werden, exponierte Server sind verstärkt zu überwachen.
2. CERT.at: Auch die österreichische Meldestelle für Computer- und Netzwerksicherheit empfiehlt, betroffene PHP-Installationen umgehend zu aktualisieren. Besonders im Blick stehen internetexponierte Systeme; betroffen sind unter anderem PHP-FPM, mod_php, CGI, FrankenPHP und LiteSpeed. CERT.at weist außerdem darauf hin, dass PHP in Drittprodukten, Appliances und Containern stecken kann. Ist ein sofortiges Update nicht möglich, sollen Betreiber die Angriffsfläche mit den vom PHP-Projekt genannten Maßnahmen reduzieren oder Systeme, wenn möglich, vorübergehend vom Netz nehmen. Die temporären Maßnahmen sind ausdrücklich kein vollständiger Ersatz für das Update. Nach Änderungen an der Konfiguration sollen die PHP-Worker neu gestartet werden.
3. CISA: Das Patchen ist dringend, internetnahe Systeme haben Vorrang. Die Behörde warnt, dass PHP in Produkten stecken kann, die man nicht direkt sieht, und rät dazu, auch eingebettetes PHP in Drittprodukten und Containern zu inventarisieren. Wer nicht schnell patchen kann, soll betroffene Systeme vom Netz nehmen. Ob die Lücken im Katalog bekannter ausgenutzter Schwachstellen (KEV) stehen, konnte ich nicht bestätigen.
4. NCSC-NL: Die niederländische Behörde führt eine Liste betroffener Produkte, die sich laufend ändert. Sie ist eine Momentaufnahme, in der Hersteller teils noch „in Prüfung" sind.

Beispiel Firewall

Palo Alto Networks bestätigt die Betroffenheit von PAN-OS und Panorama. Das bezieht sich auf die Management-Ebene; der Hersteller bewertet das Risiko unter anderem als Einschränkung der Management-Funktion und arbeitet an Fixes. Bis dahin soll der Zugriff auf die Managementoberfläche auf vertrauenswürdige interne Netze beschränkt werden. Das Beispiel zeigt, warum eine reine Liste eigener PHP-Server nicht genügt: PHP kann Bestandteil eines Appliances oder einer Managementplattform sein.

Altsysteme werden zum Problem

Auch bei Sicherheitsherstellern zeigt sich das Problem von Alt- und Nebenkomponenten: Nicht nur aktuelle Kernprodukte, sondern auch ältere Webanwendungen und Portale können eine verwundbare PHP-Laufzeit enthalten. Siemens teilte am 22. Oktober mit, dass der Einfluss auf Siemens-Produkte geprüft werde. Für betroffene Produkte sollen separate Security Advisories veröffentlicht werden.

Was nicht sicher ist …

1. Ob Kernsysteme betroffen sind. Auf der Herstellerliste standen zuletzt keine großen ERP-, PLM- oder MES-Plattformen. Das heißt „bisher nicht bekannt" und nicht „nicht betroffen". Viele Hersteller haben noch nicht geantwortet.
2. Wie leicht es in der eigenen Umgebung geht. Demonstrationen zeigen die Ausnutzung unter anderem bei Webanwendungen auf Basis von WordPress, Drupal und Joomla. Entscheidend ist dabei nicht das CMS selbst, sondern die darunter eingesetzte verwundbare PHP-Laufzeit und deren konkrete Serverkonfiguration.
3. Was im eigenen Netz steckt. Das ist die größte Unsicherheit, und sie ist die einzige, die Anwender selbst beseitigen können.

Handlungsoptionen

Für die Produktion ist nicht entscheidend, ob PHP direkt auf einer SPS läuft. Kritisch kann bereits ein kompromittierter Server sein, der Zugang zu Engineering-, Visualisierungs-, Fernwartungs- oder Managementsystemen besitzt. Die PHP-Schwachstelle ist dann möglicherweise nur der erste Schritt einer Angriffskette. Eine saubere Trennung von Office-IT, DMZ und OT begrenzt diesen möglichen Folgeschaden.

Für IT-Manager

1. Inventarisieren von PHP-Laufzeiten, Geräten mit Weboberfläche, Containern und Hosting-Dienstleistern. Anfordern einer schriftlichen Bestätigung von Dienstleistern.
2. Aus dem Internet erreichbare Systeme zuerst patchen und Neustart der PHP-Prozesse. Ein CMS- oder Plugin-Update behebt die Lücke in der Laufzeit nicht.
3. Verwaltungszugänge von Netzwerk- und Sicherheitsgeräten nicht ins Internet legen, sondern auf ein internes Verwaltungsnetz.
4. Exponierte Systeme auf neue Dateien, unbekannte Prozesse und ungewöhnliche ausgehende Verbindungen prüfen. Bei ungepatchten, exponierten Systemen von einem möglichen Befall ausgehen.
5. Hersteller-Advisories und die Tracker-Liste verfolgen. WAF-Regeln sind eine Übergangslösung und kein Ersatz für den Patch.

Für Fertigungsleiter, Ingenieure, Konstrukteure

1. der IT melden, welche Maschinen, Anlagen und Dashboards eine Weboberfläche haben.
2. fragen, ob diese Oberflächen aus dem Büronetz oder dem Internet erreichbar sein müssen. Meist ist das nicht nötig.
3. Wartungsfenster für Sicherheitsupdates einplanen, bevor die nächste Lücke kommt.

Fazit und Ausblick

Die Lage bleibt in einem wichtigen Punkt unsicher: Ob die Kernsysteme der Fertigung betroffen sind, wissen wir noch nicht. Sicher ist, was Angreifer derzeit angehen, nämlich PHP-Webserver und Standard-CMS, die aus dem Internet erreichbar sind. Dort kommt der Patch zuerst.

Zweitens lohnt der Blick über die bekannten Server hinaus. Wer nur sagt „Unsere Kernsysteme laufen nicht auf PHP", weiß das möglicherweise nicht mit Sicherheit. CISA rät deshalb, auch eingebettetes PHP in Geräten und Drittprodukten zu inventarisieren.

Links:

https://github.com/NCSC-NL/php2shell

https://security.paloaltonetworks.com/CVE-2026-109618

https://cert-portal.siemens.com/news/2026/10/22/

https://aws.amazon.com/tw/blogs/securityut/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/

https://blog.cloudflare.com/php-vulnerabilities-waf-protection

https://www.sophos.com/en-us/security-advisories/sophos-sa-20261021-php2shell

https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2026/261021_PHP-kritische-Schwachstelle.html

https://www.cisa.gov/

https://www.cert.at/de/warnungen/2026/10/kritische-sicherheitslucken-in-php-updates-verfugbar