Centraltec

AI ConsultingAI Development

php2shell und die Zero-Day-Welle: Die Sicherheitslücken im Oktober 2026

Eine kritische Lücke im PHP-Kern, eine Serie aktiv ausgenutzter Zero-Days in Perimeter-Geräten und erste Schwachstellen in den KI-Werkzeugen selbst – was dahintersteckt und was Unternehmen jetzt konkret tun sollten.

Illustration: ein orange glühender Riss zieht sich durch eine dunkle Serverhalle

Die vergangenen vier Wochen waren für Sicherheitsverantwortliche ungewöhnlich dicht. Drei Entwicklungen liefen gleichzeitig: eine kritische Lücke im Kern von PHP, die praktisch jeden Webserver betrifft. Eine Serie von Zero-Days in genau den Geräten, die das Firmennetz eigentlich schützen sollen. Und die ersten ernsthaften Schwachstellen in den KI-Werkzeugen, mit denen heute entwickelt wird.

Dieser Beitrag ordnet ein, was passiert ist, was davon wirklich dringend ist – und warum sich an der Geschwindigkeit, mit der all das abläuft, gerade etwas Grundsätzliches ändert.

php2shell: eine Lücke unterhalb der Anwendung

Am 21. Oktober 2026 hat das PHP-Projekt Patches für zwei Schwachstellen veröffentlicht, die unter dem Namen php2shell laufen: CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 Punkten nach CVSS bewertet. CVSS ist die branchenübliche Skala für die Schwere von Schwachstellen; alles ab 9,0 gilt als kritisch. Beide erlauben einem Angreifer aus dem Internet, ohne Zugangsdaten und ohne Mitwirkung eines Nutzers Befehle auf dem Webserver auszuführen. (CISA, BSI)

Der entscheidende Punkt ist, wo die Lücke sitzt. PHP verarbeitet die Daten einer eingehenden Anfrage, bevor die Erweiterungen initialisiert sind und bevor auch nur eine Zeile Anwendungscode übersetzt wurde. Die Schwachstelle liegt also unterhalb der Anwendung. Für die Praxis heißt das etwas Unangenehmes: Eine sorgfältig gepflegte, aktuell gehaltene Anwendung ist genau so verwundbar wie eine vernachlässigte. Weder ein sauberes Framework noch guter eigener Code helfen hier. (CrowdStrike)

Vereinfacht funktioniert der Angriff so: Der Angreifer schickt eine Anfrage, die PHP beim Verarbeiten absichtlich in eine Speichergrenze laufen lässt. PHP bricht ab – aber der Abbruch überspringt die Aufräumarbeiten. Zurück bleiben globale Zeiger, die auf bereits freigegebenen Speicher verweisen. Ein Zeiger ist eine Adresse im Arbeitsspeicher; wenn der Speicher dahinter wieder freigegeben wurde, der Zeiger aber bestehen bleibt, arbeitet das Programm anschließend mit fremden Daten weiter.

Genau das nutzt der zweite Schritt aus. Webserver bearbeiten viele Anfragen mit demselben Arbeitsprozess. Die nächste Anfrage desselben Angreifers belegt den freigewordenen Speicher mit selbst gewählten Inhalten – und PHP behandelt diese Inhalte dann als eigene interne Strukturen. Am Ende steht die Ausführung beliebiger Befehle mit den Rechten des Webservers. CrowdStrike hat nachgewiesen, dass eine einzige anonyme POST-Anfrage genügt, um einen Apache-Arbeitsprozess eine Shell starten zu lassen. (CrowdStrike, Wiz)

Die beiden CVEs unterscheiden sich darin, wie weit der Angriff reicht. CVE-2026-109618 spielt sich innerhalb einer einzigen Anfrage ab. CVE-2026-109619 braucht zwei Anfragen an denselben Arbeitsprozess und trifft vor allem Installationen mit dauerhaft laufenden Prozessen, klassisch Apache mit mod_php. Bei PHP-FPM wird ein Prozess, der schon beim Start scheitert, beendet – ein Abbruch mitten im Skript lässt ihn aber am Leben und damit angreifbar. (CrowdStrike)

Warum man den Angriff im Log nicht sieht

Für die Erkennung ist eine Eigenschaft besonders unangenehm: Der Angriff ist nahezu unsichtbar. Der Arbeitsprozess stürzt nicht ab, der Server antwortet mit einem normalen HTTP 200, und die Anwendungs-Logs enthalten nichts – weil nie Anwendungscode gelaufen ist.

Die einzige verlässliche Spur auf dem Server ist ein Eintrag im Fehlerlog des Webservers nach dem Muster „Allowed memory size of N bytes exhausted" in Verbindung mit „in Unknown on line 0". Dieser Zusatz Unknown on line 0 ist der eigentliche Hinweis: Er bedeutet, dass der Speicher schon vor dem Start des Skripts ausging. Genau das passiert bei einem Angriffsversuch – und sonst selten. (CrowdStrike)

Weitere Signale, auf die es sich zu achten lohnt:

Was jetzt zu tun ist

Patchen ist die einzige vollständige Abhilfe. Die korrigierten Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Wichtig: Nach dem Einspielen müssen alle Arbeitsprozesse neu gestartet werden, sonst laufen die alten weiter.

Drei Punkte werden in der Praxis gerne übersehen:

Erstens die Bestandsaufnahme. PHP steckt an Stellen, an die man zunächst nicht denkt. Seit Veröffentlichung der Patches melden auch Hersteller von Netzwerkkomponenten Verwundbarkeiten, weil PHP in ihren Produkten verbaut ist. Die Frage lautet also nicht nur „Welche Webserver betreiben wir?", sondern „In welchen Appliances, Management-Oberflächen und Fertigprodukten steckt PHP?". (BSI)

Zweitens die Altversionen. PHP 8.1 und älter werden nicht mehr gepflegt und bekommen keinen Patch. CISA empfiehlt, solche Systeme vom Netz zu nehmen, bis sie aktualisiert sind. Das klingt hart, ist angesichts der Angriffsfläche aber angemessen. (CISA)

Drittens die Web Application Firewall. Eine WAF – ein vorgeschalteter Filter, der verdächtige Anfragen blockiert – kann einen Teil der Versuche abfangen und ist als Überbrückung sinnvoll. Ein Ersatz für den Patch ist sie nicht, weil der Angriff unterhalb der Anwendungsebene stattfindet und sich in legitim aussehenden Anfragen verstecken lässt.

Wie die Lage sich tatsächlich entwickelt hat

Der zeitliche Ablauf dieser Lücke ist aufschlussreicher als die Lücke selbst.

Die PHP Foundation hatte das Projekt in ein Förderprogramm für Open-Source-Sicherheit eingebracht. Ende Juli begann die Sicherheitsfirma Calif mit einem Audit und fand binnen Tagen mehrere Wege zur Codeausführung. Am 11. August meldeten Calif und OpenAI unabhängig voneinander dieselbe Ursache. Wiz Research stieß mit eigenen Mitteln im August auf weitere Angriffswege. Grundlage war dabei ein Problem, dessen erste Anzeichen schon ein Audit aus dem Jahr 2024 gesehen hatte – damals fand niemand einen konkreten Weg zur Ausnutzung, und die Korrektur blieb liegen. (Wiz)

Dann ging es schnell:

Imperva hat die ersten 24 Stunden ausgewertet: 482.342 Anfragen, 122.311 Angriffs-Sitzungen, 21.998 betroffene Websites in 103 Ländern. Deutschland lag auf Platz vier der am häufigsten angegriffenen Standorte. Das Muster ist allerdings flach – im Schnitt knapp vier Anfragen pro Sitzung. Das ist breites, wahlloses Scannen, kein gezielter Angriff. (Imperva)

Und hier kommt die gute Nachricht, die man ebenso deutlich sagen sollte: Bisher ist kein erfolgreicher Einbruch über php2shell bestätigt. Sophos hatte am 22. Oktober einen erfolgreichen Fall gemeldet und diese Einschätzung wenige Stunden später zurückgezogen. Beobachtet wurden Scans, Fingerprinting, Versuche, Zugangsdaten aus .env-Dateien abzugreifen, und der versuchte Nachschub einer Mirai-Variante für DDoS-Angriffe – aber keine nachgewiesene Übernahme. Sophos' eigenes Angriffsteam beschreibt das Schreiben eines zuverlässigen Exploits als schwierig, selbst mit KI-Unterstützung. Das verschafft Zeit. Es ist keine Entwarnung: Mit genügend Aufwand werden funktionierende Exploits kommen. (Sophos, The Hacker News)

Die Perimeter-Geräte: hier wird tatsächlich eingebrochen

Während php2shell die Aufmerksamkeit bündelt, läuft parallel etwas, das weniger Schlagzeilen macht und in der Praxis gefährlicher ist. Seit Ende September wurde eine ganze Reihe von Lücken in Perimeter-Systemen bekannt – also in den Geräten am Übergang zwischen Internet und Firmennetz: VPN-Zugänge, Mail-Gateways, Fernwartung. Diese Geräte sind aus Angreifersicht ideal, weil sie per Definition aus dem Internet erreichbar sind und tief im Netz stehen.

Bei dieser Gerätekategorie gilt eine Regel, die beim Patchen oft untergeht: Erst prüfen, dann patchen. Wenn eine Lücke seit Wochen ausgenutzt wird, kann das Gerät längst kompromittiert sein, und ein Update entfernt die Spuren, nicht den Angreifer. CISA empfiehlt für die Citrix-Geräte ausdrücklich, vor dem Einspielen nach Hinweisen auf eine Kompromittierung zu suchen, forensische Spuren zu sichern, Logs auf ein zentrales System auszuleiten – lokale Logs werden schnell überschrieben – und im Verdachtsfall ein sauberes Backup einzuspielen und anschließend alle Geheimnisse zu wechseln: Passwörter, Schlüssel und Zertifikate. (CISA)

Die dritte Front: die KI-Werkzeuge selbst

Für alle, die mit KI-Assistenten entwickeln, kam im Oktober eine neue Kategorie dazu. Am 21. Oktober wurde eine Schwachstelle im MCP Inspector veröffentlicht, kurz darauf eine gleichartige im KI-Coding-Werkzeug OpenCode. MCP, das Model Context Protocol, ist die inzwischen verbreitete Schnittstelle, über die ein KI-Assistent externe Werkzeuge anbindet. (GitHub Security Advisory, The Hacker News)

Der Ablauf ist bemerkenswert simpel. Der entfernte MCP-Server antwortet auf die Verbindungsanfrage mit „nicht autorisiert" und nennt dabei eine Anmelde-Adresse seiner Wahl. Das Werkzeug öffnet diese Adresse automatisch im Browser. Unter Windows und WSL landet die Zeichenkette dabei innerhalb eines PowerShell-Befehls – und PowerShell wertet Ausdrücke der Form $(...) innerhalb von Anführungszeichen aus. Eine URL, die wie eine normale Adresse aussieht, wird so zum ausgeführten Befehl.

Entscheidend sind die Randbedingungen: Das passiert beim Verbinden. Kein Klick, keine Freigabe, kein Werkzeugaufruf, und das Sprachmodell ist an der Sache überhaupt nicht beteiligt. Der Server muss auch nicht bösartig gewesen sein, als man ihn eingetragen hat – die Nutzlast kommt zur Laufzeit in der Antwort, nicht aus der gespeicherten Konfiguration. Ein übernommener Server, eine abgelaufene Domain oder ein Tippfehler im Namen führen zum selben Ergebnis. macOS und Linux sind nicht betroffen. (GitHub Security Advisory)

Die Abhilfe: MCP Inspector auf 2.12.0 aktualisieren, OpenCode auf 1.18.33. Wer nicht sofort aktualisieren kann, sollte alle nicht geprüften entfernten MCP-Server aus der Konfiguration entfernen.

Ein Detail daran verdient Beachtung, weil es ein allgemeines Muster zeigt: Die eigentliche Ursache liegt in einer weit verbreiteten Hilfsbibliothek zum Öffnen von Links. Behoben ist das Problem dort in der nächsten Hauptversion – nur verweisen die betroffenen Projekte auf einen Versionsbereich, der diese Hauptversion niemals automatisch einbezieht. Ein routinemäßiges Update hätte die Lücke also nicht geschlossen. (GitHub Security Advisory)

Unabhängig davon zeigt eine Mitte Oktober veröffentlichte Untersuchung, wie belastbar die zweite MCP-Angriffsfläche ist: Werkzeugbeschreibungen. Weil ein Modell anhand dieser Beschreibungen entscheidet, welches Werkzeug es aufruft, lassen sich dort Anweisungen verstecken. Die Studie erreicht über verschiedene Modell-Server-Kombinationen Erfolgsquoten zwischen 63 und 100 Prozent, bei gleichzeitig unveränderter Erledigung der eigentlichen Aufgabe – der Nutzer merkt also nichts. Drei getestete Schutzmaßnahmen senkten die Quote nicht unter 55 Prozent. (ACM)

Die praktische Konsequenz: Ein MCP-Server ist eine Software-Lieferkette, kein Plug-in. Er gehört inventarisiert, auf eine freigegebene Liste gesetzt und versioniert wie jede andere Abhängigkeit.

Warum die Zahl der Lücken gerade steigt

Hinter all dem steht eine Verschiebung, die sich in den Zahlen des BSI ablesen lässt. Im ersten Quartal 2026 wurden 10.803 Schwachstellen bekannt, im zweiten Quartal bereits 17.539 – ein Anstieg um gut 60 Prozent innerhalb von drei Monaten. Das BSI nennt als möglichen Grund ausdrücklich die KI-gestützte Schwachstellensuche. (BSI)

php2shell ist dafür das Lehrstück. Das zugrunde liegende Problem war 2024 schon einmal gestreift worden. Was fehlte, war der Nachweis, dass es sich tatsächlich ausnutzen lässt – und ohne diesen Nachweis blieb die Korrektur liegen. Wiz beschreibt den nötigen Beweis als eine außergewöhnlich komplexe Kette von Schritten, an der Grenze dessen, was menschliche Forscher praktisch leisten können; aktuelle KI-Modelle hätten diese Hürde deutlich gesenkt. (Wiz)

Man sollte daraus allerdings nicht die falsche Geschichte machen. Was hier passiert ist, ist zunächst ein Erfolg der Verteidigung: Drei Gruppen haben eine seit Jahren schlummernde Lücke gefunden und über zweieinhalb Monate koordiniert mit dem PHP-Projekt und den großen Cloud- und CDN-Anbietern einen Patch vorbereitet. Auf der Angreiferseite steht dem bisher gegenüber: viel automatisiertes Scannen, aber kein funktionierender Exploit in freier Wildbahn.

Was sich dagegen messbar verändert hat, ist das Zeitfenster. Zwischen dem Erscheinen des Patches und Zehntausenden Angriffsversuchen lagen 45 Minuten. Die CVE-Nummern waren schon einen Tag vorher durchgesickert, ein Ausnutzungsversuch sogar vier Tage vorher zu sehen. Wer sein Patch-Management auf einen monatlichen Wartungstermin ausrichtet, arbeitet gegen eine Uhr, die inzwischen anders tickt.

Was das für das eigene Vorgehen heißt

Sechs Punkte, die sich aus diesem Oktober ableiten lassen:

  1. Internet-erreichbare Systeme zuerst. Nicht der CVSS-Wert entscheidet über die Reihenfolge, sondern die Erreichbarkeit. Eine 9,8 im internen Netz ist weniger dringend als eine 8,6 am Perimeter.
  2. Eine aktuelle Inventarliste ist die halbe Reaktion. Die erste Frage nach jeder Meldung lautet „Wo läuft das bei uns?". Wer darauf nicht innerhalb einer Stunde antworten kann, verliert den entscheidenden Teil des Zeitfensters.
  3. Komponenten mitdenken, nicht nur Produkte. php2shell betrifft Appliances, deren Hersteller PHP eingebaut haben. Eine Software-Stückliste (SBOM) ist dafür das passende Werkzeug.
  4. Bei Perimeter-Geräten vor dem Patch auf Kompromittierung prüfen und Geheimnisse danach rotieren. Das Update allein beseitigt einen bereits vorhandenen Angreifer nicht.
  5. Erkennung dort aufbauen, wo der Angriff sichtbar ist. Bei php2shell ist das nicht das Anwendungs-Log, sondern das Verhalten auf dem Host: PHP-Prozesse, die Shells starten, und die beschriebene Fehlermeldung im Server-Log.
  6. KI-Werkzeuge in die Patch-Routine aufnehmen. Coding-Assistenten, MCP-Server und Agent-Frameworks sind produktive Software mit Zugriff auf Quellcode und Zugangsdaten. Sie gehören in dieselbe Inventarliste wie alles andere.

Unsere Sicht bei Centraltec

Wir beraten Unternehmen beim Einsatz von KI – und genau deshalb interessiert uns dieser Oktober. Er zeigt beide Seiten derselben Entwicklung: KI findet Schwachstellen, die jahrelang übersehen wurden, und KI-Werkzeuge bringen selbst neue Angriffsflächen mit.

Praktisch heißt das für Projekte, die wir begleiten: Jeder Assistent, der Dateien liest, Befehle ausführt oder externe Dienste anbindet, bekommt dieselbe Behandlung wie eine produktive Komponente – Inventar, Freigabeliste, Versionsstand, nachvollziehbare Rechte. Und jede Brücke nach außen, ob Package-Cache, Browser-Werkzeug oder MCP-Server, wird als Angriffsfläche geplant und nicht als Zubehör.

Wer gerade prüft, wie die eigene Lage aussieht, fängt am besten bei zwei Fragen an: Welche unserer PHP-Installationen sind aus dem Internet erreichbar und auf welchem Stand sind sie? Und welche MCP-Server und KI-Werkzeuge greifen heute auf unsere Entwicklungsumgebungen zu?

← Zurück zu News

php2shell und die Zero-Day-Welle: Die Sicherheitslücken im Oktober 2026 | Centraltec