KI greift an

Sicherheitslücken: schnelles Reagieren entscheidet

Von Gaspard Chevassus·Veröffentlicht am 23. Oktober 2026·5 Min. Lesezeit

Gouache-Malerei: drei umgedrehte Ruderboote auf Böcken am Seeufer, eines mit einem türkisfarbenen Flicken; im Wasser tragen drei Haifischflossen die Logos von Claude, OpenAI und Gemini.

Mitte Oktober 2026 wurden innert weniger Tage mehrere kritische Schwachstellen in Bausteinen veröffentlicht, die einen grossen Teil des Webs betreiben: Node.js, PHP, NGINX und der Linux-Kernel. Einige erlauben es, ohne jede Anmeldung Code auf einem Server auszuführen. Für eine produktive Anwendung entscheidet dann, wie schnell die Korrektur überall eingespielt ist.

Eine Woche Warnmeldungen, Oktober 2026

14. Okt.NGINXSpeicherfehlerFünf Schwachstellen behoben, eine davon in der HTTP/3-Unterstützung.
20. Okt.HTTP/3Denial of ServiceEine einzige Verbindung kann den Speicher eines Servers erschöpfen: 7 von 10 getesteten Implementierungen waren verwundbar.
21. Okt.Node.jsCodeausführungZehn Schwachstellen behoben, darunter eine Codeausführung aus der Ferne. Node.js 20 erhält keine Korrekturen mehr.
21. Okt.PHP «PHP2Shell»CodeausführungCodeausführung ohne Anmeldung, vorgeführt auf WordPress, Drupal und Magento. PHP betreibt 69 % der Websites mit bekannter serverseitiger Sprache.
21. Okt.Linux KSMBDCodeausführungZwei mit 9,0 von 10 bewertete Schwachstellen, veröffentlicht vor jeder Korrektur.
21. Okt.LiteLLMSchlüsseldiebstahlEine manipulierte Version dieser KI-Bibliothek wurde veröffentlicht, um API-Schlüssel zu stehlen.

Das Fenster zwischen Patch und Angriff hat sich geschlossen

Vor einigen Jahren brauchten Angreifer Wochen, um eine bekannte Lücke auszunutzen. Heute sind es Tage, und manchmal beginnt die Ausnutzung, bevor es eine Korrektur gibt.

Durchschnittliche Zeit bis zur Ausnutzung einer Schwachstelle, gemessen am Patch

63 Tage nach dem Patch in 2018–2019, fünf Tage im Jahr 2023. 2025 geht die Ausnutzung dem Patch im Durchschnitt um rund eine Woche voraus, gemäss einer Schätzung.

Im dritten Quartal 2026 hat Rapid7 zwischen der Veröffentlichung einer schweren Schwachstelle und ihrer Ausnutzung durchschnittlich drei Tage gemessen. Ein monatlicher Update-Rhythmus lässt also mehrere Wochen offen.

KI beschleunigt die Entdeckung von Schwachstellen

Modelle, die Code lesen können, finden Schwachstellen inzwischen in grossem Massstab. Anthropic hat laut seinem CVD dashboard über 6’000 Schwachstellen in Open-Source-Projekten gemeldet, und die am 21. Oktober behobene Node.js-Lücke wurde vom Team Codex Security von OpenAI gefunden. Angreifer nutzen dieselben Werkzeuge.

Die Wirkung der KI auf Schwachstellen im Jahr 2026

Veröffentlichte Schwachstellen pro Monat

Januar 20265’045August 202610’740

Ausgenutzte Schwachstellen pro Monat

Durchschnitt 202510,5Januar–August 202618

Anteil der Lücken mit Codeausführung aus der Ferne

Mit KI gefunden50 %Übrige Lücken26 %

Lücken werden auch früher öffentlich: Die Kernel-Dokumentation Security bugs verlangt inzwischen, jede mit KI gefundene Lücke als öffentlich zu behandeln, weil mehrere Forschende sie oft am selben Tag entdecken. Nur ein kleiner Teil der veröffentlichten Lücken wird tatsächlich ausgenutzt; entscheidend ist, die relevante schnell zu erkennen.

Anwendungen mit KI-Funktionen bringen eigene Risiken mit, etwa Prompt Injection LLM01 Prompt Injection oder eine kompromittierte Lieferkette LLM03 Supply Chain. Sie brauchen dieselbe Wartung wie der Rest der Anwendung.

Schnell und überall korrigieren

Eine Korrektur ist ein einziges Update. Die Arbeit besteht darin, sicherzustellen, dass sie jeden Ort erreicht, an dem die Software läuft, ohne etwas zu beschädigen.

Bewährte Praktiken bei einer kritischen Schwachstelle

1.Inventar erstellenAlles, was läuft, auch was die Administrationsoberfläche nicht zeigt: daneben gestartete Dienste, gestoppte Dienste, direkt auf dem Server installierte Software.
2.PriorisierenZuerst, was aus dem Internet erreichbar ist und was eine Lücke ohne Anmeldung erreichen kann.
3.Separat korrigierenEin Fix auf Basis der produktiven Version, ohne laufende Arbeiten. Dieselbe Änderung fliesst danach in die Entwicklungsversion ein.
4.Auch die Kopien abdeckenTest- und Staging-Umgebungen, Backups, Ersatzkopien. Ein gestoppter Dienst wird korrigiert, bevor er wieder startet.
5.Prüfen, was wirklich läuftDie tatsächlich ausgeführte Version, nicht die in der Konfiguration angegebene, danach der Zustand des Dienstes nach jeder Änderung.
6.ProtokollierenJede Aktion und ihr Ergebnis werden festgehalten. So lässt sich die Arbeit fortsetzen, erklären und rückgängig machen.

Schutz, bevor die Korrektur da ist

Wird eine Lücke vor ihrer Korrektur veröffentlicht, verschaffen mehrere Schutzebenen die Zeit, in Ruhe zu korrigieren.

Vier Schutzebenen rund um die Anwendung

So wenig wie möglich exponieren

Nur Dienste, die öffentlich sein müssen, sind erreichbar; die Administration läuft über einen privaten Zugang.

Automatisch aktualisieren

Sicherheitsupdates des Betriebssystems, Aktualisierungsvorschläge für Abhängigkeiten und regelmässige Kontrolle der laufenden Versionen.

Datenverkehr filtern

Eine Web Application Firewall blockiert bekannte Angriffe, bis die Korrektur da ist.

Schaden begrenzen

Minimale Rechte, schreibgeschützte Dateien und Erkennung auffälligen Verhaltens.

Ihre Anwendung

Gibt es noch keine Korrektur, wie bei den Lücken im Linux-Kernel dieser Woche, macht Fachwissen den Unterschied: prüfen, ob der verwundbare Dienst läuft und erreichbar ist, und ihn bis dahin abschalten oder seinen Zugang sperren.

Wartung macht Tempo möglich

Eine aktuelle Anwendung mit gepflegten Versionen lässt sich in wenigen Stunden korrigieren. Eine lange nicht gewartete Anwendung braucht zuerst eine Migration, manchmal eine riskante, bevor sie die Korrektur überhaupt erhalten kann. Das gilt für Anwendungen, die noch mit Node.js 20 laufen, das laut dem Plan Node.js Release sein Lebensende erreicht hat, oder mit PHP 7, das ebenfalls nicht mehr gepflegt wird.

Checkliste für Ihre Anwendungen

Inventar. Wissen Sie, wo jede Anwendung läuft, einschliesslich Testumgebungen, gestoppter Dienste und Backups?
Versionen. Kennen Sie die tatsächlich laufenden Versionen und das Ende ihres Supports?
Beobachtung. Wer erhält die Sicherheitsmitteilungen zu Ihren Technologien, und wer entscheidet über das weitere Vorgehen?
Deployment. Können Sie eine Korrektur allein in Produktion bringen, ohne laufende Arbeiten?
Prüfung. Kontrollieren Sie nach einem Update die aktive Version und den Zustand des Dienstes?
Notlösung. Können Sie einen verwundbaren Dienst isolieren, solange es keine Korrektur gibt?
KI-Funktionen. Haben Ihre Assistenten nur die nötigen Zugriffe, und lassen sich ihre Schlüssel rasch erneuern?

Wartung und Hosting

Wir warten und hosten die Anwendungen, die wir entwickeln, und können Anwendungen anderer Teams übernehmen. Wenn Sie wissen möchten, wo Ihre Anwendung bei diesen Risiken steht, schreiben Sie uns: Wir beginnen mit einem Inventar.

Quellen und Referenzen

18 QuellenNode.js · NGINX · FoxIO · PHP · Help Net Security · +10

Zeitraum	Durchschnittliche Zeit
2018–2019	63 Tage
2020 – Anfang 2021	44 Tage
2021–2022	32 Tage
2023	5 Tage
2025 (Schätzung)	7 Tage vorher

Sicherheitslücken: schnelles Reagieren entscheidet

Das Fenster zwischen Patch und Angriff hat sich geschlossen

KI beschleunigt die Entdeckung von Schwachstellen

Schnell und überall korrigieren

Schutz, bevor die Korrektur da ist

Wartung macht Tempo möglich

Checkliste für Ihre Anwendungen

Wartung und Hosting

Quellen und Referenzen

Passende Services

Ähnliche Artikel

Vibe-Code übernehmen: Leitfaden für CTOs und Entwickler

Vibe Coding: wann es hilft, wo seine Grenzen liegen und wann eine Agentur sinnvoll ist

Eine vibe-codierte App übernehmen, ohne von vorn zu beginnen