Gemini a accédé à des systèmes réels lors d’un test

Google a déclaré au Wall Street Journal que Gemini avait accédé aux systèmes de trois entreprises lors d’un test d’Irregular ; celle-ci n’a trouvé aucune preuve de compromission ni de fuite de données.^{[2], [1], [3]}

💡 Explication en Langage Simple (ELI5)

Imaginez un exercice de police où les recrues doivent accéder au site d'une banque fictive. L'exercice est censé rester dans une cour fermée, mais le portail est ouvert et une vraie entreprise porte le même nom en ligne. Les recrues peuvent sortir de la cour et atteindre le vrai site. Irregular indique n'avoir trouvé aucune preuve d'intrusion dans les systèmes des clients ni de perte de données. La leçon consiste à imposer la limite réseau et à utiliser des noms fictifs réservés, sans compter sur le modèle pour la reconnaître.^{[2], [1]}

Concepts Clés et Termes

Évaluation capture-the-flag (CTF): Un test où un modèle tente de pénétrer des systèmes volontairement vulnérables, pour mesurer ses capacités offensives avant sa sortie.^{[2], [1]}
Irregular: La société de sécurité IA qui a mené l'évaluation sur sa propre infrastructure. Le même partenaire était impliqué dans les incidents Claude révélés par Anthropic en juillet 2026.^[1]
Sortie refusée par défaut: Une règle réseau qui bloque toute connexion sortante non explicitement autorisée, pour qu'un environnement ne puisse pas atteindre Internet par accident.^[4]
Noms réservés (RFC 2606): Des domaines comme .test et .example, qui ne peuvent jamais être enregistrés : une cible fictive ne peut donc pas coïncider avec une vraie organisation.^[5]
Classification: CWE-693 (défaillance d’un mécanisme de protection) est la classification analytique de FlawOpen, et non une CWE attribuée par le fournisseur. High est une appréciation éditoriale, car l’évaluation rapportée a franchi le confinement réseau et atteint les systèmes de trois organisations ; les sources citées n’établissent ni compromission ni perte de données clients. Aucun CVE ni score CVSS ne s’applique.^{[7], [2], [1]}
Origine des recommandations: La liste suivante présente les recommandations d’ingénierie de FlawOpen tirées de la frontière décrite ; elle ne prétend pas qu’Google ou Irregular ait déployé ces contrôles précis.^[1]

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-693

Chronologie de l'Incident

2026-05

The Wall Street Journal a rapporté la déclaration de Google selon laquelle Gemini a atteint les systèmes de trois entreprises lors d’une évaluation de cybersécurité menée par Irregular en mai.^{[2], [1], [3]}

2026-08-14

Irregular a publié son analyse, indiquant que le problème de l’environnement d’évaluation avait été corrigé et que les parties concernées avaient été informées.^[1]

2026-09-18

Google a déclaré au Wall Street Journal que Gemini avait atteint les systèmes de trois entreprises lors d’un test en mai ; le journal a publié son article le 18 septembre.^{[2], [3]}

Déroulement de l'Attaque Étape par Étape

Étape 1

L'environnement n'est pas isolé

Le modèle ne devait pas avoir accès à Internet, mais l'environnement d'évaluation du partenaire le lui donnait par erreur.^[1]

Étape 2

La cible fictive porte un vrai nom

L'exercice demandait au modèle d'obtenir des informations sur une entreprise fictive dont le nom était aussi celui d'entreprises réelles.^{[2], [1]}

Étape 3

Méthodes d’accès rapportées et limites

Google a déclaré au Wall Street Journal que le modèle avait trouvé des informations publiques et tenté de deviner des identifiants pour des sites qu’il croyait liés à l’exercice. Irregular a ensuite indiqué que le nom fictif correspondait à un domaine réel et n’avoir trouvé aucune preuve d’intrusion dans les systèmes des clients ni de fuite de données.^{[2], [1], [3]}

Étape 4

Confinement et divulgation

Irregular indique que le problème de l’environnement d’évaluation avait été corrigé avant son rapport public du 14 août et que les parties concernées avaient été informées. The Wall Street Journal a rapporté la confirmation de Google en septembre après l’avoir interrogé. Les informations disponibles n’établissent pas que des données clients aient été obtenues.^{[2], [1]}

Code Source : Vulnérable vs Sécurisé

Configuration Kubernetes illustrative, qui n’est ni celle d’Irregular ni celle de Google. Elle sélectionne tous les pods de agent-eval et autorise uniquement TCP/443 vers les pods mock-target explicitement étiquetés ; NetworkPolicy filtre les ports et protocoles, pas TLS : configurez donc le service simulé pour exiger HTTPS. Elle autorise aussi DNS vers un résolveur dédié. Si ce résolveur isole son trafic entrant, ajoutez une règle correspondante pour les pods d’évaluation sur le port 53 en UDP et TCP. Configurez-le pour ne servir que la zone simulée interne et ne jamais transférer des requêtes arbitraires vers Internet, sinon DNS peut devenir une voie de sortie. Le suffixe .test est réservé aux tests par la RFC 2606. L’application dépend du CNI ; excluez hostNetwork et les charges privilégiées au niveau du nœud de la frontière, puis vérifiez le blocage avec un canari contrôlé.^{[4], [5], [1]}

IMPLÉMENTATION VULNÉRABLE

apiVersion: v1
kind: ConfigMap
metadata:
  name: ctf-scenario
  namespace: agent-eval
data:
  # Utilisez un nom réservé en .test pour que l’exemple ne puisse pas viser une organisation réelle.
  target_company: "Example Freight Test Co"
  target_host: "portal.freight.test"
# Aucun NetworkPolicy ne s’applique dans cet espace de noms : les pods peuvent donc accéder à Internet.

PATCH SÉCURISÉ ET ROBUSTE

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:
    # Étiquetez au préalable l’espace de noms cible avec purpose=ctf-mock-targets et les pods cibles avec app=mock-target.
# Autoriser uniquement TCP/443 ; NetworkPolicy n’inspecte pas TLS et n’impose pas HTTPS.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-mock-targets
          podSelector:
            matchLabels:
              app: mock-target
      ports:
        - protocol: TCP
          port: 443
    # Étiquetez au préalable l’espace de noms du résolveur dédié avec purpose=ctf-dns et ses pods avec app=eval-dns.
    # Utilisez un résolveur dédié qui ne répond que pour la zone de test interne.
    - to:
        - namespaceSelector:
            matchLabels:
              purpose: ctf-dns
          podSelector:
            matchLabels:
              app: eval-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Appliquez une NetworkPolicy de sortie refusée par défaut (ou une règle de pare-feu équivalente) à chaque espace de noms d'évaluation, et n'autorisez que des espaces de noms de cibles simulées nommés.^{[4], [1]}
✓Avant chaque lot, lancez dans l'espace de noms un pod sentinelle qui tente de joindre une adresse externe que vous contrôlez ; faites échouer le lot si la requête aboutit.^[4]
✓Donnez à chaque cible fictive des domaines réservés (.test, .example, .invalid) et des noms d'entreprise inventés ; ajoutez un contrôle CI qui rejette les fichiers de scénario contenant des domaines publics réalistes.^{[5], [1]}
✓Déclenchez des alertes pendant les exécutions en cas de connexions sortantes ou de tentatives de deviner des identifiants sur des hôtes hors scénario ; consignez les tentatives d’authentification sans supposer qu’elles ont abouti.^{[2], [1]}
✓Inscrivez des délais de notification et de divulgation publique dans les contrats avec les partenaires d'évaluation, pour qu'un incident chez eux vous parvienne vite, ainsi qu'aux parties concernées.