Warum die Lage kritisch ist
Unter der Bezeichnung „PHP2Shell“ werden die Schwachstellen CVE-2026-109618 und CVE-2026-109619 zusammengefasst. Beide erreichen im Bewertungssystem CVSS v4.0 einen kritischen Wert von 9,2 von 10. Sie können es nicht authentifizierten Angreifern ermöglichen, aus der Ferne eigenen Code auf einem betroffenen Server auszuführen – ohne vorherige Anmeldung und potenziell noch bevor der eigentliche Anwendungscode einer Website greift.
Betroffen sind laut dem PHP-Projekt grundsätzlich alle PHP-Installationen, die Webanfragen verarbeiten. Sicherheitsupdates stehen mit PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 bereit. PHP 8.1 und ältere Versionszweige werden vom PHP-Projekt nicht mehr regulär unterstützt; hier sind gegebenenfalls Hersteller- oder LTS-Backports beziehungsweise die Migration auf eine unterstützte Version erforderlich.
Technischer Hintergrund
Die erste Schwachstelle betrifft die Behandlung von Speicherengpässen: Wird PHP in einem ungünstigen Moment durch einen „Out-of-Memory“-Zustand unterbrochen, können interne Daten einer Anfrage nur teilweise initialisiert sein. Bei der anschließenden Bereinigung kann PHP diese ungültigen Daten fälschlich als gültig behandeln – mit möglicher Speicherbeschädigung und Ausführung fremden Codes.
Bei der zweiten Schwachstelle kann anfragebezogener interner Zustand erhalten bleiben, obwohl der zugrunde liegende Speicher bereits freigegeben wurde. Eine spätere Anfrage desselben Worker-Prozesses kann auf diesen veralteten Zustand zugreifen. Besonders gefährlich ist, dass damit die Sicherheitslücke in der PHP-Laufzeit selbst liegt – ein Update von WordPress, TYPO3 oder einer anderen Webanwendung allein genügt daher nicht.
Gelingt die Ausnutzung, läuft der eingeschleuste Code zunächst mit den Rechten des Webserver- beziehungsweise PHP-Prozesses. Daraus können – abhängig von Systemkonfiguration, Berechtigungen und Segmentierung – Datendiebstahl, Manipulation von Websites, Installation von Schadsoftware, Missbrauch des Servers für weitere Angriffe und Betriebsunterbrechungen entstehen.
Risiken für Unternehmen
Für Unternehmen reicht das Schadensbild weit über den Ausfall einer Website hinaus:
-
Vertraulichkeit: Kunden-, Mitarbeiter-, Vertrags- oder Zugangsdaten können offengelegt werden.
-
Integrität: Inhalte, Datenbanken und Transaktionen können manipuliert werden.
-
Verfügbarkeit: Webshops, Kundenportale und digitale Dienstleistungen können ausfallen oder vorsorglich abgeschaltet werden.
-
Folgeschäden: Ein kompromittierter Server kann als Ausgangspunkt für laterale Bewegungen, Erpressung oder Angriffe auf Dritte dienen.
-
Haftung und Reputation: Datenschutzverletzungen, Benachrichtigungs- und Meldepflichten, Wiederherstellungskosten sowie Vertrauensverlust können den technischen Erstschaden deutlich übersteigen.
Der Vorfall betrifft nicht nur klassische Websites. PHP ist auch in Appliances, Netzwerkprodukten, Administrationsoberflächen und eingebetteten Laufzeitumgebungen enthalten, bei denen Unternehmen den Patch häufig nicht selbst einspielen können. Damit rücken Software-Lieferketten und die Reaktionsfähigkeit von Herstellern, Hostern und IT-Dienstleistern in den Mittelpunkt.
Globaler Infrastruktur-Effekt
PHP bildet die technische Grundlage zahlreicher Content-Management-Systeme, Onlineshops, Portale und Fachanwendungen. Das BSI nennt unter anderem WordPress, Drupal, TYPO3, Joomla, Magento, Nextcloud, pfSense und OPNsense als Beispiele für PHP-basierte Projekte und warnt vor breit angelegten Angriffskampagnen auf unterschiedlichste Anwendungsbereiche.
Genau darin liegt der globale Impact solcher Schwachstellen: Ein Fehler in einer weitverbreiteten Basistechnologie schafft gleichzeitig Angriffsfläche in vielen Branchen und Ländern. Sobald technische Details oder Proof-of-Concepts öffentlich werden, verkürzt sich das Zeitfenster zwischen Veröffentlichung und automatisierter Ausnutzung drastisch; CERT-EU berichtete bereits kurz nach Freigabe der Patches von zirkulierenden ersten Proof-of-Concepts. Vorsorgliche Abschaltungen durch Betreiber zeigen zugleich, dass selbst eine erfolgreiche Abwehr wirtschaftliche Folgen haben kann: Sicherheit wird kurzfristig durch Nichtverfügbarkeit erkauft.
Was zu tun ist
Unternehmen sollten unverzüglich:
-
sämtliche PHP-Instanzen inventarisieren – einschließlich Container, Cloud-Images, Appliances und fremdbetriebener Systeme;
-
die PHP-Laufzeit auf eine korrigierte Version aktualisieren oder bestätigte Hersteller-Backports einspielen;
-
den tatsächlichen Patchstand technisch verifizieren und PHP-Worker beziehungsweise betroffene Dienste kontrolliert neu starten;
-
ungepatchte, internetseitig erreichbare Systeme erforderlichenfalls isolieren oder vorübergehend vom Netz nehmen;
-
Logs, Prozesse, Dateien, Benutzerkonten und ausgehende Verbindungen auf Auffälligkeiten prüfen und bei Verdacht die Incident-Response-Prozesse aktivieren;
-
von Hostern und IT-Dienstleistern einen dokumentierten Nachweis über Betroffenheit, Patchstatus und Kompromittierungsprüfung verlangen.
Temporäre Maßnahmen wie das Deaktivieren von session.upload_progress, restriktive Upload-Limits, Web-Application-Firewalls oder zusätzliche Speicherbegrenzungen können einzelne Angriffspfade erschweren. Sie ersetzen das Update jedoch nicht: Das PHP-Projekt bezeichnet nur die Aktualisierung als vollständige Lösung; ist diese nicht sofort möglich, empfehlen BSI und CERT-EU die Isolation exponierter Systeme.

PHP-Shell Infografik (generiert mit Google Gemini)
Erste erfolgreiche Angriffe
Erste erfolgreiche Ausnutzungen der PHP-Lücken sind inzwischen auf Lockservern, sogenannten Honeypots, dokumentiert; zugleich sind weiterhin zahlreiche Server ungeschützt. Im nächsten Newsletter greifen wir das Thema nochmals detailliert auf und ergänzen aktuelle Zahlen zum Ausmaß der Gefährdung, zum Patch-Fortschritt und zu bekannt gewordenen Angriffen.
Bedeutung für Cyber-Versicherungen
Für Versicherungsmakler bietet der Vorfall einen konkreten Gesprächseinstieg in drei Ebenen des Cyber-Risikomanagements:
-
Prävention: Gibt es ein vollständiges Asset-Inventar, verbindliche Patch-Fristen, einen Prozess für kritische Zero-Day-Lücken und klare Zuständigkeiten zwischen Unternehmen, Hoster und IT-Dienstleister?
-
Reaktion: Sind Forensik, Krisenkommunikation, Datenschutzberatung, Wiederherstellung und externe Incident-Response-Leistungen rund um die Uhr verfügbar?
-
Risikotransfer: Deckt der Vertrag insbesondere Betriebsunterbrechung, Datenwiederherstellung, IT-Forensik, Haftpflichtansprüche, Datenschutzverfahren und – soweit vereinbart – Cyber-Erpressung angemessen ab?
Dabei sollte klar kommuniziert werden: Eine Cyber-Versicherung ersetzt weder Updates noch organisatorische Mindeststandards. Verspätetes Patchen, nicht unterstützte Software und fehlende Inventarisierung können den Schaden vergrößern und zu Deckungsprobleme führen. Welche Folgen tatsächlich eintreten, hängt stets vom konkreten Bedingungswerk, den vorvertraglichen Anzeigen und dem Einzelfall ab.
PHP2Shell ist damit mehr als eine technische Warnmeldung. Der Fall macht sichtbar, wie stark Unternehmen von unsichtbaren Softwarekomponenten und externen Dienstleistern abhängen – und warum wirksamer Cyber-Schutz nur aus dem Zusammenspiel von Prävention, belastbarer Notfallorganisation und passendem Versicherungsschutz entsteht.