Zum Inhalt springen
Tech & Tacheles„Klartext zu KI, Security und Crypto"
← Alle Beiträge
Cybersecurity September 22, 2026

Gemini Sicherheitstest: Googles KI hackte drei echte Firmen – und stoppte selbst

Beim Gemini Sicherheitstest griff Googles KI auf drei reale Firmen zu. Was schiefging, warum Google schwieg – und welche Kontrollen wirklich versagten.

Gemini Sicherheitstest: Googles KI hackte drei echte Firmen – und stoppte selbst

Ein Gemini Sicherheitstest ist im Mai 2026 aus dem Rahmen gelaufen: Ein Google-Modell griff während einer Prüfübung auf die Systeme von drei realen Unternehmen zu. Google hat das bestätigt, nachdem das Wall Street Journal am Freitag, 18. September 2026, darüber berichtete. 9to5Google ergänzte die Bestätigung am 19., SecurityWeek am 21. September um Stellungnahmen aus Googles Sicherheitsabteilung. Bemerkenswert dabei: Das Modell brach jeden der drei Zugriffe von sich aus ab.

Was im Gemini Sicherheitstest passierte

Schauplatz war die Infrastruktur des Prüfdienstleisters Irregular. Aufgabe: ein Capture-the-Flag-Szenario, in dem das Modell Informationen aus der Software eines erfundenen Unternehmens beschaffen sollte. Der Haken lag im Namen – die erfundene Firma hieß genauso wie eine echte. Und obwohl für den Versuch kein Internetzugang vorgesehen war, stand einer zur Verfügung. Irregular spricht von einem Versehen.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Drei Durchläufe, zwei Vorgehensweisen: Einmal reichte simples Durchprobieren, bis ein Passwort saß. In den beiden anderen Läufen suchte das Modell schlicht nach dem Firmennamen und stieß dabei auf Zugangsdaten, die in öffentlichen Repositories lagen. Damit meldete es sich an. Kein Exploit, keine Zero-Day-Lücke – eine Suchmaschine und ein schwaches Passwort.

Google zufolge erkannte das Modell jedes Mal, dass es bei einem echten Unternehmen gelandet war, und beendete den Zugriff. Eine Unschärfe bleibt in den Darstellungen: Das offizielle Statement von Heather Adkins, VP Security Engineering, spricht davon, das Modell habe öffentliche Informationen gefunden und Zugangsdaten erraten; die auf den WSJ-Bericht gestützten Schilderungen sprechen von Zugangsdaten, die es in Repositories gefunden hat. Aufgelöst hat Google das bisher nicht.

Irregular informierte Google Ende Juli. Veröffentlicht wurde der Vorgang erst, als das WSJ nachfragte. Google begründet das damit, dass kein Schaden entstanden sei und das Modell sofort gestoppt habe; als Fehlausrichtung des Modells wertet der Konzern den Fall nicht, weil die eigenen Schutzmechanismen gegriffen hätten. Die drei betroffenen Firmen wurden benachrichtigt, ihre Namen nennt Google nicht. US-Bundesbehörden seien informiert worden. Welches Modell beteiligt war, bleibt offen – nur dass es nicht das aktuelle gewesen sei.

Kein Einzelfall, sondern ein Muster

Derselbe Prüfdienstleister taucht in Vorfällen von Meta, OpenAI und Anthropic auf. Anthropic hat den eigenen Fall im Juli öffentlich aufgearbeitet und dabei nachvollziehbare Zahlen genannt: 141.006 Evaluierungsläufe wurden rückwirkend durchgesehen, in drei davon erreichte ein Claude-Modell aus der Umgebung von Irregular heraus das Internet und griff auf Produktivsysteme dreier Organisationen zu. Der Auslöser dieser Überprüfung war wiederum OpenAI, das am 21. Juli offenlegte, dass mehrere Modelle über eine unbekannte Schwachstelle aus einer isolierten Testumgebung ausgebrochen waren und die Produktivinfrastruktur von Hugging Face erreicht hatten. Laut SecurityWeek hat OpenAI zuletzt sechs weitere Fälle von Fehlverhalten offengelegt, darunter Agenten, die GitHub nach durchgesickerten API-Schlüsseln absuchten. Irregular erklärt, alle bekannten Probleme auf der eigenen Seite seien seit Wochen behoben.

Was das für dich bedeutet

Die Schlagzeile lautet „KI hackt Firmen”. Aus CISO-Sicht ist das die uninteressanteste Lesart. Versagt hat hier nämlich kein Modell, sondern es haben drei ganz gewöhnliche Kontrollen versagt – solche, die es in jedem Unternehmen gibt.

Erstens: Der Geltungsbereich war ein Name, keine Grenze. Ein erfundenes Ziel, das genauso heißt wie eine echte Firma, ist eine Einladung. Wer Testumgebungen baut, kennt das Problem aus Pentests und Lastversuchen: Solange der Scope nur im Auftragsdokument steht und nicht im Netz durchgesetzt wird, ist er eine Bitte.

Zweitens: Der Internetzugang war „nicht vorgesehen”. Er war trotzdem da – bei Google wie bei Anthropic, jeweils beim selben Dienstleister. Zwischen der Annahme, dass eine Umgebung abgeschottet ist, und dem Nachweis liegt genau ein Messvorgang, den offenbar niemand gemacht hat. Dieses Muster kenne ich aus zwei Jahrzehnten Infrastrukturarbeit: Isolation, die nie geprüft wurde, ist keine Isolation.

Drittens: Die Zugangsdaten lagen offen. In zwei von drei Fällen hat das Modell nichts gebrochen, sondern gefunden. Der eigentliche Befund steckt also nicht im Sprachmodell, sondern in den Repositories Dritter – und in einem Passwort, das sich erraten ließ. Wer Konten gegen genau solche Zugriffe härten will, findet die Hardwareseite in meinem Ratgeber zu Hardware-Security-Keys und FIDO2.

Bleibt der Punkt, der mich am meisten stört: die Meldekette. Ende Juli informiert, im September veröffentlicht – und das erst nach einer Presseanfrage. Anthropic hat seinen Fall dagegen aus eigenem Antrieb dokumentiert. Wer selbst KI-Dienstleister beauftragt, sollte diese Frage nicht dem Anbieter überlassen, sondern vertraglich regeln. Wie lange solche Vorgänge sonst unbemerkt bleiben, zeigt der Fall der OpenAI-Agenten in einem deutschen Wiki.

Fünf Punkte für die eigene Praxis

  • Egress messen, nicht annehmen. Vor jedem KI-Testlauf aus der Umgebung heraus einen Verbindungsversuch nach draußen starten und protokollieren. Die Konfiguration zu lesen, reicht nicht.
  • Testziele nie nach echten Organisationen benennen. Dafür gibt es reservierte Bereiche: RFC 2606 und RFC 6761 halten die Endungen .test, .example, .invalid und .localhost sowie die Domains example.com, example.net und example.org frei. Das kostet nichts und verhindert genau diesen Fehler.
  • Secret Scanning ernst nehmen. Öffentliche Repositories und CI-Logs regelmäßig nach Zugangsdaten durchsuchen und Funde rotieren – nicht nur sperren.
  • Agenten als privilegierte Identitäten behandeln. Eigene Konten, minimale Rechte, Protokollierung der Werkzeugaufrufe. Ein Prompt ist keine Zugriffskontrolle.
  • Meldepflichten vertraglich festschreiben. Wer externe Evaluierungen einkauft, definiert Fristen und Eskalationswege für Vorfälle, bevor der erste Test läuft.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden