Blog
PHP2Shell: Warum jetzt schnelles Handeln gefragt ist
Sicherheitslücken in PHP, Frameworks oder anderen zentralen Komponenten einer Webanwendung sind nichts Ungewöhnliches. Software wird kontinuierlich weiterentwickelt und dabei werden auch regelmäßig Schwachstellen entdeckt, bewertet und geschlossen. Entscheidend ist deshalb nicht allein, dass eine Lücke existiert, sondern wie weitreichend sie ist und wie gut Organisationen darauf vorbereitet sind.
Bei den aktuell bekannt gewordenen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 ist besondere Aufmerksamkeit angebracht. Das BSI bewertet beide Schwachstellen mit einem CVSS-Score von 9,2 von 10 und der Kritikalitätsstufe Orange. Betroffen sind PHP-Installationen, die Webanfragen verarbeiten und damit potenziell sehr viele öffentlich erreichbare Webanwendungen. [1]
Was macht diese Schwachstellen besonders?
Zum einen ist PHP weit verbreitet: Es steckt nicht nur in individuell entwickelten Webanwendungen, sondern bildet auch die technische Grundlage zahlreicher etablierter Systeme wie etwa WordPress, Drupal, TYPO3, Joomla, Magento oder Nextcloud. Eine Schwachstelle in der PHP-Laufzeitumgebung kann daher viele unterschiedliche Anwendungen gleichzeitig betreffen.
Zum anderen handelt es sich nicht um ein Problem, das sich allein durch ein Update des eingesetzten CMS, Shopsystems oder Frameworks beheben lässt. Die Schwachstellen betreffen die PHP-Laufzeitumgebung selbst. Wer beispielsweise WordPress aktualisiert, aber eine verwundbare PHP-Version betreibt, ist damit nicht automatisch geschützt. Entscheidend ist, dass die PHP-Installation beziehungsweise die zugrunde liegende Plattform aktualisiert wird.
Ungewöhnlich war auch der Ablauf der Veröffentlichung: Das PHP Security Team kündigte bereits am Vortag eine kritische Sicherheits Veröffentlichung an und nannte den geplanten Zeitpunkt. Damit konnten Betreiber interne Abläufe vorbereiten, Wartungsfenster abstimmen und Kapazitäten für ein zügiges Update einplanen. Mit der Veröffentlichung der technischen Details und korrigierten Versionen stieg jedoch zugleich der Zeitdruck: Sicherheitsupdates können durch KI besonders effizient analysiert werden, um daraus Angriffsmethoden gegen noch ungepatchte Systeme abzuleiten. Das BSI geht deshalb von einer kurzfristigen Ausnutzung verwundbarer Systeme aus. [1]
Hinzu kommt: Laut BSI ist für eine mögliche Ausnutzung weder eine Anmeldung noch eine Interaktion von Nutzenden erforderlich. In bestimmten Konstellationen könnte dies die Ausführung von Schadcode auf einem PHP-Webserver ermöglichen. Gerade bei öffentlich erreichbaren Systemen ist das ein Risiko, das unverzüglich bewertet werden sollte. [1]
Unsere Handlungsempfehlungen für Unternehmen
In einer solchen Lage kommt es auf einen klaren, pragmatischen Ablauf an. Wir empfehlen, nicht nur einzelne Server zu betrachten, sondern strukturiert vorzugehen:
1. Betroffenheit schnell feststellen
Verschaffen Sie sich einen Überblick über alle Systeme, auf denen PHP eingesetzt wird. Dazu gehören nicht nur klassische Webserver, sondern auch Container-Umgebungen, interne Anwendungen, Shop- und Content-Management-Systeme sowie Appliances oder Herstellerprodukte mit integrierter PHP-Komponente.
Besonders wichtig: Prüfen Sie, welche Systeme aus dem Internet erreichbar sind und wo PHP Webanfragen verarbeitet.
2. PHP patchen und nicht nur Anwendungen aktualisieren
Spielen Sie die Sicherheitsupdates für die PHP-Laufzeitumgebung zeitnah ein und prüfen Sie anschließend den tatsächlichen Versions- und Patchstand. Bei Linux-Distributionen ist dabei zu berücksichtigen, dass Sicherheitsupdates häufig über Backports bereitgestellt werden. Die Versionsnummer allein reicht deshalb nicht immer für eine Bewertung aus.
Bei containerisierten Anwendungen müssen Images aktualisiert und Container neu gebaut beziehungsweise ausgerollt werden. Bei Appliances oder Standardsoftware sollte geprüft werden, ob der jeweilige Hersteller aktualisierte Versionen oder Firmware bereitstellt.
3. Nicht patchbare Systeme kurzfristig absichern
Wenn ein zeitnahes Update nicht möglich ist, sollte die externe Erreichbarkeit der betroffenen Systeme kritisch hinterfragt werden. Wo es technisch und organisatorisch möglich ist, empfehlen wir, öffentlich erreichbare verwundbare Systeme bis zur Aktualisierung vorübergehend vom Internet zu trennen oder den Zugriff deutlich einzuschränken.
Web Application Firewall-Regeln können eine zusätzliche Schutzschicht sein. Sie dürfen aber nicht dazu führen, dass notwendige Updates verschoben werden: Die nachhaltige Behebung erfolgt ausschließlich über den Patch.
4. Auffälligkeiten im Blick behalten
Nach einem kritischen Sicherheitshinweis sollten Logs, Monitoring und Alarmierungen besonders aufmerksam geprüft werden. Konzentrieren Sie sich dabei auf öffentlich erreichbare Webserver, auffällige Anfragen, ungewöhnliche Prozessstarts, Änderungen an Dateien oder Konfigurationen sowie unerwartete Netzwerkverbindungen.
Was Unternehmen daraus langfristig mitnehmen sollten
Akute Sicherheitslücken lassen sich nicht vollständig verhindern. Entscheidend ist, ob ein Unternehmen sie schnell erkennen, bewerten und beheben kann. Dafür braucht es belastbare Grundlagen.
Ein aktives Patchmanagement sollte deshalb nicht erst bei kritischen Meldungen beginnen. Es braucht klare Zuständigkeiten, einen aktuellen Überblick über Systeme und Softwarestände sowie etablierte Prozesse für Bewertung, Test und Ausbringung von Sicherheitsupdates. Gerade bei öffentlich erreichbaren Anwendungen sollten kritische Patches priorisiert und kurzfristig ausgerollt werden können.
Ebenso wichtig ist es, nicht auf End-of-Life-Softwareständen zu bleiben. Nicht mehr unterstützte PHP-Versionen erhalten regulär keine Sicherheitsupdates mehr. Zwar können in Einzelfällen Backport-Patches verfügbar sein – sie ersetzen jedoch keine langfristige Migrationsstrategie. Wer auf unterstützte Versionen setzt, reduziert Risiken und schafft die Voraussetzung, künftig schnell und planbar auf Sicherheitsupdates reagieren zu können.
Ergänzend empfehlen wir, öffentlich erreichbare Anwendungen auf das notwendige Maß zu beschränken, Systeme konsequent zu härten und Sicherheitsmechanismen wie Web Application Firewalls, Netzwerksegmentierung sowie restriktive Berechtigungen als zusätzliche Schutzschichten zu nutzen.
