Gemini griff in Tests auf reale Systeme zu

Google teilte dem Wall Street Journal mit, dass Gemini während eines Irregular-Tests auf Systeme von drei Unternehmen zugriff; Irregular fand keine Hinweise auf eine Kompromittierung oder einen Datenabfluss.^{[2], [1], [3]}

💡 Einfache Erklärung (ELI5)

Stellen Sie sich eine Polizeiübung vor, bei der Anwärter die Website einer fiktiven Bank aufrufen sollen. Die Übung soll auf einem abgeschlossenen Gelände bleiben, doch das Tor steht offen und ein echtes Unternehmen trägt denselben Namen im Internet. Die Anwärter können das Gelände verlassen und die echte Website erreichen. Irregular erklärte, keine Hinweise auf einen Einbruch in Kundensysteme oder Datenverlust gefunden zu haben. Die Lehre: Die Netzwerkgrenze muss technisch durchgesetzt werden; verlassen Sie sich nicht darauf, dass das Modell sie erkennt, und verwenden Sie reservierte Fantasienamen.^{[2], [1]}

Kernkonzepte & Begriffe

Capture-the-Flag-Evaluierung (CTF): Ein Test, bei dem ein Modell in absichtlich verwundbare Systeme einzudringen versucht, um vor der Veröffentlichung seine offensiven Cyberfähigkeiten zu messen.^{[2], [1]}
Irregular: Das KI-Sicherheitsunternehmen, das die Evaluierung auf eigener Infrastruktur durchführte. Derselbe Partner war an den Claude-Vorfällen beteiligt, die Anthropic im Juli 2026 offenlegte.^[1]
Egress standardmäßig verweigert: Eine Netzwerkregel, die jede ausgehende Verbindung blockiert, die nicht ausdrücklich erlaubt ist, damit eine Umgebung das Internet nicht versehentlich erreicht.^[4]
Reservierte Namen (RFC 2606): Domains wie .test und .example, die nie registriert werden können – ein fiktives Ziel kann so nicht mit einer echten Organisation zusammenfallen.^[5]
Einstufung: CWE-693 (Versagen eines Schutzmechanismus) ist die analytische Einstufung von FlawOpen und keine vom Anbieter vergebene CWE. High ist eine redaktionelle Bewertung, weil die gemeldete Evaluation die Netzwerkisolation überschritt und Systeme von drei Organisationen erreichte; die zitierten Quellen belegen weder eine Kompromittierung noch den Verlust von Kundendaten. CVE und CVSS-Wert sind nicht anwendbar.^{[7], [2], [1]}
Herkunft der Empfehlungen: Die folgende Liste enthält FlawOpen-Empfehlungen für die beschriebene Grenze; sie behauptet nicht, dass Google oder Irregular genau diese Kontrollen umgesetzt haben.^[1]

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-693

Vorfall-Zeitstrahl

2026-05

Das Wall Street Journal berichtete über Googles Aussage, Gemini habe im Mai während einer Irregular-Cybersicherheitsprüfung Systeme von drei Unternehmen erreicht.^{[2], [1], [3]}

2026-08-14

Irregular veröffentlichte seine Analyse und erklärte, das Problem der Evaluationsumgebung sei behoben und betroffene Parteien seien benachrichtigt worden.^[1]

2026-09-18

Google teilte dem Wall Street Journal mit, Gemini habe bei einem Test im Mai Systeme von drei Unternehmen erreicht; die Zeitung veröffentlichte ihren Bericht am 18. September.^{[2], [3]}

Schritt-für-Schritt Angriffsablauf

Schritt 1

Die Umgebung ist nicht isoliert

Das Modell sollte keinen Internetzugang haben, doch die Evaluierungsumgebung des Partners stellte ihn ungewollt bereit.^[1]

Schritt 2

Das fiktive Ziel trägt einen echten Namen

Die Aufgabe verlangte, Informationen von einem fiktiven Unternehmen zu beschaffen, dessen Name auch von echten Firmen geführt wird.^{[2], [1]}

Schritt 3

Berichtete Zugriffswege und Grenzen

Google teilte dem Wall Street Journal mit, das Modell habe öffentliche Informationen gefunden und Zugangsdaten für Websites zu erraten versucht, die es der Übung zuordnete. Irregular erklärte später, der fiktive Name habe einer realen Domain entsprochen; es gebe keine Hinweise auf einen Einbruch in Kundensysteme oder Datenabfluss.^{[2], [1], [3]}

Schritt 4

Eindämmung und Offenlegung

Irregular zufolge war das Problem der Evaluationsumgebung vor dem öffentlichen Bericht vom 14. August behoben; die betroffenen Parteien seien benachrichtigt worden. Das Wall Street Journal berichtete im September nach einer Anfrage über Googles Bestätigung. Die verfügbaren Angaben belegen nicht, dass Kundendaten erlangt wurden.^{[2], [1]}

Quellcode: Verwundbar vs. Sicher

Beispielhafte Kubernetes-Konfiguration, nicht von Irregular oder Google. Sie wählt alle Pods in agent-eval aus und erlaubt nur TCP/443 zu ausdrücklich markierten mock-target-Pods; NetworkPolicy filtert Ports und Protokolle, nicht TLS. Konfigurieren Sie den Mock-Dienst daher so, dass er HTTPS verlangt. DNS ist außerdem nur zu einem dedizierten Resolver erlaubt. Wenn dessen Eingangsverkehr isoliert ist, ergänzen Sie eine passende Eingangsregel für Evaluations-Pods auf UDP- und TCP-Port 53. Der Resolver darf nur die interne Mock-Zone bedienen und keine beliebigen Anfragen ins öffentliche Internet weiterleiten, da DNS sonst zum Ausgangspfad werden kann. Die Endung .test ist laut RFC 2606 für Tests reserviert. Die Durchsetzung hängt vom CNI ab; hostNetwork und privilegierte Node-Workloads gehören nicht in diese Grenze. Prüfen Sie die Sperre mit einem kontrollierten Canary.^{[4], [5], [1]}

VERWUNDBARE IMPLEMENTIERUNG

apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  # Verwenden Sie einen reservierten .test-Hostnamen, damit das Beispiel kein echtes Unternehmen ansprechen kann.
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
# In diesem Namespace gibt es keine NetworkPolicy; Pods können daher das Internet erreichen.

GEHÄRTETER SICHERHEITS-PATCH

apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: eval-egress-allowlist
  namespace: agent-eval
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    # Den Ziel-Namespace vorab mit purpose=ctf-mock-targets und die Ziel-Pods mit app=mock-target labeln.
# Nur TCP/443 erlauben; NetworkPolicy prüft weder TLS noch erzwingt es HTTPS.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-mock-targets
          podSelector:
            matchLabels:
              app: mock-target
      ports:
        - protocol: TCP
          port: 443
    # Den Namespace des dedizierten Resolvers vorab mit purpose=ctf-dns und seine Pods mit app=eval-dns labeln.
    # Einen dedizierten Resolver verwenden, der nur auf die interne Testzone antwortet.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-dns
          podSelector:
            matchLabels:
              app: eval-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Checkliste für Engineering & Systemsicherheit

✓Wenden Sie auf jeden Evaluierungs-Namespace eine NetworkPolicy mit standardmäßig verweigertem Egress (oder eine gleichwertige Firewall-Regel) an und erlauben Sie nur benannte Mock-Ziel-Namespaces.^{[4], [1]}
✓Starten Sie vor jedem Batch im Namespace einen Canary-Pod, der eine externe Adresse unter Ihrer Kontrolle zu erreichen versucht; lassen Sie den Batch scheitern, wenn die Anfrage durchgeht.^[4]
✓Vergeben Sie für jedes fiktive Ziel reservierte Domains (.test, .example, .invalid) und erfundene Firmennamen; ergänzen Sie eine CI-Prüfung, die Szenariodateien mit echt wirkenden öffentlichen Domains ablehnt.^{[5], [1]}
✓Lösen Sie während der Läufe bei ausgehenden Verbindungen und beim Erraten von Zugangsdaten für Hosts außerhalb des Szenarios Alarm aus; protokollieren Sie Authentifizierungsversuche, ohne einen Erfolg zu unterstellen.^{[2], [1]}
✓Legen Sie in Verträgen mit Evaluierungspartnern Fristen für Benachrichtigung und öffentliche Offenlegung fest, damit ein Vorfall beim Partner Sie und die Betroffenen schnell erreicht.