PHP2Shell:
PHP2Shell: Filigran bewertet die kritischen PHP-Sicherheitslücken
Filigran warnt vor weitreichenden Folgen
Zwei kritische Schwachstellen in PHP versetzen Unternehmen, Hosting-Provider und Sicherheitsbehörden in Alarmbereitschaft. Mit einem CVSS-Score von jeweils 9,2 ermöglichen die als PHP2Shell bekannten Sicherheitslücken potenziell die Ausführung von Schadcode auf Webservern – ohne Anmeldung und ohne Mitwirkung der Nutzer. Besonders brisant: Technische Informationen gelangten bereits vor der offiziellen Veröffentlichung der Sicherheitsupdates an die Öffentlichkeit und verschafften Angreifern damit einen gefährlichen zeitlichen Vorsprung.
BSI stuft Bedrohung als außerordentlich hoch ein
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat auf die Schwachstellen CVE-2026-109618 und CVE-2026-109619 mit einer Cybersicherheitswarnung der Stufe 3 / Orange reagiert. Die Behörde bewertet das Gefährdungspotenzial als außerordentlich hoch.
Die beiden unter dem Namen PHP2Shell zusammengefassten Sicherheitslücken betreffen eine der weltweit meistgenutzten Technologien für dynamische Websites und Webanwendungen. Nach Angaben des BSI reichen die betroffenen PHP-Versionen mindestens bis PHP 5 zurück.
Das eigentliche Problem liegt dabei nicht in fehlerhaft programmierten Websites oder unsicheren Erweiterungen, sondern unmittelbar in der PHP-Engine. Dadurch können auch Anwendungen gefährdet sein, deren eigener Programmcode keine Sicherheitslücken aufweist.
Betroffen sind grundsätzlich PHP-Installationen, die Webanfragen verarbeiten. Dazu gehören PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP Security Team bewertet die Gefährdung bei mod_php als besonders hoch, weil ein Angriff unter bestimmten Voraussetzungen bereits während der Verarbeitung einer Anfrage möglich ist, bevor der eigentliche Anwendungscode ausgeführt wird.
Sicherheitsupdates verfügbar – Angriffsrisiko bleibt hoch
Seit dem 21. Oktober 2026 stehen korrigierte PHP-Versionen zur Verfügung. Die Sicherheitslücken werden durch die Updates auf PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen.
Für die bereits aus dem regulären Support ausgeschiedenen Versionen PHP 7.4, 8.0 und 8.1 wurden zusätzlich Backport-Korrekturen bereitgestellt. Diese sind allerdings nicht mit regulären neuen PHP-Releases gleichzusetzen. Für PHP 5 stehen keine offiziellen Sicherheitsupdates zur Verfügung.
Die Veröffentlichung der Patches bedeutet jedoch keineswegs Entwarnung. Im Gegenteil: Sobald technische Analysen und Angriffsmethoden öffentlich verfügbar sind, wächst der Druck auf Unternehmen, verwundbare Systeme schnellstmöglich zu aktualisieren.
Besonders problematisch ist die Situation für Organisationen, die ältere PHP-Versionen betreiben oder aufgrund komplexer Abhängigkeiten nicht kurzfristig aktualisieren können.
PHP2Shell trifft auch den deutschen Mittelstand
Für Unternehmen im DACH-Raum besitzt die Sicherheitswarnung eine besondere Tragweite. PHP bildet die technische Grundlage zahlreicher Unternehmenswebsites, Content-Management-Systeme und E-Commerce-Plattformen.
Damit stehen auch Installationen von WordPress, Drupal, Joomla sowie Shopsysteme wie Magento, Shopware und WooCommerce im Fokus. Entscheidend ist dabei die eingesetzte PHP-Laufzeitumgebung: Selbst ein vollständig aktualisiertes CMS kann gefährdet sein, wenn der darunterliegende Webserver eine verwundbare PHP-Version verwendet.
Wie ernst die Lage eingeschätzt wird, zeigt das Beispiel Mainz. Die Landeshauptstadt reagierte auf die Warnung mit einer vorsorglichen Abschaltung mehrerer städtischer Internetdienste einschließlich des zentralen Portals mainz.de.
Solche Maßnahmen verdeutlichen das operative Dilemma: Unternehmen und Behörden müssen zwischen der Verfügbarkeit digitaler Dienstleistungen und dem Risiko einer möglichen Kompromittierung abwägen.
Filigran: Sicherheitsverantwortliche müssen jetzt Prioritäten setzen
Die aktuelle Bedrohungslage unterstreicht, wie schnell einzelne Schwachstellen in weitverbreiteten Basistechnologien zu einem branchenübergreifenden Sicherheitsproblem werden können.
Dabei geht es längst nicht mehr ausschließlich darum, verfügbare Patches einzuspielen. Sicherheitsteams müssen zunächst feststellen, wo PHP tatsächlich eingesetzt wird, welche Systeme von außen erreichbar sind und welche geschäftskritischen Anwendungen auf verwundbaren Versionen basieren.
Gerade in komplexen IT-Landschaften mit zahlreichen Webdiensten, externen Dienstleistern und historisch gewachsenen Anwendungen kann diese Bestandsaufnahme zur Herausforderung werden.
PHP2Shell macht damit ein grundsätzliches Problem im Schwachstellenmanagement sichtbar: Zwischen der Veröffentlichung einer kritischen Sicherheitslücke und ihrer vollständigen Behebung entsteht ein Zeitfenster, das Angreifer konsequent ausnutzen können
Sam Hasseine, CEO und Mitgründer von Filigran, Debrah Galea, Senior Product Marketing Manager, sowie Mathieu Rigotoo, CISO des Unternehmens, ordnen die aktuelle Bedrohungslage ein und erläutern, worauf sich Sicherheitsverantwortliche bei der Bewertung und Priorisierung der Risiken konzentrieren sollten.
Samuel Hassine, CEO und Mitbegründer von Filigran
„Eine Website für einen Tag offline zu nehmen, ist eine weitaus kostengünstigere Entscheidung, als ein Jahr lang eine Sicherheitslücke erklären zu müssen. Die Behörden, die Organisationen genau dazu auffordern, geben fundierte Ratschläge, und die Geschwindigkeit der koordinierten Reaktion zeigt, wie sehr sich die Branche weiterentwickelt hat. Diese Schwachstellen befanden sich in Code aus dem Jahr 2004 und wurden mithilfe von KI entdeckt. Die gleichen Tools werden Angreifern helfen, sich ebenso schnell zu bewegen, und erste Angriffe werden bereits gemeldet. Die nun bevorstehende Aufgabe ist leicht zu erteilen, aber schwer umzusetzen. Man muss jedes System finden, auf dem PHP läuft, einschließlich derer, die in Produkten von Drittanbietern versteckt sind. Man muss auf eine unterstützte Version aktualisieren oder das System offline nehmen. Anschließend muss überprüft werden, ob während des Zeitraums, indem die Sicherheitslücke bestand, nichts eingedrungen ist. Das Patchen ist der einfache Teil. Zu wissen, was man betreibt, ist die eigentliche Herausforderung.“
Debrah Galea, Senior Product Marketing Manager bei Filigran
„PHP2Shell weist viele Gemeinsamkeiten mit Log4j auf: die nicht authentifizierte Remote-Code-Ausführung in Software, die fast überall läuft, ausgelöst durch eine einzige manipulierte Anfrage. Doch die Auswirkungen sind unterschiedlich. Log4j war tief in den Java-Abhängigkeiten verborgen, und die Teams brauchten Wochen, um es überhaupt zu finden. PHP ist leichter zu erkennen, sodass Unternehmen Schwachstellen schneller aufspüren können. Und im Gegensatz zu Log4Shell ist bereits ein Patch verfügbar. Die PHP-Schwachstellen lassen sich zudem schwerer ausnutzen als Log4Shell, doch da nun ein funktionierender Exploit vorliegt, wird dies Angreifer nicht lange aufhalten. Sicherheitsteams sollten PHP-Systeme mit Internetanbindung unverzüglich patchen und anschließend überprüfen, ob diese Korrekturen auch tatsächlich halten.“
Mathieu Rigotto, CISO bei Filigran
„Die Veröffentlichung eines funktionierenden PHP2Shell-Exploits, bevor der offizielle Patch verfügbar war, basierte nicht auf Sicherheitsforschung. Damit erhielten Angreifer einen Vorsprung, während die Verteidiger noch keine Gegenmaßnahmen ergreifen konnten. Eine koordinierte Offenlegung dient genau dazu, Vorfälle wie diesen zu vermeiden. Nun, da der Exploit öffentlich ist, besteht die oberste Priorität darin, die eigene Angriffsfläche zu kennen: Welche PHP-Endpunkte sind tatsächlich über das Internet erreichbar, einschließlich vergessener Altsysteme, und könnten bestehenden Schutzmaßnahmen im Weg stehen? An zweiter Stelle stehen Ownership und Auswirkungen. Jedes exponierte System benötigt einen Verantwortlichen, der sofort handeln kann, sowie ein Verständnis dafür, was eine Kompromittierung bedeuten würde, unabhängig davon, ob es um Kundendaten, Anmeldedaten oder einen Einstiegspunkt in das interne Netzwerk geht. Dieser Kontext ist enorm wichtig, denn Schweregrad-Bewertungen allein stufen jeden PHP-Server gleich ein. Was wir hier wieder vor Augen geführt bekommen, ist: Notfälle wie dieser testen nicht, wie schnell Organisationen Sicherheitshinweise lesen; sie testen, ob sie ihre Gefährdung bereits kannten, bevor der Sicherheitshinweis veröffentlicht wurde.“
