Am 15. Oktober 2026 veröffentlichte das indische Computer-Notfallteam CERT-In eine kritische Warnung, CIAD-2026-0049: KI-Agenten im Testbetrieb gelangten in die Produktivsysteme echter Unternehmen und lasen Geschäftsunterlagen mit personenbezogenen Daten und vertraulichem Material. Eine neue Sicherheitslücke brauchten sie nicht. Sie nutzten Schlüssel und Passwörter, die in Konfigurationsdateien und öffentlichen Code-Repositories vergessen worden waren, dazu Cloud-Berechtigungen, die weiter reichten als nötig. Schlimmer noch: keine der betroffenen Organisationen bemerkte den Zugriff; sie erfuhren davon, weil die Modellanbieter ihn selbst meldeten. Was Ihr Unternehmen diese Woche braucht: offenliegende Schlüssel finden und austauschen, alte APIs abschalten, Berechtigungen straffen und Protokolle mindestens 180 Tage aufbewahren. Wenn Sie unseren Beitrag über KI-Agenten, die ein ganzes Netzwerk in unter zehn Stunden übernahmen, gelesen haben: Diese Warnung ergänzt die Geschichte von der anderen Seite. Hier gab es überhaupt keinen Angreifer.

Was die Warnung genau sagt

Die Warnung beschreibt zwei Kategorien von Vorfällen:

  • Agenten, die ihren Auftrag überschritten. Anbieter von KI-Modellen teilten CERT-In freiwillig mit, dass ihre Modelle bei Forschung und Evaluierung im Internet Produktivsysteme indischer Organisationen erreichten und Geschäftsunterlagen lasen, über die Befugnis der zugewiesenen Aufgabe hinaus.
  • Angreifer mit Open-Source-Agentenwerkzeugen. Eine finanziell motivierte Kampagne nutzte öffentlich verfügbare, KI-basierte Frameworks für offensive Sicherheit und verkürzte die Zeit vom ersten Zugriff bis zum endgültigen Schaden von Tagen auf wenige Stunden.

Zwei Details verdienen Aufmerksamkeit: Organisationen, die nur teilweise nachbesserten, wurden binnen Tagen erneut und in größerem Umfang angegriffen, und die Agenten verwendeten dieselben offenliegenden Zugangsdaten in getrennten Operationen wieder. Ein offenliegender Schlüssel wird nicht vergessen.

Die Schwachstellen sind alt. Neu ist das Tempo

Die Warnung stellt klar, dass die in diesen Vorfällen ausgenutzten Schwachstellen konventionell sind. Es sind fünf:

  1. Schlüssel und Passwörter, die im Quellcode, in der Historie öffentlicher Repositories, in Konfigurationsdateien, Client-Anwendungen und öffentlichen Webinhalten offenliegen.
  2. Ruhende, veraltete und Test-APIs, die weiterhin aus dem Internet erreichbar sind.
  3. API-Schlüssel für Zahlungen, die im Klartext gespeichert und aus der Laufzeitumgebung der Anwendung lesbar sind.
  4. Zu großzügige Cloud-Rollen, mit denen gewöhnliche oder anonyme Aufrufer weitreichend lesen und schreiben können.
  5. Aus dem Internet erreichbare Verwaltungsoberflächen und ungepatchte Middleware mit schwachen Passwörtern oder ohne Multi-Faktor-Authentifizierung.

Nichts davon ist für eine IT-Leitung neu. Neu ist laut der Warnung, dass KI diese Fehler schneller, gründlicher und in größerem Umfang fand und ausnutzte als menschliche Angreifer. Der kleine Fehler, der jahrelang unbemerkt blieb, wird jetzt in Stunden gefunden.

Warum das ein saudisches Unternehmen betrifft

Die Warnung kommt aus Indien, doch die fünf Schwachstellen gibt es überall, wo Code geschrieben und Cloud-Server gemietet werden. In Saudi-Arabien decken zwei Regelwerke das direkt ab:

  • Die Essential Cybersecurity Controls ECC-2:2024 der Nationalen Cybersicherheitsbehörde (NCA): 4 Hauptbereiche, 28 Unterbereiche, 108 Kontrollen und 92 Unterkontrollen. Dazu gehören Kontrolle 2-2-3-2, die Multi-Faktor-Authentifizierung für Fernzugriff und privilegierte Konten verlangt, Kontrolle 2-2-3-3 zum Prinzip der minimalen Rechte und Kontrolle 2-2-3-5 zur regelmäßigen Überprüfung von Identitäten und Zugriffsrechten.
  • Die Durchführungsverordnung zum Gesetz zum Schutz personenbezogener Daten (PDPL): Artikel 24 verpflichtet den Verantwortlichen, der zuständigen Behörde eine Verletzung des Schutzes personenbezogener Daten spätestens 72 Stunden nach Kenntnisnahme zu melden, wenn sie der betroffenen Person schaden kann.

Hier liegt die Ironie, die die indische Warnung offenlegt: Die 72-Stunden-Frist beginnt, wenn Sie davon erfahren. In den gemeldeten Fällen wussten die Unternehmen nichts, bis es ihnen jemand anderes sagte. Die eigentliche Frage ist nicht, ob Sie rechtzeitig melden, sondern ob Sie es überhaupt erfahren.

Schritte für diese Woche

Die Empfehlungen von CERT-In für Organisationen, sortiert für ein mittelständisches Unternehmen:

  • Suchen Sie nach offenliegenden Schlüsseln im Code und in der gesamten Repository-Historie, in Variablen der Build- und Deployment-Pipelines, in Konfigurationsdateien, mobilen Apps und im Cloud-Speicher. Für jeden gefundenen Schlüssel gilt: austauschen, aus der Historie entfernen und von außen prüfen, dass der alte nicht mehr funktioniert.
  • Prüfen Sie jede Änderung vor dem Merge mit einem Secrets-Scanner und halten Sie Passwörter aus Code, Konfigurationsdateien und Datenbanken heraus.
  • Inventarisieren Sie Ihre APIs und schalten Sie alte und Test-Endpunkte sowie ungenutzte Konten ab.
  • Reduzieren Sie Cloud-Berechtigungen auf das Minimum, legen Sie niemals Dienstschlüssel in Code, der auf dem Gerät des Kunden läuft, und testen Sie, was ein anonymer Besucher lesen und schreiben kann.
  • Nehmen Sie Verwaltungsoberflächen aus dem Internet und erzwingen Sie Multi-Faktor-Authentifizierung für jede Administratoranmeldung.
  • Überwachen Sie in Maschinengeschwindigkeit: Alarme bei Massenabrufen und automatisierten Registrierungen, und bewahren Sie Protokolle mindestens 180 Tage auf.
  • Wenn Sie KI-Agenten im Unternehmen einsetzen: Geben Sie jedem Lauf eine eigene, kurzlebige Identität mit minimalen Rechten, sperren Sie jedes nicht benötigte Ziel und führen Sie ein manipulationssicheres Protokoll über alles, was er auf Produktivsystemen tut.

Nach jeder Offenlegung eines Schlüssels oder einem bestätigten Zugriff soll die Umgebung laut Warnung als kompromittiert gelten, bis eine forensische Prüfung das Gegenteil zeigt, und mit erneuten Versuchen innerhalb von Tagen bis Wochen ist zu rechnen.

Die Sicht von Origami

Wir lesen diese Warnung als Ende der Schonfrist für kleine Fehler. Ein Schlüssel, den ein Entwickler vor drei Jahren in einer Datei vergessen hat, oder eine Test-API, die niemand geschlossen hat, galt als theoretisches Risiko, weil niemand danach suchen würde. Heute sucht Software unablässig danach, und manche davon ist nicht einmal ein Angreifer, sondern nur ein Modell, das eine Aufgabe ausprobiert und dabei seine Grenzen überschreitet.

Deshalb raten wir unseren Kunden, vor jedem Werkzeug mit einer Bestandsaufnahme zu beginnen: Wo liegen Ihre Schlüssel, wer hat worauf Zugriff, und welche APIs sind noch offen? Diese Fragen lassen sich in Tagen beantworten, sie decken das meiste ab, was die Warnung aufzählt, und sie verbessern Ihre Position gegenüber den NCA-Kontrollen wie gegenüber dem Datenschutzgesetz.

Fazit

Die Agenten in diesen Vorfällen brauchten keine übermenschliche Intelligenz, nur einen vergessenen Schlüssel und eine zu weite Berechtigung. Beginnen Sie diese Woche damit, offenliegende Schlüssel zu finden und auszutauschen, schließen Sie dann alte APIs und erreichbare Verwaltungsoberflächen, und stellen Sie anschließend sicher, dass Sie es bemerken würden, wenn jemand Ihre Daten massenhaft liest. Wenn Sie eine Prüfung Ihrer Systeme und APIs wünschen, kontaktieren Sie uns.

Quellen