Eine Formel dafür, wann ein Modell kippt, OpenAIs Agenten in 100 Organisationen, 8,8 Millionen Dänen über einen legalen Partnerzugang kompromittiert, zwei Stunden vom Exploit-Code bis zum Angriff, und PwC zählt, wer handelt.
In dieser Ausgabe
- 01Forscher können nun berechnen, wann ein Modell umschlägt.
- 02Wikimedia suchte nach OpenAIs Agenten. Die Rechnung geht an Freiwillige.
- 03Niemand hat sich in Dänemarks Einwohnermelderegister eingehackt. Jemand hat sich eingeloggt.
- 04Zwei Stunden vom öffentlichen Exploit-Code bis zu Live-Angriffen.
- 05Die Hälfte nennt KI als größte Lücke. Siebzehn Prozent übertragen sie dem CISO.
Erhalten Sie den nächsten GRC Brief in Ihrem Postfach.
The GRC Brief abonnierenForscher können nun berechnen, wann ein Modell umschlägt.
Zwei Forscher der George Washington University haben eine Formel für den Punkt veröffentlicht, an dem ein Modell in fehlerhafte Ausgaben kippt. Die Ursache liegt im Attention Head: Angehäufter Gesprächskontext zieht die Aufmerksamkeit in Richtung eines unerwünschten Ausgabe-Basins, bis ein Schwellenwert überschritten wird. Unachtsame Prompts bewirken dies ebenso leicht wie böswillige. Das Muster hielt sich über sieben Open-Weight-Modelle hinweg. Der vorgeschlagene Fix ist eine Warnleuchte innerhalb des Modells, die vor jeder Ausgabe geprüft wird.
Quelle: Patterns (Cell Press) · Johnson & Huo, peer-reviewed paper
Meine Einschätzung
Letzte Woche habe ich das Wort „rogue" fallen lassen. Das ist der Grund. Ein Schwellenwert, den Sie berechnen können, und ein Indikator, den Sie setzen können, ist Engineering, und Engineering hat Verantwortliche. Ein Vorbehalt: Die Tests wurden mit kleinen Open-Weight-Modellen ohne Cloud-Filterung durchgeführt, daher lassen sich die Zahlen nicht auf den Produktivbetrieb übertragen. Der Mechanismus schon. Nutzen Sie den Test, den er impliziert. Bevor ein Agent Zugangsdaten erhält, testen Sie ihn mit vagen und schlecht formulierten Prompts. Bleibt er innerhalb seiner Berechtigungen, umgeht er Einschränkungen, eskaliert er an einen Menschen. Keine befriedigenden Antworten, keine Autonomie.
Wikimedia suchte nach OpenAIs Agenten. Die Rechnung geht an Freiwillige.
Die Wikimedia Foundation führte eine eigene Untersuchung durch und veröffentlichte sie. Sie fand Agenten, von denen sie annimmt, dass OpenAI sie betreibt: Diese bearbeiten ihre Wikis, überwiegend in Sandbox-Bereichen, scheitern daran, ein gehostetes Notiz-Tool als Proxy zu nutzen, und senden Millionen automatisierter Anfragen an öffentliche APIs, darunter Hunderttausende von Abfragen, die möglicherweise zu einem Teilausfall des Wikidata Query Service im Mai beigetragen haben. Kein Sicherheitsvorfall, kein Anzeichen für eine Koordination der Agenten. Zwei Zahlen dazu: Die Foundation gibt an, dass 65 Prozent ihres ressourcenintensivsten Traffics inzwischen von Bots stammt, und OpenAI hat über hundert Vorfälle in mehr als hundert Organisationen eingeräumt.
Quelle: Wikimedia Foundation · S. Deckelmann, 5 Oct 2026
Meine Einschätzung
Hundert Vorfälle, hundert Organisationen. Ich habe in diesem Jahr drei davon behandelt, und nur weil jemand diese drei dokumentiert hat. Schauen Sie nun, wer zahlt. Die Foundation gibt an, dass sie die Kosten bereits absorbiert, ihre Freiwilligen die Aufräumarbeiten übernehmen, und fordert die Unternehmen, die von diesen Agenten profitieren, auf, zur Schadensvorbeugung und -behebung beizutragen, anstatt dies zum neuen Normalzustand werden zu lassen. Das Problem, das das für Sie hinterlässt, ist die Attribution. Wenn Sie eine öffentliche API exponieren, können Sie eine Forschungsflotte nicht von einem feindlichen Crawler unterscheiden, und Ihre Rate-Limits wurden für Menschen dimensioniert. Prüfen Sie, was Ihres einem nicht authentifizierten Client bei hohem Volumen liefert.
Niemand hat sich in Dänemarks Einwohnermelderegister eingehackt. Jemand hat sich eingeloggt.
Das dänische Central Population Register enthält rund 11 Millionen Datensätze, und die zehnstellige CPR-Nummer, die es vergibt, steuert alles von Steuern über Gesundheitsversorgung bis zum Bankwesen. Angreifer missbrauchten den legitimen Zugang eines privaten dänischen Unternehmens, um das Register abzufragen, und entwendeten Namen, Adressen und CPR-Nummern von rund 8,8 Millionen Personen: lebenden, ausgewanderten und verstorbenen. Das entspricht etwa 80 Prozent des Registers in einem Land mit sechs Millionen Einwohnern. Das Register erkannte den Vorfall am 2. Oktober, benachrichtigte die Datenschutzbehörde am 4. und ging am 5. an die Öffentlichkeit, entzog dem Unternehmen den Zugang und schaltete die Polizei ein. Personen mit Name- und Adressschutz waren ausgenommen. Der Akteur wurde nicht benannt.
Quelle: Help Net Security · Denmark CPR breach, 6 Oct 2026
Meine Einschätzung
Niemand hat sich eingehackt. Ein Konto mit legalem Zugang zur Abfrage namentlich genannter Personen wurde genutzt, um 8,8 Millionen Datensätze abzurufen, und die Autorisierung war bei jedem einzelnen Schritt gültig. Niemand hat das Nutzungsmuster überwacht. Das ist Third-Party-Risiko in seiner reinsten Form: Sie können die Organisation prüfen, den Vertrag unterzeichnen, den Fragebogen durchführen, und trotzdem keine Ahnung haben, was die Anmeldedaten um drei Uhr morgens tun. Dieser Schaden verfällt nicht. Eine CPR-Nummer ist ein dauerhafter nationaler Identifikator; die Betroffenen können ihn nicht rotieren wie ein Passwort, und die Verstorbenen schon gar nicht. Eines muss man fair anerkennen: Dänemark betreibt MitID, sodass eine CPR-Nummer allein keine Identitätsübernahme ermöglicht. Sie lässt jedoch jeden Phishing-Anruf legitim klingen, weshalb das Ministerium Bürgerinnen und Bürgern rät, weder am Telefon noch per E-Mail Informationen preiszugeben, selbst wenn der Anrufer Name, Adresse und CPR-Nummer kennt. Wenn Sie einem Partner Abfragezugang auf Identitätsdaten gewähren, stellen Sie diese Woche fest, ob jemandem tausend Abfragen auffallen würden, wo normalerweise zehn stattfinden.
Zwei Stunden vom öffentlichen Exploit-Code bis zu Live-Angriffen.
Atlassian hat CVE-2026-21589 am 5. Oktober mit einer Bewertung von 9,3 veröffentlicht: Ein nicht authentifizierter Angreifer kann Dateien innerhalb des Web-Roots von acht selbst gehosteten Data-Center-Produkten lesen, darunter Jira und Confluence. watchTowr veröffentlichte am nächsten Tag eine Analyse und Exploit-Code und zeigte, dass aus dem Dateilesen Administrator-Zugang wird, wenn Jira mit Crowd verbunden ist. Honeypots protokollierten die ersten Versuche zwei Stunden später, gefolgt von einem öffentlichen Scanning-Template.
Quelle: BleepingComputer · B. Toulas, 7 Oct 2026
Meine Einschätzung
Zwei Stunden. Kürzer als der Abstand zwischen zwei Change-Advisory-Board-Sitzungen. Lassen Sie sich nicht durch die vermeintliche Hürde des exakten Dateipfads beruhigen: Atlassian-Pfade sind dokumentiert und in jeder Deployment-Instanz identisch. Das schärft auch einen Rat, den ich Ihnen zweimal gegeben habe. Die Priorisierung anhand des CISA-Katalogs bekannter ausgenutzter Schwachstellen ist ein guter Filter, und er hat hier versagt: Drei Tage nach Beginn der aktiven Ausnutzung war die Schwachstelle noch immer nicht gelistet. Ihr Auslöser ist die Kombination: Internet-exponiert, selbst gehostet, öffentlicher Exploit-Code, Scanning-Template im Umlauf. Patchen Sie auf dieser Basis. Wo Crowd im Pfad sitzt, behandeln Sie das als Identitätsvorfall.
Die Hälfte nennt KI als größte Lücke. Siebzehn Prozent übertragen sie dem CISO.
PwC befragte 3.934 Führungskräfte aus Wirtschaft und Technologie in 71 Ländern. Die Hälfte der Security-Verantwortlichen nennt Angriffe auf eigene KI-Systeme als die Bedrohung, auf die sie am wenigsten vorbereitet sind, noch vor Cloud, Supply Chain und Ransomware. Siebzehn Prozent machen den CISO für KI-Sicherheit verantwortlich. Vierundvierzig Prozent geben an, dass ihnen die Fähigkeiten zur Aufsicht fehlen. Einundzwanzig Prozent implementieren quantenresistente Maßnahmen.
Quelle: SecurityWeek · PwC survey, 1 Oct 2026
Meine Einschätzung
Drei Zahlen, eine Lücke. Das Risiko hat einen Namen, einen Verantwortlichen, auf den sich niemand geeinigt hat, und niemanden, der qualifiziert wäre, es zu überprüfen. ISO 42001 ist genau auf diese Fragen ausgerichtet: Wer entscheidet, wer prüft, wer steht danach Rede und Antwort. Dann die 21 Prozent, gemessen an der EU-Erwartung, dass die Mitgliedstaaten ihre kryptografischen Inventare bis Ende dieses Jahres in Angriff nehmen. „Harvest now, decrypt later" bedeutet: Ihre Uhr lief an, sobald der Chiffretext abgefangen wurde. Beantworten Sie eine Frage: Gibt es Daten in Ihrem Besitz, die länger geheim bleiben müssen, als Ihre aktuelle Kryptografie standhalten wird. Dann erstellen Sie das Inventar.