KI-Hacking ist Realität: Was PHP2Shell und Node2Shell für Ihre IT-Sicherheit bedeuten

„Wir sind gut aufgestellt: Die Firewall läuft, die Backups sind aktuell, Updates spielen wir regelmäßig ein.“ Diesen Satz hören Geschäftsführer und IT-Verantwortliche oft. Lange war er eine solide Antwort. Der 21. Oktober 2026 hat gezeigt, wo seine Grenzen liegen.

An diesem Tag wurden zwei kritische Sicherheitslücken öffentlich, die tief im Fundament des Webs stecken: PHP2Shell in der Programmiersprache PHP und Node2Shell in der Kompressionsbibliothek Brotli. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) gab für PHP2Shell die Warnstufe 3 (Orange) aus. Weltweit nahmen Behörden, Kliniken und Unternehmen ihre Websites vorsorglich vom Netz.

In Deutschland waren unter anderem Seiten der Thüringer Staatskanzlei und der Landespolizei betroffen, ebenso das Stadtportal bremen.de und mainz.de. International gingen etwa Regierungsseiten in den Niederlanden und Finnland zeitweise offline.

Für Entscheider zählt vor allem ein Detail: Beide Lücken haben Sicherheitsforscher mithilfe von KI-Modellen gefunden. Das verändert, wie schnell aus einem unscheinbaren Fehler ein echtes Risiko wird.

Was ist passiert?

Die Endung „2Shell“ steht inzwischen für eine besonders gefährliche Art von Lücke: Ein Angreifer schickt von außen eine präparierte Anfrage an den Server und kann darüber eigenen Code ausführen. Ein Passwort oder einen Login braucht er dafür nicht. Ende 2025 sorgte React2Shell in React- und Next.js-Anwendungen für Aufsehen; Anfang 2026 registrierten Sicherheitsfirmen dafür täglich 300.000 bis 400.000 Angriffsversuche.

Im Oktober 2026 folgten zwei weitere:

PHP2Shell (CVE-2026-109618 und CVE-2026-109619) steckt im Kern von PHP. Auf dieser Sprache laufen rund 70 Prozent aller Websites, darunter WordPress, TYPO3, Drupal, Joomla sowie viele Shops und Kundenportale. Über eine manipulierte Upload-Anfrage kann ein Angreifer den Arbeitsspeicher des Servers auslesen, etwa Passwörter, Tokens und API-Schlüssel, und unter Umständen eigenen Code ausführen. Betroffen sind alle Versionen ab PHP 5.4.

Node2Shell (CVE-2026-111497, auch HTTP2Shell oder Broccoli2Shell genannt) steckt im Decoder von Brotli. Die von Google entwickelte Kompressionstechnologie macht Datenübertragungen im Web kleiner und schneller. Entdeckt wurde der Fehler in Node.js. Betroffen ist aber jede Software, die Brotli-Daten aus fremder Quelle entpackt: Python-Pakete, Bun, .NET-Anwendungen mit aktivierter Brotli-Dekomprimierung sowie HTTP-Server, -Clients und Proxys, die Brotli einbinden.

Gefährlich wird Node2Shell also dort, wo eine Anwendung komprimierte Daten von außen verarbeitet. Das können eingehende Anfragen sein oder Antworten fremder Server, die automatisch entpackt werden.

Beiden Lücken ist gemeinsam, dass der Fehler eine Ebene unter dem Code liegt, den Ihre Entwickler schreiben. Bei PHP2Shell greift der Angriff, bevor Ihre Anwendung überhaupt läuft. Auch sauber programmierte Software schützt dann nicht, solange die Laufzeitumgebung darunter veraltet ist.

Der Wendepunkt: KI macht alte Fehler ausnutzbar

Die Vorgeschichte von PHP2Shell zeigt, was sich verändert hat. Der Fehler steckte 14 Jahre im Code. 2024 bemerkte ein PHP-Kernentwickler die zugrunde liegende Schwäche, als er Funde aus einem externen Sicherheitsaudit behob. Weil niemand nachweisen konnte, dass sie ausnutzbar ist, blieb sie liegen.

Ende Juli 2026 nahm sich die Sicherheitsfirma Calif im Rahmen von OpenAIs Initiative „Patch the Planet“ den PHP-Code vor, mit dem KI-Modell GPT-5.6 Sol als Assistenten. Zwei Tage nach Beginn fanden die Forscher den ersten Auslöser, gut zwei Wochen nach dem Start lag ein funktionierender Angriff als Beweis vor. Unabhängig davon fand das Team von Wiz dieselben Lücken, ebenfalls mit KI-Werkzeugen. Die Brotli-Lücke meldeten Forscher von OpenAIs Codex Security.

Wichtig ist die Rollenverteilung: Keine KI ist hier selbstständig auf Fehlersuche gegangen. Erfahrene Forscher haben gezielt gesucht, die KI hat ihnen Kleinarbeit abgenommen und den Nachweis der Ausnutzbarkeit stark beschleunigt. Laut den Forschern schrumpft so Arbeit, die früher Monate dauerte, auf wenige Tage.

Das hat Folgen für alle, die Software betreiben. Fehler, die bisher als theoretisch, aber praktisch nicht ausnutzbar galten, müssen neu bewertet werden.

Ein Detail der Brotli-Lücke unterstreicht das. Die eigentliche Ursache war schon im Februar 2026 im öffentlichen Quellcode behoben. Nur hatte niemand erkannt, dass es um eine Sicherheitslücke ging, und ein offizielles Update erschien erst im Oktober.

Wer ältere Code-Änderungen mit KI-Werkzeugen gezielt durchsucht, kann solche stillen Korrekturen finden, lange bevor eine Warnung erscheint. Diesmal waren die Verteidiger zuerst da. Verlassen sollte man sich darauf nicht.

Wie schnell Angreifer heute reagieren

Bei PHP2Shell lief die koordinierte Veröffentlichung nicht nach Plan. Am 20. Oktober sickerten Details durch, und PHP musste die Updates vorziehen. Amazon beobachtete den ersten Angriffsversuch sogar schon am 17. Oktober, vier Tage vor dem Patch.

Nach der Veröffentlichung tauchten binnen Stunden weitere Angriffswerkzeuge auf, die sofort breit gegen Server im Netz eingesetzt wurden. Die meisten dieser frühen Versuche scheiterten allerdings, denn die Lücke ist technisch anspruchsvoll auszunutzen.

Am 24. Oktober gelangen Angreifern dann die ersten nachweislich erfolgreichen Einbrüche auf Testsystemen (Honeypots). Inzwischen führt die US-Cybersicherheitsbehörde CISA sowohl PHP2Shell als auch Node2Shell als aktiv ausgenutzte Lücken.

Für Unternehmen heißt das: Zwischen dem Bekanntwerden einer Lücke und den ersten Angriffen liegen heute Stunden statt Wochen. Manchmal beginnen die Angriffe sogar früher.

Drei Annahmen, die nicht mehr tragen

„Unsere Firewall regelt das.“ Eine klassische Netzwerk-Firewall sieht bei PHP2Shell nur eine gewöhnliche Upload-Anfrage. Web Application Firewalls und CDN-Anbieter haben zwar schnell Filterregeln für bekannte Angriffsmuster nachgeliefert. Das überbrückt die Zeit bis zum Update, ersetzt es aber nicht.

„Updates spielen wir einmal im Quartal ein.“ Wenn Angriffe wenige Stunden nach einer Veröffentlichung beginnen, ist ein starrer Wartungszyklus zu langsam. Sie brauchen einen Ablauf, mit dem kritische Sicherheitsupdates innerhalb von Stunden bis wenigen Tagen live gehen, ohne auf das nächste Wartungsfenster zu warten.

„Wir kümmern uns um unsere eigene Software.“ Moderne Anwendungen bestehen aus vielen Schichten: Betriebssystem, Laufzeitumgebung, Bibliotheken, Container-Images. Eine Bibliothek wie Brotli steckt oft unsichtbar in anderer Software, die ihre eigene Kopie mitbringt, und ein Update des Betriebssystems erreicht diese Kopien nicht. Wer nicht weiß, was in seinen Systemen steckt, kann im Ernstfall nicht sagen, ob er betroffen ist.

Was Sie jetzt konkret tun sollten

Falls noch nicht geschehen, sind das die wichtigsten Schritte:

Bestandsaufnahme machen. Wo laufen bei Ihnen PHP und Node.js? Denken Sie auch an Shops, Intranet, alte interne Tools und Systeme, die Dienstleister für Sie betreuen.
PHP aktualisieren auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Für PHP 8.1 und älter gibt es kein offizielles Update, hier hilft nur der Umstieg auf eine unterstützte Version. Ein Update von WordPress, TYPO3 und Co. allein genügt nicht.
Node.js und Brotli aktualisieren: Node.js auf 22.23.4, 24.22.1 oder 26.12.1, Brotli auf 1.0.10, 1.1.1 oder 1.2.1, die Python-Pakete auf Brotli 1.2.1 und brotlicffi 1.2.1.0. Für .NET hat Microsoft ein Notfall-Update veröffentlicht. Container-Images anschließend neu bauen und ausrollen.
Zugangsdaten erneuern. Waren Server vor dem Update angreifbar, tauschen Sie Passwörter, Tokens und API-Schlüssel aus, die dort im Arbeitsspeicher lagen.
Nach Spuren suchen, auch in Logs vor dem 21. Oktober. Warnzeichen sind auffällige Upload-Anfragen mit anschließenden Speicherfehlern, gehäufte HTTP-500-Fehler und Webserver-Prozesse, die unerwartet Programme starten.
Beim Hosting-Anbieter nachfragen. Lassen Sie sich bestätigen, dass die Updates installiert sind und nicht nur geplant.

Wie q23 Sie unterstützt

PHP2Shell und Node2Shell zeigen, dass sich Sicherheit zunehmend unterhalb der eigenen Anwendung entscheidet. Dabei unterstützen wir Sie konkret:

Betroffenheits-Check: Wir prüfen, welche PHP-, Node.js- und Bibliotheksversionen in Ihren Anwendungen und Containern tatsächlich laufen und ob Sie von PHP2Shell oder Node2Shell betroffen sind.
Modernisierung von Altsystemen: Läuft Ihre Anwendung noch auf PHP 8.1 oder älter, bringen wir sie auf eine unterstützte Version, damit sie wieder Sicherheitsupdates erhält.
Schnelle Sicherheitsupdates: Für von uns betreute Systeme spielen wir kritische Sicherheitsupdates ein, sobald sie verfügbar sind, statt auf das nächste Wartungsfenster zu warten.
Sicherheit ab dem ersten Tag: In neuen Projekten setzen wir auf gepflegte Versionen, eine automatische Prüfung der Abhängigkeiten und eine Architektur, in der eine einzelne Lücke nicht gleich das ganze System öffnet.

Fazit

PHP2Shell und Node2Shell werden nicht die letzten Lücken dieser Art bleiben. OpenAI-Präsident Greg Brockman rechnet in den kommenden Monaten mit vielen weiteren solchen Funden. Unternehmen sollten deshalb wissen, was in ihren Systemen läuft, und kritische Updates in Stunden statt in Quartalen einspielen können.

Sie sind unsicher, ob Ihre Systeme betroffen sind? Sprechen Sie uns an. Wir sagen Ihnen, wo Sie stehen und was zu tun ist.