Am 21. Oktober 2026 wurden zwei kritische Sicherheitslücken im PHP-Kern veröffentlicht, die unter dem Namen PHP2Shell bekannt geworden sind. Wer dabei nur an WordPress-Websites denkt, greift zu kurz. PHP läuft nicht nur hinter klassischen Internetauftritten, sondern kann auch Bestandteil von Webanwendungen, Hosting-Panels, internen Portalen sowie Weboberflächen von Netzwerk- und Speichersystemen sein. Für Unternehmen lautet die entscheidende Frage deshalb nicht nur „Ist unsere Website aktuell?“, sondern „Wo wird in unserer gesamten technischen Umgebung PHP für Webanfragen eingesetzt?“
1. Was ist PHP2Shell?
PHP2Shell ist die Bezeichnung für zwei kritische Schwachstellen im PHP-Kern:
- CVE-2026-109618 und
- CVE-2026-109619.
Beide betreffen die Verarbeitung von Webanfragen durch PHP. Unter entsprechenden Bedingungen kann ein nicht angemeldeter Angreifer eine Schwachstelle ausnutzen und Code im Kontext des betroffenen PHP-Prozesses ausführen.
Das PHP-Projekt nennt ausdrücklich PHP-Installationen als gefährdet, die Webanfragen verarbeiten. Dazu gehören unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.
Für die regulär unterstützten PHP-Zweige wurden die korrigierten Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht.
Bei älteren Versionen muss geprüft werden, ob der Betriebssystem-, Hosting- oder LTS-Anbieter eine zurückportierte Sicherheitskorrektur bereitstellt oder ein Upgrade erforderlich ist.
2. Warum betrifft das Thema mehr als Websites?
PHP wird häufig mit WordPress verbunden. Das ist verständlich, aber für diese Sicherheitslage zu eng gedacht.
Die Schwachstellen befinden sich nicht in WordPress, sondern im PHP-Kern. Damit ist grundsätzlich entscheidend, wo PHP Webanfragen verarbeitet.
Das kann die öffentliche Unternehmenswebsite sein. Es kann aber genauso eine Anwendung sein, die Mitarbeiter nur über eine bestimmte Adresse aufrufen, eine Hosting-Verwaltung oder die browserbasierte Administrationsoberfläche eines technischen Systems.
Ein Unternehmen sollte deshalb nicht mit einer Liste seiner WordPress-Websites beginnen, sondern mit einer Liste seiner webbasierten Systeme und Anwendungen.
Die richtige Frage lautet: Wo läuft PHP in unserer Umgebung – auch dort, wo wir es im täglichen Betrieb gar nicht sehen?
3. Welche Systeme gehören jetzt auf die Prüfliste?
Die konkrete Betroffenheit muss für jedes Produkt und jede Version separat geprüft werden. Für die Bestandsaufnahme sollten Unternehmen aber deutlich weiter denken als nur an ihre öffentliche Website.
| Bereich | Was geprüft werden sollte |
|---|---|
| Unternehmenswebsites | Welche PHP-Version verarbeitet die Webanfragen und wer aktualisiert sie? |
| Content-Management-Systeme | Nicht nur WordPress: Entscheidend ist die darunterliegende PHP-Umgebung beziehungsweise der Herstellerstatus. |
| Onlineshops | Welche PHP-Version beziehungsweise welches Herstellerpaket wird eingesetzt? |
| Individuelle Webanwendungen | Eigene Kundenportale, Partnerportale, Intranets und Fachanwendungen können PHP verwenden. |
| Hosting-Panels | Auch die Verwaltungsoberfläche eines Servers kann selbst PHP enthalten. Für Plesk wurden beispielsweise eigene Sicherheitsupdates veröffentlicht. |
| NAS und Speichersysteme | Einige Produkte verwenden PHP für Webserver-Funktionen oder Verwaltungsoberflächen. Hier ist der jeweilige Herstellerhinweis maßgeblich. |
| Firewalls und Netzwerkgeräte | Auch browserbasierte Management-Oberflächen können PHP-Komponenten enthalten. Produkt und Firmware-Version müssen separat geprüft werden. |
| Monitoring- und IT-Werkzeuge | Webbasierte Administrations- und Monitoring-Systeme können PHP als Bestandteil ihrer Oberfläche oder Anwendung einsetzen. |
| Container und Server-Images | PHP kann Bestandteil eines Images sein und muss dort ebenfalls über ein aktualisiertes Image oder Paket ersetzt werden. |
Diese Liste bedeutet ausdrücklich nicht, dass jedes Produkt aus diesen Kategorien automatisch durch PHP2Shell kompromittierbar ist. Sie zeigt, wo Unternehmen bei ihrer Bestandsaufnahme nachsehen sollten.
4. PHP vorhanden bedeutet nicht automatisch: Dieses Produkt ist betroffen
Gerade bei einer schnell wachsenden Sicherheitsmeldung ist diese Unterscheidung wichtig.
Ein Produkt kann PHP verwenden und trotzdem bereits ein Herstellerupdate erhalten haben. Ein Anbieter kann eine Sicherheitskorrektur in eine ältere PHP-Version zurückportiert haben. Eine bestimmte Produktkomponente kann anders betrieben werden als eine normale PHP-Website. Oder der Hersteller untersucht die konkrete Betroffenheit noch.
Deshalb sollte nicht aus einer allgemeinen Produktliste abgeleitet werden:
„Dieses NAS, diese Firewall oder dieses CMS verwendet PHP – also ist es definitiv verwundbar.“
Stattdessen sind drei Informationen notwendig:
- Produkt und Version: Was läuft tatsächlich?
- PHP beziehungsweise Komponente: Welche technische Basis wird für Webanfragen verwendet?
- Herstellerstatus: Gibt es ein Security Advisory, ein Firmware-Update, ein gepatchtes Paket oder läuft die Untersuchung noch?
Bei klassischen selbst verwalteten PHP-Webservern lässt sich die installierte PHP-Version unmittelbar prüfen. Bei Appliances und eingebetteten Systemen sollte dagegen der vom Hersteller vorgesehene Update-Weg verwendet werden.
5. Was ist mit Systemen, die nur intern erreichbar sind?
Ein nur intern erreichbares System hat eine andere Exposition als eine Anwendung, die direkt aus dem Internet erreichbar ist. Es sollte deshalb nicht mit derselben Priorität bewertet werden wie ein öffentlich erreichbarer ungepatchter Webserver.
Ignoriert werden sollte es trotzdem nicht.
Wenn ein Angreifer über einen anderen Weg bereits Zugriff auf das Unternehmensnetz erlangt, können ungepatchte interne Systeme zusätzliche Angriffsflächen bieten.
Deshalb ist eine sinnvolle Priorisierung:
- Internet-exponierte Systeme zuerst identifizieren und absichern.
- Danach intern erreichbare PHP-basierte Systeme erfassen und Herstellerupdates prüfen.
- Nicht mehr benötigte oder unbekannte Systeme nicht einfach weiterlaufen lassen.
Entscheidend ist also nicht nur, ob ein System öffentlich oder intern erreichbar ist. Entscheidend ist, dass das Unternehmen überhaupt weiß, dass dieses System existiert, welche Software dort läuft und wer dafür verantwortlich ist.
6. Wer muss das Update durchführen?
Das lässt sich nicht für alle Systeme gleich beantworten.
| Situation | Typischer nächster Schritt |
|---|---|
| Managed Webhosting | Provider-Information prüfen und bestätigen, ob die verwendete PHP-Umgebung aktualisiert wurde. |
| Eigener Server oder VPS | PHP- beziehungsweise Betriebssystempakete aktualisieren und Dienste entsprechend der Umgebung neu starten. |
| Plesk oder anderes Hosting-Panel | Neben den gehosteten Websites auch den Herstellerstatus des Panels und seiner Komponenten prüfen. |
| Container | Aktualisiertes Basis- beziehungsweise PHP-Image verwenden und Anwendung neu bereitstellen. |
| NAS, Firewall oder Appliance | Herstellerhinweis und Firmware- beziehungsweise Produktupdate prüfen; nicht eigenmächtig interne Komponenten ersetzen. |
| Individuelle Webanwendung | Serverumgebung aktualisieren und anschließend die Anwendung sowie ihre Schnittstellen testen. |
Gerade hier zeigt sich das Problem vieler Unternehmen: Der Vertrag für Hosting, Server oder Gerät existiert, aber niemand kann unmittelbar sagen, wer bei einer kritischen Sicherheitsmeldung tatsächlich handeln muss.
7. Wie sollte ein Unternehmen jetzt vorgehen?
Bekannt betroffene, aus dem Internet erreichbare Systeme sollten umgehend aktualisiert werden. Erfassen Sie parallel weitere Systeme und klären Sie deren Patchstatus mit dem zuständigen Anbieter.
- Websites erfassen: Unternehmensseiten, Shops, Landingpages und weitere Internetauftritte.
- Webanwendungen erfassen: Kundenportale, Partnerportale, Intranets und individuell entwickelte Anwendungen.
- Server und Hosting prüfen: Managed Hosting, VPS, Dedicated Server, Hosting-Panels und Container.
- Weitere Weboberflächen identifizieren: NAS, Firewalls, Router, Monitoring- und andere technische Systeme, soweit sie PHP verwenden könnten.
- Internet-Exposition bestimmen: Welche dieser Systeme sind von außen erreichbar?
- Version beziehungsweise Herstellerstatus prüfen: Nicht allein auf Produktnamen verlassen.
- Verfügbare Updates installieren: PHP-Paket, Betriebssystempaket, Firmware, Appliance-Update oder Hersteller-Patch entsprechend der jeweiligen Umgebung.
- Systeme neu starten, wenn der jeweilige Update-Weg dies verlangt: Ein installiertes Paket bedeutet nicht in jeder Umgebung automatisch, dass bereits alle laufenden Prozesse den neuen Code verwenden.
- Funktion testen: Website, Anmeldung, Formulare, Uploads, Schnittstellen und andere geschäftskritische Funktionen kontrollieren.
- Auffälligkeiten bewerten: Bei Anzeichen für eine mögliche Kompromittierung ist eine weitergehende Incident-Prüfung notwendig; ein nachträgliches Update allein klärt einen möglichen Sicherheitsvorfall nicht auf.
8. Warum müssen danach auch Geschäftsprozesse geprüft werden?
Für Kubertino endet die technische Betrachtung nicht bei der Frage, ob eine Startseite nach dem Update wieder angezeigt wird.
Viele Unternehmenswebsites und Webanwendungen sind heute Teil eines größeren Prozesses.
Eine Anfrage kann beispielsweise über ein PHP-basiertes Formular eingehen und anschließend:
- eine E-Mail auslösen,
- einen Kontakt im CRM suchen oder erstellen,
- Daten an ein ERP übergeben,
- einen Workflow starten,
- ein Dokument erzeugen oder
- einen Mitarbeiter über einen neuen Vorgang informieren.
Das bedeutet nicht, dass das angebundene CRM oder ERP aufgrund von PHP2Shell ebenfalls verwundbar ist.
Es bedeutet aber: Wenn die technische Umgebung vor einer solchen Schnittstelle verändert wurde, sollte anschließend geprüft werden, ob der gesamte relevante Ablauf noch funktioniert.
Beispiel: Website-Anfrage
Nach dem PHP-Update öffnet sich die Website normal. Der technische Test sollte trotzdem weitergehen:
- Lässt sich das Formular absenden?
- Wird der Vorgang serverseitig verarbeitet?
- Kommt die Nachricht am vorgesehenen Ziel an?
- Funktioniert eine vorhandene CRM- oder API-Übergabe?
- Wird der interne Folgeprozess weiterhin ausgelöst?
Wie solche Übergaben strukturiert aufgebaut werden können, zeigen wir im Beitrag Formular und E-Mail ins CRM: Felder und Dubletten richtig zuordnen.
9. Was zeigt PHP2Shell über die technische Wartung eines Unternehmens?
Die aktuelle Sicherheitslage zeigt ein grundsätzliches Problem, das weit über PHP hinausgeht.
Viele Unternehmen wissen, wer Texte auf ihrer Website ändert oder neue Produkte einpflegt. Deutlich schwieriger wird die Antwort auf Fragen wie:
- Wer überwacht kritische Sicherheitsmeldungen?
- Wer kennt alle relevanten Server und Anwendungen?
- Wer prüft PHP-, Betriebssystem- und Herstellerupdates?
- Wer betreut ein Hosting-Panel?
- Wer weiß, welche Weboberflächen von außen erreichbar sind?
- Wer prüft ein NAS oder eine Appliance, wenn deren Hersteller eine Sicherheitswarnung veröffentlicht?
- Wer testet nach dem Update die geschäftlich relevanten Funktionen?
Bei einem einfachen Managed-Hosting-Paket übernimmt der Provider möglicherweise einen Teil dieser Aufgaben. Das bedeutet aber nicht automatisch, dass er auch die Anwendung, individuelle Schnittstellen oder weitere Systeme des Unternehmens betreut.
Umgekehrt kann ein Dienstleister die Website pflegen, ohne für Firewall, NAS oder die gesamte interne IT-Infrastruktur verantwortlich zu sein.
Deshalb muss bei Sicherheitsmeldungen zuerst geklärt werden, welche Systeme betroffen sein könnten und wer für jedes dieser Systeme zuständig ist.
10. PHP2Shell-Checkliste für Unternehmen
- Websites: Welche öffentlichen Websites und Shops verwenden PHP?
- Anwendungen: Welche Portale, Intranets und individuellen Webanwendungen verwenden PHP?
- Hosting: Wer betreibt die PHP-Umgebung und wurde das Sicherheitsupdate bestätigt?
- Server: Gibt es eigene VPS, Dedicated Server oder Container mit PHP?
- Panels: Werden Plesk oder andere webbasierte Serververwaltungen eingesetzt?
- Geräte: Gibt es NAS, Firewalls, Router oder andere Appliances mit webbasierten Verwaltungsoberflächen?
- Hersteller: Liegt für Produkt und Version ein aktueller Security-Hinweis vor?
- Erreichbarkeit: Welche Systeme sind direkt aus dem Internet erreichbar?
- Updates: Wurde das passende PHP-, Betriebssystem-, Firmware- oder Herstellerupdate installiert?
- Funktion: Funktionieren Website, Formulare, Uploads, Logins und Schnittstellen danach weiterhin?
- Auffälligkeiten: Gibt es Hinweise, die eine weitergehende Sicherheitsprüfung erfordern?
- Verantwortung: Ist für jedes relevante System klar, wer zukünftige Sicherheitsmeldungen prüft und Updates koordiniert?
PHP2Shell ist kein reines WordPress-Problem
Die wichtigste Erkenntnis aus der aktuellen Sicherheitslage lautet: PHP ist Infrastruktur.
Es kann hinter einer WordPress-Seite laufen, aber ebenso hinter einem Shop, Kundenportal, einer individuellen Anwendung, einem Hosting-Panel oder der Weboberfläche eines technischen Systems.
Deshalb reicht es nicht, im WordPress-Backend nach verfügbaren Updates zu schauen.
Unternehmen müssen wissen, welche Systeme sie betreiben, welche davon PHP für Webanfragen verwenden, welche von außen erreichbar sind, welcher Hersteller beziehungsweise Dienstleister zuständig ist und ob ein passendes Sicherheitsupdate tatsächlich installiert wurde.
Genau hier wird technische Betreuung für Unternehmen wichtig: nicht erst dann, wenn eine Website ausfällt, sondern bereits dann, wenn eine kritische Sicherheitsmeldung eine schnelle und nachvollziehbare Prüfung der vorhandenen Systeme verlangt.
Quellen und aktueller Stand
PHP Project – Critical remote code execution vulnerabilities
Red Hat – PHP2Shell Security Bulletin
Plesk – PHP2Shell: PHP und Plesk-Komponenten aktualisieren