Zwei Schwachstellen im PHP-Kern können eine nicht authentifizierte Remote-Code-Ausführung ermöglichen. Die Patches sind verfügbar, erste Angriffsversuche wurden gemeldet. Für Betreiber entscheidet sich die Reaktionsfähigkeit nun daran, ob sie exponierte PHP-Systeme vollständig kennen – einschließlich der Instanzen, die in Drittprodukten stecken.

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) stuft die Lage mit Warnstufe 3 „Orange“ als außerordentlich hoch ein. Betroffen sind die Schwachstellen CVE-2026-109618 und CVE-2026-109619, zusammen als „PHP2Shell“ bezeichnet. Beide ermöglichen unter bestimmten Bedingungen, dass Angreifer aus der Ferne und ohne Anmeldung Schadcode auf einem verwundbaren Webserver ausführen.

Die Fehler liegen in der PHP-Engine. Deshalb hängt das Risiko nicht davon ab, ob der Anwendungscode eines Shops oder Portals selbst fehlerhaft ist. Verwundbar können auch Anwendungen sein, deren eigener Code keine bekannte Schwachstelle aufweist, sofern sie eine betroffene PHP-Laufzeit verwenden. Das betrifft potenziell auch Installationen von Magento, Shopware oder WooCommerce.

Die beiden CVEs gehen auf unterschiedliche Fehlerzustände zurück. CVE-2026-109618 betrifft einen Fehler bei der Behandlung eines Speicherengpasses. CVE-2026-109619 beruht auf einem veralteten globalen Zustand, der nach Freigabe des zugehörigen Speichers erneut verwendet werden kann – ein sogenannter Use-after-free-Fehler. In beiden Fällen kann die fehlerhafte Zustandsbehandlung zur Ausführung von Angreifercode führen.

Der CVSS-4.0-Wert von 9,2 signalisiert einen sehr hohen Schweregrad. Er ist jedoch kein Maß dafür, wie einfach jeder Angriff unter allen Betriebsbedingungen gelingt. Die Bewertung weist auch auf erhöhte Angriffskomplexität und bestimmte Voraussetzungen hin. Für Betreiber ändert das nichts an der Dringlichkeit: Internet-erreichbare Systeme mit verwundbarer PHP-Version müssen priorisiert behandelt werden.

Die Laufzeit muss systematisch erfasst werden

Nach Angaben des BSI sind bekannte PHP-Versionen bis mindestens PHP 5 betroffen. Gefährdet sind Installationen, die Webanfragen verarbeiten. Dazu gehören unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP Security Team bewertet das Risiko bei mod_php als besonders hoch.

Seit dem 21. Oktober sind korrigierte Versionen für PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 verfügbar. Für die nicht mehr unterstützten Zweige 7.4, 8.0 und 8.1 wurden Backport-Patches bereitgestellt. Für PHP 5 gibt es keine Patches. Betreiber älterer Systeme müssen deshalb prüfen, ob ihre Distribution oder ihr Anbieter eine unterstützte Korrektur liefert. Ein Versionssprung allein genügt nicht als Nachweis: Entscheidend ist, dass die tatsächlich eingesetzte Laufzeit den Fix enthält.

Die größere operative Hürde liegt häufig vor dem Patchen. PHP kann direkt auf einem Server installiert oder in einer Anwendung, Appliance oder einem Drittprodukt enthalten sein. Ein Asset-Verzeichnis, das nur eigenständig installierte PHP-Pakete erfasst, kann daher unvollständig sein.

Samuel Hassine, CEO und Mitbegründer von Filigran, beschreibt die Bestandsaufnahme als eigentliche Herausforderung. Organisationen müssten jedes System finden, auf dem PHP läuft, auch wenn die Laufzeit in Drittprodukten verborgen sei. Eine zeitweise Abschaltung könne dabei wirtschaftlich vertretbarer sein als ein längerer Betrieb unter akuter Gefährdung. Nach dem Update müsse außerdem untersucht werden, ob es während des Verwundbarkeitszeitraums zu einem Eindringen kam.

Patchen ist kein Abschluss

Cloudflare meldete erste Angriffe bereits vor der Veröffentlichung der Updates. Mit der Veröffentlichung technischer Details und funktionierenden Exploit-Codes wächst das Risiko automatisierter Scans und gezielter Ausnutzungsversuche. Ein beobachteter Angriff ist dabei nicht gleichbedeutend mit einer bestätigten Kompromittierung; er macht die Prüfung exponierter Systeme aber dringlicher.

Debrah Galea, Senior Product Marketing Manager bei Filigran, vergleicht PHP2Shell mit Log4Shell: Beide Fälle betreffen weit verbreitete Software und ermöglichen unter bestimmten Bedingungen eine nicht authentifizierte Remote-Code-Ausführung. Der Vergleich hat Grenzen. PHP ist häufig leichter als Technologiekomponente zu erkennen als eine tief eingebettete Java-Abhängigkeit. Zudem standen für mehrere aktuelle PHP-Zweige Updates bereit. Die nun öffentliche Exploit-Möglichkeit dürfte die technische Hürde für Angreifer jedoch senken.

Die Landeshauptstadt Mainz schaltete nach der Warnung vorsorglich mehrere städtische Internetdienste einschließlich des zentralen Portals ab. Eine solche Maßnahme reduziert die Erreichbarkeit, ersetzt aber weder die Behebung der Schwachstelle noch die spätere Prüfung. Wo ein zeitnahes Update nicht möglich ist, kann die temporäre Isolation eines Systems eine sinnvolle Schutzmaßnahme sein.

Die Reaktion muss über den Patch hinausgehen

Mathieu Rigotto, CISO bei Filigran, kritisiert die vorzeitige Veröffentlichung technischer Details vor dem offiziellen Patch. Eine koordinierte Offenlegung soll Verteidigern Zeit zur Vorbereitung geben, bevor Angreifer verwertbare Informationen erhalten. Nach der Veröffentlichung rücken für ihn drei Fragen in den Mittelpunkt: Welche PHP-Endpunkte sind tatsächlich aus dem Internet erreichbar? Wer ist für jedes dieser Systeme zuständig? Und welche Folgen hätte eine Kompromittierung – etwa für Kundendaten, Zugangsdaten oder als Einstieg in interne Netze?

Für Sicherheitsverantwortliche ergibt sich daraus ein konkreter Ablauf:

• Angriffsfläche erfassen: Internet-erreichbare Dienste von außen und PHP-Installationen innerhalb der Infrastruktur identifizieren. Drittprodukte und Appliances einbeziehen.
• Exposition priorisieren: Systeme mit direkter Internetanbindung und Installationen mit mod_php zuerst betrachten.
• Korrektur verifizieren: Updates einspielen und prüfen, ob die Laufzeit tatsächlich auf dem korrigierten Stand ist.
• Nicht patchbare Systeme isolieren: Für PHP 5 existiert kein Patch. Solche Systeme benötigen eine Übergangslösung, etwa eine Abschaltung oder eine wirksame Begrenzung der Erreichbarkeit.
• Auf Kompromittierung untersuchen: Systeme und Protokolle aus dem Verwundbarkeitszeitraum auf verdächtige Aktivitäten prüfen.

PHP2Shell testet damit nicht nur die Geschwindigkeit des Patch-Managements. Der Vorfall zeigt, ob Organisationen ihre exponierten Systeme, deren Verantwortliche und deren Bedeutung für den Geschäftsbetrieb bereits kennen. Erst diese Übersicht macht es möglich, Warnungen in priorisierte Maßnahmen zu übersetzen – und nach dem Patch festzustellen, ob die Gefahr tatsächlich eingedämmt ist.