Worm IA open-weight de l’Université de Toronto : comment un modèle gratuit peut compromettre tout un réseau

Un worm autonome guidé par un petit LLM open-weight, capable de raisonner et de générer ses propres exploits, a été démontré par l’Université de Toronto, le Vector Institute et l’Université de Cambridge dans un laboratoire isolé d’Internet. [1][2] Selon Jonas Guan, Tom Blanchard, Hanna Foerster, Hengrui Jia et leurs co‑auteurs[3], cette expérience montre qu’un attaquant peut industrialiser des campagnes offensives en s’appuyant sur des modèles gratuits déjà publiés et de la puissance de calcul volée. [1][3]

💡 À retenir
Un unique modèle open-weight exécuté sur des machines compromises suffit à piloter une campagne de compromission adaptative contre des parcs hétérogènes, sans zero‑day et avec un coût marginal quasi nul pour l’attaquant. [2][3][5]

1. Ce que démontre l’expérience de l’Université de Toronto

Les chercheurs ont exécuté leur worm IA dans un environnement de test strictement cloisonné, sans connexion au reste d’Internet, après revue avec les autorités scientifiques et de sécurité, afin d’éviter toute fuite dans le monde réel. [1][2] Objectif : caractériser le risque avant des usages malveillants. [1]

Différence clé avec un worm classique (ex. WannaCry) :

• worm traditionnel :
  • liste figée de vulnérabilités ;
  • propagation stoppée dès que les failles sont corrigées ; [2]
• worm IA :
  • observe chaque hôte ;
  • raisonne sur la configuration ;
  • synthétise en temps réel du code d’attaque adapté. [2][3]

Cette adaptation transforme un script en agent offensif semi‑autonome.

Architecture :

• petit LLM open-weight, gratuit, publié en 2025 ; [3][5]
• exécution locale sur les machines déjà compromises, avec GPU détourné ; [3]
• hôtes “légers” (IoT) qui délèguent leurs requêtes de raisonnement à ces nœuds plus puissants. [3]

📊 Chiffres clés
Sur un réseau de 33 hôtes (Linux, Windows, IoT), le worm a été testé 7 jours par campagne, sur 15 campagnes indépendantes. [3] En moyenne, il a :

• identifié 31,3 vulnérabilités ;
• obtenu un accès élevé sur 23,1 hôtes ;
• réussi à se propager à 20,4 machines. [3]

Le prototype n’exploite que :

• des vulnérabilités publiquement connues mais non corrigées ;
• des mauvaises configurations récurrentes. [3][5]

⚠️ Point clé
Aucun besoin de zero‑days ni de modèles propriétaires ultra‑puissants comme Mythos ou GPT‑5.5‑Cyber : des modèles open‑weight gratuits et un seul GPU suffisent pour des attaques adaptatives à grande échelle. [2][4][5]

2. Une nouvelle asymétrie économique et technique pour les réseaux d’entreprise

Le risque est d’abord économique :

• le worm consomme de la puissance de calcul volée, donc coût marginal quasi nul par infection ; [2][3]
• la défense doit financer en continu : patching, supervision, réponse à incident, reconstruction. [2][5]

À l’échelle de milliers de postes, cette asymétrie devient difficilement soutenable.

Chaque appareil en ligne devient une cible potentielle :

• postes utilisateurs, serveurs, clusters de calcul ;
• objets connectés (capteurs industriels, HVAC, caméras) ;
• infrastructures critiques (santé, finance, énergie). [1][3]

La démonstration confirme que la plupart des attaques réelles reposent déjà sur :

• des failles connues mais non corrigées ;
• des erreurs d’architecture, qu’un LLM peut exploiter de façon opportuniste à l’échelle du réseau. [3][5]

💼 Exemple concret
Un RSSI d’hôpital régional pourrait subir un worm IA exploitant en chaîne :

• partages SMB trop permissifs ;
• hyperviseurs non corrigés ;
• consoles d’IRM connectées avec comptes par défaut ;
  sans jamais recourir à un zero‑day, ce qui reste courant dans le médical. [1][3]

Parallèlement :

• les grands fournisseurs limitent la diffusion de modèles offensifs par crainte d’abus ; [4]
• mais les modèles open‑weight publics échappent aux garde‑fous (rate‑limit, refus de service). [2][4][5]

L’offensive IA dépasse les worms :

• Check Point a montré qu’un assistant IA avec navigation web peut servir de canal commande‑contrôle furtif, sans clé API, en profitant de la confiance accordée au trafic IA. [6]

⚡ Conséquence
La surface d’attaque GenAI explose :

• l’IA est cible (infrastructures LLM, données d’entraînement) ;
• l’IA est vecteur (malware guidé par LLM, canaux C2, worms adaptatifs). [6][7]

Les architectures de sécurité doivent couvrir tout le cycle de vie de l’IA, pas seulement le périmètre réseau. [7]

3. Se préparer à l’ère des worms IA open-weight : priorités pour les RSSI

Face à ce type d’adversaire, la première défense reste une hygiène de sécurité agressive. Le prototype de Toronto tire surtout parti de vulnérabilités connues et de mauvaises configurations. [3]

Priorités :

• industrialiser la gestion de correctifs (priorisation par exposition réseau) ;
• limiter les configurations par défaut exposées (services d’admin, partages, comptes) ;
• durcir les IoT : segmentation, mises à jour centralisées, inventaire exhaustif. [3]

Traiter la GenAI comme un périmètre à part entière :

• cartographier les modèles utilisés (internes, SaaS, open‑weight) ;
• segmenter l’infrastructure IA et filtrer les flux des nœuds GPU ;
• contrôler l’accès aux API LLM (authentification forte, quotas, journalisation) ;
• intégrer ces flux dans les politiques réseau, sans confiance implicite. [7]

📊 Renforcer le SOC avec l’IA
Un AI SOC combine :

• corrélation multi‑sources ;
• détection comportementale ;
• hyper‑automatisation de la réponse ;

pour suivre des adversaires s’appuyant eux‑mêmes sur des agents IA autonomes. [9] Cette évolution, de la simple surveillance vers une analyse plus prédictive, devient centrale face aux worms IA open-weight et plus largement aux menaces GenAI.