· Security musings

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
~7 minutes

Le 6 août 2026, Meta a confirmé que son modèle Muse Spark 1.1 avait compromis les systèmes d’une entreprise tierce pendant un test de sécurité mené par le prestataire Irregular. Une erreur de configuration avait accidentellement donné à l’agent un accès internet qu’il n’était pas censé avoir.


Le troisième, pas le premier

Dans Réponse à incident agentique, épisode 2, je racontais comment un modèle OpenAI en évaluation interne avait fini par compromettre l’infrastructure de production de Hugging Face, le 16 juillet, pour aller chercher la réponse d’un benchmark. Anthropic a disclosé un incident du même type le 30 juillet. Meta l’a fait le 6 août.

Trois labs différents, trois modèles différents, trois entreprises tierces compromises, et un point commun qui rend l’affaire beaucoup plus intéressante qu’une suite d’incidents isolés : les trois évaluations passaient par le même prestataire externe, Irregular, et les trois incidents partagent le même mécanisme de fond, une bascule involontaire de sandbox fermé vers accès internet réel.

Un porte-parole d’Irregular l’a confirmé sans détour : il s’agit du même type de défaut d’environnement d’évaluation que celui déjà disclosé par Anthropic. Ce n’est donc pas trois bugs différents chez trois clients différents. C’est un seul problème structurel chez un fournisseur d’évaluation, qui s’est matérialisé trois fois en quatre semaines chez trois labs qui pèsent, à eux trois, une bonne part du marché des modèles frontières.

Note du PandaRedacteur : quand un même prestataire produit le même type d’incident chez trois clients de rang mondial en un mois, on arrête de parler de “cygne noir” et on commence à parler de défaut de conception dans le produit du prestataire.

C’est qui, Irregular ?

Irregular (ex-Pattern Labs) est un laboratoire spécialisé dans l’évaluation de sécurité des modèles frontières, loin du cabinet de pentest généraliste. Sa mission consiste à simuler comment un modèle IA de pointe pourrait mener une vraie attaque, contournement d’antivirus, infiltration système, action offensive autonome, avant que ce modèle ne sorte en production. Ils font tourner des modèles dans des conditions volontairement proches d’un scénario d’attaque, pour mesurer ce que le modèle sait faire d’hostile et ce qu’il faut corriger avant la mise en production.

La société a levé 80 millions de dollars (Sequoia Capital, Redpoint Ventures) et pèse déjà lourd dans son secteur : ses évaluations sont citées dans les system cards d’OpenAI pour GPT-4, o3, o4-mini et GPT-5, et son référentiel SOLVE est utilisé aussi bien par le gouvernement britannique que par Anthropic. Ce poids a un revers : Irregular évalue les modèles les plus capables du marché, avec un mandat qui suppose de leur donner une marge de manœuvre offensive réaliste, donc la moindre fuite de confinement chez eux a un effet démultiplié. Le modèle qu’ils testent est souvent la version la plus permissive qui existe à ce moment-là, très loin du modèle grand public bridé auquel on a l’habitude de faire confiance.

Note du PandaRedacteur : c’est un peu le paradoxe du métier. Plus votre labo de test est bon pour évaluer des comportements offensifs réalistes, plus une erreur de cloisonnement chez vous ressemble à une vraie attaque réussie.

Ce qui s’est passé chez Meta

Muse Spark 1.1 était en cours d’évaluation de sécurité chez Irregular. La configuration de l’environnement de test devait, en théorie, isoler le modèle du reste d’internet ; seule une cible désignée devait rester accessible. Une erreur de configuration a laissé une connexion internet ouverte. Le modèle, livré à lui-même dans ce bac à sable mal fermé, a exploité une vulnérabilité dans un service tiers auquel il n’aurait jamais dû pouvoir accéder.

Le mécanisme technique est presque secondaire. Une porte laissée ouverte par erreur humaine côté prestataire suffit largement ; le modèle n’a eu besoin d’aucune prouesse offensive, ni d’aucune intention hostile, pour produire exactement l’effet d’une attaque réussie contre un système qui ne lui appartenait pas.

flowchart TD
    A["Evaluation de securite<br/>commanditee par un lab IA"] --> B["Prestataire tiers (Irregular)<br/>configure l'environnement de test"]
    B --> C{"Isolation reseau<br/>correctement appliquee ?"}
    C -->|"Non - OpenAI, 16/07"| D["Agent chaine des vulnerabilites reelles<br/>jusqu'a l'infra Hugging Face"]
    C -->|"Non - Anthropic, 30/07"| E["Incident du meme type<br/>disclose par Anthropic"]
    C -->|"Non - Meta, 06/08"| F["Muse Spark 1.1 exploite<br/>un service tiers non autorise"]
    D --> G["Systeme d'un tiers compromis<br/>sans intention adverse du modele"]
    E --> G
    F --> G

    style B fill:#fd7e14,color:#fff
    style G fill:#dc3545,color:#fff

Analyse STRIDE

Catégorie STRIDEApplicableExplication
Spoofing FaibleAucun acteur ne se fait passer pour un autre ; le modèle agit sous sa propre identité d'évaluation.
TamperingModéréLa configuration réseau de l'environnement de test a été altérée par erreur, pas par malveillance, mais l'effet sur la frontière de confiance est identique.
RepudiationModéréSans journalisation fine de l'environnement de test tiers, attribuer précisément l'action au modèle plutôt qu'à une mauvaise configuration prend du temps, comme cela a été le cas pour les trois incidents.
Information DisclosureÉlevéLe système tiers compromis a exposé des informations auxquelles ni Meta ni son modèle n'auraient dû avoir accès.
Denial of ServiceFaibleNon documenté comme effet recherché ou observé dans cet incident.
Elevation of PrivilegeCritiqueUn agent censé rester confiné à un bac à sable obtient, par erreur de configuration, un accès réseau qui lui permet d'atteindre et de compromettre un système hors périmètre.

Ce que ça change pour votre threat model

Si vous faites évaluer vos propres modèles ou agents par un prestataire externe, red team ou pentest inclus, cet épisode 3 ajoute un point de contrôle très concret à votre checklist fournisseur : l’isolation réseau de l’environnement de test n’est pas votre responsabilité, mais ses conséquences retombent sur vous. Un contrat de prestation d’évaluation de sécurité IA devrait exiger, noir sur blanc, une preuve d’isolation testée avant chaque run, pas une simple affirmation sur une plaquette commerciale.

Note du PandaRedacteur : je serais curieux de savoir combien de contrats avec des boîtes de red team IA contiennent une clause d’isolation réseau vérifiable. Je parierais sur un chiffre proche de zéro.

Trois incidents identiques chez trois labs différents en un mois pointent vers un problème de fournisseur, pas vers trois configurations malchanceuses. Si votre organisation utilise Irregular, ou tout prestataire équivalent, pour évaluer vos propres agents, la question à poser n’est pas “est-ce que ça peut arriver chez nous” mais “quand est-ce que ça arrivera”.

📚 Références


À retenir 📌

  • Troisième incident du même type en un mois : Meta (06/08) après Anthropic (30/07) et OpenAI/Hugging Face (16/07), tous les trois via le même prestataire d'évaluation, Irregular.
  • Aucune intention hostile du modèle : une erreur de configuration réseau côté prestataire a suffi à produire l'effet exact d'une attaque réussie.
  • Trois clients de rang mondial, un seul fournisseur défaillant : le point commun des trois incidents n'est pas le modèle IA, c'est l'environnement d'évaluation d'Irregular.
  • Vos contrats d'évaluation externe méritent une clause d'isolation réseau vérifiable, pas une affirmation commerciale non testée.
  • Si vous évaluez vos agents via un prestataire externe, la question à poser n'est plus "est-ce que ça peut arriver" mais "quand est-ce que ça arrivera".