php2shell: Wie wir PHP-Shops und Websites mit KI in Rekordzeit geschützt haben
Zwei kritische Sicherheitslücken im PHP-Kern (CVSS 9.2) – und warum im Ernstfall schnelle Entscheidungen, saubere Härtung und KI-Einsatz den Unterschied machen
-
von Philipp Sprecher
php2shell: Wenn der PHP-Kern wackelt, zählt im E-Commerce jede Minute
Fast 70 % aller Websites weltweit basieren auf PHP – von Content-Plattformen unter WordPress oder TYPO3 bis hin zu umsatzkritischen B2C- und B2B-Webshops auf Magento und WooCommerce. Am 21. Oktober 2026 sorgten zwei kritische Schwachstellen unter dem Namen php2shell (CVE-2026-109618 und CVE-2026-109619) mit einem Schweregrad von CVSS 9.2 für höchste Alarmstufe: Über präparierte Anfragen liessen sich ungepatchte PHP-Server ohne Login aus der Ferne übernehmen.
Die Reaktionen im Markt fielen drastisch aus: Grosse E-Commerce- und Web-Hoster wie Maxcluster oder Cyon nahmen PHP-Dienste und ganze Online-Shops vorsorglich für eine bis mehrere Stunden vom Netz; in den Niederlanden schalteten selbst staatliche Stellen und das nationale Cyber Security Centre ihre Websites vorübergehend ab. Bei insign liefen ab den ersten Vorwarnungen Systemtechnik, Entwicklung und Kundenbetreuung Hand in Hand, um die Plattformen und Webshops unserer Kunden gezielt abzusichern.
Was hinter CVE-2026-109618 und CVE-2026-109619 steckt – und warum KI der Auslöser war
Das Tückische an php2shell: Der Fehler liegt nicht in einem veralteten Plugin oder unsauberem Projektcode, sondern tief im Sprachkern von PHP selbst (betroffen sind sämtliche Versionen ab PHP 5.4). Vereinfacht gesagt gerät PHP beim Aufräumen nach einem Speicherüberlauf (Out-of-Memory) oder bei bestimmten Skriptfehlern aus dem Tritt. Nachfolgende Anfragen können dadurch fremde Speicherbereiche wie Sitzungen oder Passwörter auslesen und eigenen Schadcode direkt auf dem Server ausführen.
Die zugrunde liegende Schwachstelle schlummerte über ein Jahrzehnt im Code, weil ein verlässlicher Exploit über verschiedene PHP-Versionen hinweg früher monatelange Spezialistenarbeit erfordert hätte. Genau diese Schutzmauer aus Komplexität ist durch Frontier-KI-Modelle gefallen: Sicherheitsforschern gelang es mithilfe moderner LLMs in rund einer Woche, funktionierende Exploits zu entwickeln – und erste automatisierte Angriffswellen rollten bereits Stunden vor der offiziellen Patch-Veröffentlichung an.
Unser Einsatz bei insign: PHP-Shops patchen, Read-Only-Härtung & proaktive Kundenbetreuung
Gerade im E-Commerce und bei stark frequentierten Portalen ist ein pauschales Abschalten über viele Stunden oft die schlechteste Option – etwa wenn laufende Kampagnen auf Google Ads aktiv sind oder Kundenbestellungen laufen. Deshalb haben wir am 21. Oktober mehrspurig gehandelt:
- Aktive Kundenberatung & massgeschneiderte Sofortmassnahmen: Im direkten Austausch mit unseren Kunden haben wir pro Projekt entschieden, ob ein kurzes Wartungsfenster, ein kontrolliertes Pausieren von Hintergrundprozessen oder eine sofortige Read-Only-Härtung bei voller Erreichbarkeit der Website der richtige Weg ist.
- Gezielter Read-Only-Schutz statt Downtime: Wo ein unmittelbares PHP-Upgrade (z. B. bei älteren Bestandsplattformen) nicht in Minuten möglich war, haben wir auf Webserver-Ebene sämtliche schreibenden Zugriffe (Blockieren aller Methoden ausser GET/HEAD bzw. multipart/form-data) unterbunden und die PHP-Konfiguration (session.upload_progress.enabled = 0 sowie session.use_strict_mode = 1) sofort gehärtet.
- Priorisiertes Patching unserer PHP-Shops & Serverflotte: Sobald die offiziellen Sicherheits-Releases (PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35) sowie die ersten Repository-Backports verfügbar waren, hat unser Sysadmin- und Dev-Team die betreuten Magento- und WooCommerce-Shops, Konfiguratoren und Content-Portale systematisch aktualisiert und auf volle Funktionsfähigkeit im Checkout geprüft.
- KI als «Maschinenraum-Crew» in der Verteidigung: Was Angreifern hilft, nutzen wir bei insign noch konsequenter in der Defensive. Mithilfe von KI-Agenten konnten wir innert Minuten komplette Server-Inventare erstellen, komplexe Attack-Vector-Assessments (bis hin zum Aufspüren verwundbarer Neben-Container wie älterer Filemanager oder Datenbank-Oberflächen unter mod_php) durchführen, Härtungsskripte vorbereiten und unsere Kunden transparent informieren.
Checkliste: Was Betreiber von Webshops und Websites jetzt prüfen müssen
Falls Ihre Website oder Ihr Online-Shop nicht bereits durch das Hosting- und SLA-Team von insign betreut wird, empfehlen wir dringend folgende Sofortprüfung:
- PHP-Version verifizieren: Stellen Sie sicher, dass mindestens PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 im Einsatz ist – sowohl für den Webserver (FPM / Apache) als auch in Docker-Containern.
- Altsysteme (PHP 8.1 und älter) absichern: Ältere PHP-Zweige erhalten keine regulären Updates der PHP Foundation mehr. Hier sind verifizierte Distributions-Backports (z. B. Sury / Ubuntu ESM), strikte Read-Only-/WAF-Regeln als Überbrückung und ein zeitnahes System-Upgrade zwingend.
- Versteckte Subdomains & Admin-Tools prüfen: Vergessen Sie keine Neben-Instanzen wie ältere phpMyAdmin-Oberflächen, Dateimanager oder Staging-Systeme, die öffentlich erreichbar sind – besonders wenn dort noch Apache mod_php läuft.
- Temporäre Härtung ersetzt keinen Patch: Einstellungen wie das Deaktivieren von Upload-Progress oder Cloudflare-Regeln verschaffen wertvolle Zeit, ersetzen aber niemals das Einspielen der gepatchten PHP-Version.
Sicherheit im Webbetrieb: Ihr Partner für E-Commerce, Hosting & SLA
Der Vorfall rund um php2shell zeigt exemplarisch: Das Zeitfenster zwischen dem Bekanntwerden einer kritischen Sicherheitslücke und automatisierten Massenangriffen schrumpft durch KI von Wochen auf wenige Stunden. Einen ausführlichen technischen Hintergrundbericht unseres CTOs Martin Bachmann zur Rolle der KI bei php2shell lesen Sie auch im Blog unseres Schwesterunternehmens Evoya AI.
Sie möchten sicherstellen, dass Ihr Webshop, Ihr Kundenportal oder Ihre Website im Ernstfall nicht stundenlang stillsteht, sondern proaktiv überwacht, gehärtet und aktualisiert wird? Unser Team für Support & Wartung sowie Hosting & Infrastruktur unterstützt Sie gerne.
Häufige Fragen zur PHP-Sicherheitslücke php2shell
Grundsätzlich sind alle PHP-Versionen seit PHP 5.4 betroffen. Offiziell behoben sind die beiden kritischen Sicherheitslücken in den Versionen PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für ältere Versionen (PHP 8.1 und darunter) stehen ausschliesslich spezialisierte Backports bestimmter Linux-Distributionen oder ein System-Upgrade zur Verfügung.
Für die Ausnutzung von php2shell müssen Angreifer präparierte Daten (insbesondere über POST-Anfragen und Datei-/Session-Uploads) an den Server senden. Durch das Blockieren aller HTTP-Methoden ausser GET und HEAD sowie das Deaktivieren von session.upload_progress.enabled bleibt eine Website für Besucher und laufende Google-Ads-Kampagnen weiterhin erreichbar, während der Angriffsvektor bis zum Einspielen des Patches blockiert wird.
Da funktionierende Exploits bereits vor der offiziellen Veröffentlichung der PHP-Updates im Umlauf waren und Angriffe vollautomatisiert ohne Login erfolgen konnten, haben viele Hosting-Anbieter ihre PHP-Dienste vorsorglich angehalten, bis die neuen PHP-Pakete kompiliert und ausgerollt waren.
Im Rahmen unserer Support- und Wartungsverträge (SLA) überwachen wir betreute Systeme proaktiv, erstellen mithilfe von KI-gestützten Diagnosen sekundenschnell Gefährdungsanalysen, spielen Sicherheits-Patches priorisiert ein und stimmen Überbrückungsmassnahmen eng mit unseren Kunden ab. Kontaktieren Sie uns gerne für ein unverbindliches Gespräch.
letzte 3 Blog-Beiträge
