Sécurité IA

Cairn : 25 attaques autonomes par IA sur des failles connues

Unit 42 décrit 25 opérations menées par un agent d'IA open source, Cairn, contre 19 organisations. Les accès obtenus reposaient sur des faiblesses connues. Ce que cela change pour la défense.

En bref. Unit 42, l'équipe de recherche de Palo Alto Networks, a publié le 12 novembre 2026 l'analyse d'une campagne où des attaquants ont utilisé Cairn, un framework open source de test d'intrusion piloté par IA, pour mener 25 opérations autonomes contre au moins 19 organisations en août et septembre 2026. Dix organisations ont subi un accès non autorisé ou une récupération de données. Unit 42 souligne que les vulnérabilités exploitées étaient connues : contournements d'authentification, mots de passe faibles ou par défaut, interfaces de programmation (API) cloud exposées, vulnérabilités publiques anciennes répertoriées sous un identifiant CVE. L'IA a augmenté le volume des attaques, pas leur sophistication.

Ce qui s'est passé

Selon Unit 42, des attaquants sinophones ont mené la campagne, suivie sous le nom CL-STA-1238. Unit 42 l'attribue avec un niveau de confiance modéré à une activité de collecte de renseignement liée à la Chine, en s'appuyant sur trois éléments : la langue des artefacts, l'usage exclusif de modèles chinois et le choix des cibles.

Les organisations visées (au moins 19) se concentrent dans trois catégories principales :

  • semi-conducteurs et fabrication avancée : sept organisations, de la lithographie à la conception de puces, aux matériaux, aux photomasques et aux organismes de normalisation ;
  • défense et politique de défense : trois organisations, dont une entreprise de technologie spatiale, un éditeur d'analytique de défense et un centre de réflexion ;
  • droits humains et société civile : quatre organisations, dont un organisme canadien de défense des droits humains et un syndicat d'enseignants américain.

Les résultats confirmés. Cairn a confirmé un accès non autorisé ou une récupération de données dans 10 organisations. Unit 42 cite notamment :

  • chez un organisme de normalisation, des dizaines d'identifiants valides obtenus par pulvérisation de mots de passe faibles, et un document de vote de norme modifié via une écriture non authentifiée dans un stockage cloud ;
  • chez une entreprise de semi-conducteurs, un identifiant de production trouvé par force brute sur une application d'intégration partenaire, puis des comptes administrateurs et un jeton d'API persistant créés dans le système de production ;
  • chez un syndicat d'enseignants, un contournement de la création de compte du CMS (le système de gestion de contenu du site) qui a permis de collecter des données de membres à grande échelle ; le framework a consigné l'accès à plus d'un million de fiches ;
  • autour d'un programme de politique de défense, environ 500 fiches utilisateurs, dont des comptes en .mil et .gov, exposées par un point d'inscription ouvert.

Comment fonctionne Cairn

Cairn est un framework public, disponible sur GitHub. Chaque « agent » est piloté par un modèle d'IA. Les agents partagent un tableau commun où ils inscrivent ce qu'ils ont confirmé, sous forme de faits, et ce qu'ils comptent faire ensuite. Un opérateur humain peut glisser des indications à tout moment.

Pour chaque opération, les attaquants fournissaient le domaine racine de la cible et un objectif d'une ligne, en substance : obtenir un accès de valeur (shell, code source, clés, identifiants) et, si possible, entrer dans le réseau interne. Cairn découpait ensuite l'objectif en petites tâches et les exécutait en boucle, avec une phase de raisonnement sur ce qui était déjà acquis et une phase d'action. Le plan variait de trois à sept étapes selon la cible. Contre un fabricant de semi-conducteurs, par exemple : reconnaissance, exploitation web, exploitation des services, collecte d'identifiants, élévation de privilèges et mouvement latéral, accès interne et persistance. Les opérations ont duré de 20 minutes à plus de 50 heures.

Les modèles. Cairn ne dépend pas d'un modèle précis. Sur les 25 opérations, 13 ont tourné sur Zhipu GLM 5.2, 8 sur DeepSeek V4 Flash et 4 sur DeepSeek V4 Pro. Unit 42 observe que les attaquants semblent avoir comparé les modèles et utilisé DeepSeek V4 Pro, la version supérieure, pour de nouvelles tentatives contre les cibles qui avaient résisté à DeepSeek V4 Flash. Chaque opération chargeait aussi un module de compétences de scan et d'exploitation, absent du projet Cairn d'origine.

Les garde-fous. Les consignes d'origine de Cairn demandent déjà au modèle de ne jamais refuser une tâche. Les attaquants ont ajouté un préambule affirmant que la mission était un test autorisé, et chaque opération générait un fichier déclarant l'engagement autorisé. Selon Unit 42, ni Zhipu GLM ni DeepSeek n'ont refusé ce cadrage.

L'humain reste dans la boucle. Dans une tâche contre un fournisseur d'équipements de semi-conducteurs, les attaquants avaient fourni des adresses de passerelles VPN (réseau privé virtuel), des noms de groupes et des mots de passe partagés. Unit 42 en déduit que des renseignements avaient été collectés au préalable.

Ce que l'analyse change, et ce qu'elle ne change pas

La conclusion d'Unit 42 est double.

Ce qui change : l'échelle. Unit 42 estime que la campagne était probablement le fait d'un seul opérateur ou d'une petite équipe, qui a mené des tentatives simultanées contre 19 organisations en deux semaines. L'orchestration autonome lève la limite qu'imposait jusqu'ici le nombre d'heures d'opérateur disponibles. Unit 42 s'attend à ce que ce type de campagne devienne plus courant, à mesure que des modèles ouverts aux garde-fous faibles gagnent en capacité.

Ce qui ne change pas : les failles. Les vulnérabilités exploitées étaient connues :

  • contournements d'authentification ;
  • références directes à des objets non protégées (IDOR, quand une application donne accès à un objet sur la seule foi de son identifiant) ;
  • élévation de privilèges par affectation de masse (quand une API accepte des champs qu'elle ne devrait pas laisser modifier, comme un rôle) ;
  • identifiants faibles ou par défaut ;
  • API cloud exposées ;
  • CVE publiques anciennes.

Unit 42 le formule ainsi : l'IA autonome augmente le volume et la couverture de l'exploitation, pas sa complexité. L'hygiène des identités, la réduction de la surface d'attaque et l'application des correctifs restent efficaces.

Qui est concerné

  • Les secteurs visés par cette campagne : chaîne des semi-conducteurs, défense, organismes de normalisation, société civile.
  • Toute organisation dont la surface exposée contient des faiblesses de cette liste. Selon Unit 42, les attaquants démarraient chaque opération à partir du seul domaine racine, en ajoutant parfois des informations recueillies au préalable.
  • Les éditeurs et utilisateurs d'outils de test d'intrusion par IA, puisque l'outil employé est un projet public conçu pour un usage légitime.

Se défendre : traiter la liste d'Unit 42 comme un plan de travail

Les six catégories d'Unit 42 se prêtent à des contrôles vérifiables. Les mesures ci-dessous sont des bonnes pratiques classiques associées à chaque catégorie.

Identifiants faibles et par défaut. Activez l'authentification à plusieurs facteurs sur tout ce qui est exposé, y compris les applications d'intégration partenaires et les accès VPN. Bloquez les tentatives répétées. Supprimez les mots de passe partagés entre plusieurs comptes ou sites, comme ceux que les attaquants détenaient ici pour des passerelles VPN.

Contournements d'authentification et inscriptions ouvertes. Inventoriez les points d'inscription, de création de compte et de réinitialisation de vos applications exposées. Pour chacun, posez la question : qui peut créer un compte, et avec quels droits par défaut ?

IDOR et affectation de masse. Ajoutez aux tests de vos API deux cas systématiques : accéder à l'objet d'un autre utilisateur en changeant un identifiant, et envoyer un champ de rôle ou de privilège non prévu. Ces tests s'automatisent en intégration continue (CI).

API et stockages cloud exposés. Recherchez les stockages accessibles en écriture sans authentification. Le cas du document de norme modifié montre qu'une écriture publique sert à altérer, pas seulement à lire.

CVE anciennes. Croisez l'inventaire de vos services exposés avec les vulnérabilités connues et fixez un délai maximal de correction pour ce qui est joignable depuis Internet.

Détection. Les opérations décrites ont duré jusqu'à plus de 50 heures. En bonne pratique, surveillez dans les journaux du pare-feu applicatif et des services d'authentification les séries longues de requêtes depuis une même source. Unit 42 publie deux adresses IP de la campagne : 154.44.31[.]4, qui hébergeait Cairn, et 82.29.129[.]54, serveur de relais et de sortie des attaques, le plus susceptible d'apparaître dans les journaux d'une cible.

Tester comme l'attaquant. En bonne pratique, un test d'intrusion qui utilise lui-même un agent d'IA, cadré par contrat, peut couvrir une surface comparable. Il ne remplace pas la revue humaine des chemins d'attaque complexes ; il donne une idée de ce qu'un attaquant automatisé peut trouver sur la même surface.

Comment vérifier

  • Aucun service exposé n'accepte d'identifiant par défaut ni d'authentification sans second facteur.
  • Les points d'inscription exposés sont inventoriés, avec les droits accordés par défaut.
  • Les tests d'API couvrent l'accès aux objets d'un autre utilisateur et les champs de privilège.
  • Aucun stockage cloud n'accepte d'écriture anonyme.
  • Les CVE des services exposés sont corrigées dans le délai fixé.

FAQ

Qu'est-ce que Cairn ?

Un framework open source de test d'intrusion piloté par IA. Des agents, chacun conduit par un modèle de langage, se coordonnent via un tableau partagé pour poursuivre un objectif fixé par un opérateur.

L'IA a-t-elle découvert de nouvelles failles dans cette campagne ?

Unit 42 indique que les vulnérabilités exploitées étaient connues. L'IA a permis de mener plus d'attaques en parallèle, sans les rendre plus complexes.

Pourquoi les modèles n'ont-ils pas refusé ?

Les consignes de Cairn demandent déjà de ne jamais refuser, et les attaquants ont ajouté un préambule présentant la mission comme un test autorisé. Selon Unit 42, ni Zhipu GLM ni DeepSeek n'ont refusé ce cadrage.

Quelles priorités pour une PME ?

En bonne pratique, celles qui répondent à la liste d'Unit 42 : authentification à plusieurs facteurs sur tout ce qui est exposé, suppression des identifiants par défaut, contrôle des points d'inscription, correction des CVE anciennes sur les services exposés.

Sources

  • Unit 42 (Palo Alto Networks), Attackers Use Autonomous AI to Target Semiconductor, Defense and Civil Society Sectors, 12 novembre 2026 : https://unit42.paloaltonetworks.com/cairn-framework-ai-autonomous-attacks/
  • Cairn, dépôt GitHub : https://github.com/oritera/Cairn

Pour mesurer ce qu'un agent offensif trouverait sur votre surface exposée et sur vos propres agents, WeeSec propose un audit de sécurité IA.

Un sujet connexe chez vous ?

20 minutes pour cadrer ensemble. Aucune offre commerciale envoyée à froid.

Réserver un échange Calendly