Comment les modèles d’IA ouverts aident les hackers à trouver des vulnérabilités dans le code

Un modèle d’intelligence artificielle ouvert peut être exécuté sur son propre serveur et connecté à des outils d’analyse de logiciels. Il peut lire le code, chercher des erreurs, proposer des vérifications et en analyser les résultats. Si un attaquant utilise un tel système, il dispose d’un assistant pour la recherche de vulnérabilités dont le travail n’est pas contrôlé par un fournisseur d’IA dans le cloud.

Pour les plateformes d’échange de cryptomonnaies, les portefeuilles et les plateformes de paiement, la menace est concrète. Une erreur dans la vérification des droits, le traitement des retraits ou les interactions entre services peut constituer le point de départ d’une attaque. L’IA aide à étudier ces erreurs et à tester davantage d’hypothèses. Son efficacité dépend toutefois de la qualité du modèle, du code disponible et des outils qui vérifient ses conclusions.

Avertissement. Cet article a une vocation informative et analytique. Il vise à expliquer les menaces et les moyens de protection. Les descriptions ne constituent pas des instructions pour mener des attaques. La sécurité d’un système ne doit être testée qu’avec l’autorisation de son propriétaire. Les exemples concernant les services crypto illustrent des risques possibles ; les résultats des tests de recherche ne correspondent pas à la probabilité de compromettre une entreprise en activité.

Pourquoi les hackers exécutent des modèles d’IA sur leurs propres serveurs

Un chatbot classique dans le cloud a un opérateur : une entreprise qui exploite le modèle, fixe les règles et peut limiter l’accès. Un modèle téléchargé fonctionne autrement. Son propriétaire choisit où il est exécuté, quelles données il reçoit et à quels programmes il a accès.

Le terme plus précis est « modèle à poids ouverts », ou open-weight. Les poids sont les paramètres acquis par le modèle pendant son entraînement. Leur accessibilité permet d’exécuter le modèle de manière autonome, même si les données d’entraînement et tous les détails de sa création restent privés. Des systèmes légitimes fonctionnent aussi ainsi, notamment les outils d’analyse de code confidentiel d’entreprise.

Pour un attaquant, l’auto-hébergement est précieux parce que le développeur du modèle perd le contrôle de l’utilisation de cette copie particulière. Il ne voit pas chaque requête et ne peut pas arrêter son fonctionnement en bloquant un compte. L’AI Security Institute britannique souligne précisément ce risque : une fois les poids publiés, les contrôles des services cloud ne peuvent pas être appliqués à tous les déploiements indépendants.

Un modèle ouvert n’est pas nécessairement dépourvu de garde-fous. Cependant, son opérateur peut modifier l’environnement logiciel et le modèle lui-même afin de les affaiblir. Dans ce cas, obtenir un outil dangereux ne nécessite pas de pirater l’entreprise qui a créé l’IA.

Une nuance importante s’impose : l’absence d’interdictions n’améliore pas, à elle seule, la capacité à trouver des erreurs. L’efficacité résulte de l’association d’une bonne analyse du code, d’outils adaptés et de retours d’information. La suppression des restrictions permet d’utiliser ces capacités à des fins malveillantes.

Comment l’IA cherche des vulnérabilités dans le code d’un service

Imaginons un service de paiement composé de plusieurs milliers de fichiers. La vérification des droits se trouve dans un module, la gestion des comptes dans un autre et le traitement des retraits dans un troisième. Pour repérer une erreur dangereuse, il faut comprendre les liens entre ces éléments.

L’IA peut aider à reconstituer ce lien : d’où provient une valeur, quels contrôles elle traverse et quelle opération l’utilise finalement. Par exemple, le modèle constate qu’un gestionnaire vérifie que l’utilisateur est connecté, mais pas que le compte demandé lui appartient. Il s’agit d’une catégorie connue d’erreurs d’autorisation que l’OWASP décrit sous le nom de Broken Object Level Authorization. Autrement dit, le service a reconnu l’utilisateur sans vérifier qu’il avait le droit d’agir sur l’objet concerné.

Une explication convaincante ne suffit pas. Le modèle peut avoir ignoré un contrôle dans un autre fichier ou mal compris le rôle d’une fonction. On le connecte donc à un environnement logiciel qui lui fournit les fragments de code pertinents, exécute des tests et renvoie les résultats. Le modèle propose une hypothèse, reçoit la réponse du programme et affine sa conclusion. C’est ainsi que fonctionne un agent d’IA d’analyse de code : il peut poursuivre son investigation après sa première réponse.

Sur une copie isolée de l’application, ce système vérifie si l’erreur se produit réellement. Si un test échoue, l’agent en analyse la cause. Si la vulnérabilité supposée est également détectée dans la version corrigée, il faut remettre le test en question. Les auteurs de l’étude de Semgrep utilisent ce type de vérification pour distinguer la compréhension de l’erreur d’une réaction à des noms et à des fragments de code familiers.

La répétition modifie la valeur pratique de l’IA. Une personne n’a pas à examiner manuellement chaque résultat intermédiaire : une partie de ce travail est confiée à l’agent. Toutefois, configurer l’environnement, vérifier les résultats et évaluer les conséquences exige toujours des ressources et des compétences.

Le code source ne devient pas non plus accessible au modèle automatiquement. Celui-ci peut étudier les dépôts publics, le code publié des contrats intelligents et le code côté client d’un site. Le code privé du serveur ne devient accessible qu’à la suite d’une fuite distincte ou d’une autorisation d’accès. Sans lui, il reste la documentation et le comportement observable du service, qui donnent une vision beaucoup moins complète.

Ce que les modèles ouverts savent déjà faire en pratique

Pour évaluer la menace, nous avons comparé les tests publiés de modèles et les analyses d’activité d’attaquants. Nous avons examiné les données fournies à l’IA, le nombre de tentatives autorisées et ce que les chercheurs considéraient comme une réussite. Cela permet de distinguer le repérage de code suspect, la confirmation d’une erreur et la pénétration effective d’une infrastructure.

Aikido a publié un résultat éclairant en août 2026. Les chercheurs ont testé des modèles sur 32 vulnérabilités récemment divulguées dans des projets réels. Les modèles disposaient du code source, mais l’accès à internet était désactivé. La comparaison portait sur l’étape principale d’analyse au sein d’un système commun, et non sur le fonctionnement autonome de chaque modèle sans outils supplémentaires.

DeepSeek V4 Pro 0813 a détecté 17 vulnérabilités lors du premier passage. En réunissant les résultats de trois passages, on arrive à 28 sur 32. Pourtant, le modèle n’en retrouvait systématiquement que 10 lors des trois passages.

Cela représente 87,5 % des vulnérabilités trouvées au moins une fois et 31,3 % trouvées à chacune des trois tentatives. Nous avons calculé ces pourcentages à partir des chiffres publiés. Cet écart explique pourquoi une réponse isolée décrit mal les capacités du système : répéter les vérifications élargit la couverture, mais les résultats restent instables. Il s’agit d’un test de redécouverte de failles connues, pas d’un indicateur de réussite du piratage de plateformes crypto.

L’évaluation de l’AI Security Institute offre une perspective plus large. Dans les tâches utilisées, les meilleurs modèles ouverts atteignaient le niveau de modèles fermés publiés quatre à sept mois auparavant. Cette évaluation concerne des tests précis, notamment des réseaux préparés artificiellement, et non un classement universel. Pour les défenseurs, cela signifie que des capacités d’analyse importantes deviennent disponibles en dehors des services cloud contrôlés.

Ce que montrent les incidents réels

En mai 2026, des chercheurs de Sysdig ont décrit une attaque exploitant une vulnérabilité de marimo, un outil de travail avec Python. Après l’intrusion initiale, l’attaquant a utilisé des identifiants découverts pour étendre son accès et atteindre une base PostgreSQL interne. En s’appuyant sur un ensemble d’indices de la session enregistrée, les auteurs ont associé les actions postérieures à l’intrusion à un agent d’IA tenant compte des résultats intermédiaires. Le modèle utilisé et son lieu d’exécution n’ont pas été établis. Le rapport ne prouve pas non plus que l’IA a découvert la vulnérabilité initiale.

Une analyse de Sysdig publiée en juin sur l’utilisation abusive de ressources de calcul tierces montre une autre partie du tableau. Un opérateur a connecté un serveur Ollama accessible sans authentification à un outil automatisé de test de sécurité. Ollama est un logiciel permettant d’exécuter des modèles sur sa propre infrastructure. Les chercheurs ont observé l’évolution de l’outil et l’ajout de nouvelles étapes de travail.

Dans cet épisode, le serveur appartenait à un tiers et les cibles se trouvaient dans des réseaux privés d’entraînement. Le cas illustre l’architecture technique et l’abus de ressources de calcul, mais ne confirme pas une attaque réussie au moyen de cet outil contre une entreprise publique.

Ces cas permettent de comprendre quelles parties du processus existent déjà. Ils ne justifient pas d’attribuer un vol précis de cryptoactifs à un modèle ouvert exécuté sur le serveur d’un hacker. Une telle conclusion nécessite des preuves supplémentaires, comme les journaux des requêtes adressées au modèle et les traces d’activité du programme associé. Des actions rapides ou inhabituelles de l’attaquant ne suffisent pas à le démontrer.

Quelles erreurs sont particulièrement dangereuses pour les services crypto

Pour une entreprise crypto, les conséquences dépendent de ce que permet la faille découverte. Accéder à une page ordinaire et pouvoir agir sur les retraits n’ont pas le même poids. Dans notre analyse du risque, nous relions donc le défaut du code aux droits du service et à l’opération financière qu’il peut modifier.

L’API, interface d’échange de données entre programmes, constitue une zone sensible. L’application l’utilise pour consulter un solde, créer des opérations et connaître leur état. Si le serveur associe incorrectement un utilisateur à un compte ou à une organisation, une session valide peut accorder des droits excessifs. Il est important de vérifier l’autorisation pour chaque action côté serveur, y compris les opérations internes et par lots moins visibles.

Un autre exemple est le traitement répété d’un même événement. Un système de paiement doit gérer correctement la réception répétée d’une notification ou l’exécution simultanée de requêtes. Si différentes parties du programme ne s’accordent pas sur l’achèvement d’une opération, des erreurs comptables peuvent apparaître. Pour l’IA, la tâche consiste à relier fichiers et états : où l’opération a été créée, quand elle a été marquée comme terminée et ce qui empêche de la traiter à nouveau. Il s’agit d’un exemple de catégorie de risque, pas de l’annonce d’une vulnérabilité découverte sur une plateforme précise.

Pour les services décentralisés, le code publié des contrats intelligents fournit du matériel d’analyse supplémentaire. Le modèle peut aider à étudier les règles d’accès et de mouvement des actifs. Mais les conclusions sur la sécurité dépendent aussi de la configuration du contrat déployé, des contrats associés et des conditions économiques. Même une erreur logicielle correctement identifiée ne permet pas toujours de voler des fonds.

Enfin, les frontières entre services sont importantes. Un composant traitant des données externes ne doit pas automatiquement obtenir le droit de signer des transactions ni accéder à tous les secrets de l’entreprise. Plus ses droits sont étendus, plus une seule vulnérabilité offre de possibilités.

Comment se défendre contre les attaques assistées par l’IA

La défense commence par l’examen du même code que l’attaquant peut étudier. La priorité doit aller à l’autorisation, au traitement des événements financiers et aux liens entre interfaces externes et services privilégiés. Pour chaque erreur découverte, il faut déterminer si elle est accessible depuis l’extérieur et quelles actions elle permet.

L’IA est également utile aux défenseurs. Une entreprise peut analyser du code privé sur sa propre infrastructure, en complément du travail des ingénieurs. Chaque découverte doit toutefois être confirmée par un test reproductible : une condition est violée dans la version vulnérable et ne l’est plus après correction. Le résultat d’un seul passage ne doit pas être considéré comme un audit complet.

Le niveau suivant consiste à limiter les conséquences. Des droits distincts par service, un accès restreint aux secrets et une vérification indépendante des paramètres de retrait réduisent le risque qu’une erreur dans un composant permette de disposer des actifs. La mise à jour des dépendances vulnérables reste indispensable : l’IA peut aider l’attaquant à exploiter des défauts déjà connus.

Lors d’une investigation, il faut relier les événements de l’application aux actions dans l’infrastructure et aux transactions blockchain. L’historique des transferts montre les mouvements d’actifs, mais n’explique généralement pas quelle erreur a permis l’accès initial. Il faut pour cela des journaux de requêtes, d’opérations et de modifications des droits. Nous recommandons donc de conserver à l’avance les données permettant de reconstituer le parcours d’une requête au service jusqu’à son résultat financier.

Les modèles ouverts rendent l’étude systématique du code plus accessible. Pour un service crypto, la réponse pratique consiste à tester régulièrement les opérations critiques et à concevoir le système de manière qu’une seule erreur ne donne pas accès à tous les actifs.