Des modèles de langage en dialogue peuvent automatiser des exploits, selon une étude

Les modèles de langage ne se limitent plus à résumer des textes ou à aider à programmer : placés dans un dialogue structuré, ils peuvent aussi se répartir les tâches nécessaires à l’analyse d’une vulnérabilité informatique. C’est le constat exploratoire d’une étude publiée dans la revue Computer Networks, qui examine comment ChatGPT et Llama 2 peuvent collaborer pour aboutir à la génération d’un exploit fonctionnel dans un environnement vulnérable.

Le sujet mérite d’être abordé avec précision. Un exploit n’est pas un virus par nature : il s’agit d’un code ou d’une séquence d’actions qui tire parti d’une faille pour provoquer un comportement non prévu d’un programme. Dans de mauvaises mains, il peut ouvrir la voie à une intrusion. Dans un cadre autorisé, il sert aussi aux chercheurs et aux équipes de sécurité à vérifier qu’une vulnérabilité est réellement exploitable et doit être corrigée en priorité.

Au 20 juillet 2025, les travaux dirigés par Simon Pietro Romano ne décrivent pas une machine capable de compromettre indistinctement n’importe quel système. Ils mettent plutôt en évidence un principe : une conversation bien orchestrée entre plusieurs grands modèles de langage, ou LLM, peut découper un problème de sécurité complexe en sous-tâches complémentaires. Cette possibilité brouille un peu plus la frontière entre assistance logicielle utile et capacité offensive automatisée.

Ce que l’étude a réellement démontré

La création d’un exploit est habituellement une activité exigeante. Elle suppose de lire du code, de comprendre le fonctionnement d’un programme et de son environnement, de repérer l’origine précise d’un défaut, puis de vérifier que le comportement obtenu est reproductible. Cette chaîne de raisonnement est traditionnellement réservée à des spécialistes de la sécurité, de la programmation bas niveau et de l’architecture des systèmes.

L’étude publiée dans Computer Networks pose une question simple : des modèles de langage généralistes peuvent-ils contribuer à automatiser ce travail lorsqu’ils ne travaillent pas seuls, mais en dialogue ? Pour y répondre, les chercheurs ont mis en place un protocole faisant interagir ChatGPT et Llama 2.

L’idée n’est pas de faire écrire à un unique assistant l’ensemble du résultat en une fois. Les deux modèles se voient attribuer des fonctions distinctes. L’un recueille et organise les éléments de contexte relatifs au logiciel vulnérable. L’autre intervient dans la production du code requis. Des incitations, appelées aussi prompts, guident cet échange pour conserver une progression cohérente entre les étapes.

Les auteurs rapportent un résultat préliminaire : cette méthode a permis de générer du code fonctionnel dans le cas d’un exploit de dépassement de tampon. Ce type de vulnérabilité survient lorsqu’un programme écrit davantage de données que l’espace mémoire prévu pour les recevoir. Il peut alors altérer le fonctionnement du logiciel, avec des conséquences qui dépendent du contexte technique.

Pourquoi faire dialoguer deux modèles de langage ?

Un LLM peut produire une réponse convaincante tout en commettant une erreur de raisonnement ou en inventant un détail technique. C’est une limite bien connue des modèles génératifs. Faire dialoguer plusieurs systèmes ne supprime pas ce problème, mais permet de découper une tâche longue et de confier à chaque agent un objectif plus étroit.

Dans le dispositif étudié, cette division du travail sert surtout à relier des informations qui, prises isolément, ne suffisent pas à caractériser une faille exploitable. Le premier modèle peut par exemple organiser les éléments relatifs au programme concerné, tandis que le second utilise ce contexte dans la phase de génération. Le processus demeure piloté par des consignes soigneusement formulées et par un enchaînement précis des échanges.

Les chercheurs identifient cinq grandes étapes. Elles illustrent les compétences que doit réunir un système d’assistance à l’analyse offensive, sans pour autant constituer une recette universelle :

Ce découpage compte autant que le résultat final. Il montre que les modèles de langage peuvent servir d’outils de coordination : ils transforment une demande générale en une succession de problèmes plus limités. Or cette capacité est utile aux défenseurs comme aux attaquants.

Exploit, vulnérabilité et test de pénétration : de quoi parle-t-on ?

Le vocabulaire de la cybersécurité peut donner l’impression que tout se confond. Pourtant, une vulnérabilité, un exploit et un test de pénétration désignent des réalités différentes.

Une vulnérabilité est un défaut dans un logiciel, une configuration ou un protocole. Elle peut exister sans avoir été découverte, et elle n’est pas toujours facile à utiliser. Un exploit est le moyen technique de tirer parti de ce défaut. Enfin, un test de pénétration, souvent appelé pentest, est une évaluation autorisée qui cherche à simuler des scénarios d’attaque pour mesurer la résistance d’une organisation.

Les équipes de sécurité utilisent ces exercices pour hiérarchiser les correctifs. Une faille dont l’exploitation est démontrée mérite en général une attention plus rapide qu’un problème hypothétique. Les évaluations de vulnérabilité et les tests de pénétration, parfois regroupés sous l’acronyme VAPT pour Vulnerability Assessment and Penetration Testing, sont donc des pratiques défensives lorsqu’ils sont menés avec l’accord explicite du propriétaire du système.

Une baisse possible de la barrière technique

Le principal motif d’inquiétude soulevé par l’étude est l’accessibilité. Si des modèles de langage peuvent prendre en charge une partie de l’analyse, de la planification et de la production de code, ils risquent de réduire le niveau de compétences nécessaire pour s’engager dans des activités offensives. Cette réduction ne signifie pas que toute personne peut devenir experte du jour au lendemain. Elle peut toutefois accélérer certaines étapes et aider à formuler des pistes qu’un utilisateur peu expérimenté n’aurait pas su explorer seul.

C’est précisément l’une des ambiguïtés majeures des outils à double usage. La même capacité peut aider une équipe de sécurité à vérifier rapidement une alerte, ou aider un acteur malveillant à chercher comment tirer profit d’un défaut. La technologie ne détermine pas seule l’intention, mais elle modifie les moyens disponibles.

Plusieurs limites tempèrent néanmoins l’idée d’une automatisation totale. Les LLM peuvent mal interpréter un extrait de code, négliger une protection mise en place par le système ou produire des réponses plausibles mais erronées. Ils n’observent pas spontanément un environnement réel et ne remplacent ni les tests contrôlés, ni la connaissance de l’infrastructure, ni le jugement d’un spécialiste. Dans l’étude, le caractère préliminaire du résultat doit donc rester central.

Quelles conséquences pour les défenseurs ?

Pour les entreprises, administrations et éditeurs de logiciels, ces travaux renforcent une idée déjà bien établie : une vulnérabilité connue doit être traitée vite, même lorsqu’elle paraît difficile à exploiter. Les outils d’IA peuvent réduire le temps nécessaire à l’exploration d’un défaut, et donc raccourcir la période durant laquelle une organisation reste exposée après la divulgation d’un problème.

La réponse ne consiste pas à renoncer à l’IA dans les équipes de sécurité. Au contraire, les mêmes mécanismes de dialogue entre agents peuvent assister les défenseurs dans le tri des alertes, l’analyse de code, la documentation des risques ou la préparation de tests autorisés. La différence se joue dans l’encadrement : périmètre clairement défini, données de test isolées, validation humaine et traçabilité des actions.

Les organisations peuvent en tirer plusieurs priorités concrètes, sans avoir à reproduire les expérimentations décrites par l’étude :

• maintenir à jour les logiciels et appliquer rapidement les correctifs de sécurité ;
• inventorier les services exposés afin de savoir quels systèmes sont réellement concernés par une faille annoncée ;
• segmenter les réseaux et limiter les privilèges, pour réduire les conséquences d’une compromission ;
• encadrer l’usage des assistants d’IA par les équipes techniques, notamment lorsqu’ils reçoivent du code ou des informations internes ;
• privilégier les tests de sécurité réalisés dans un cadre contractuel, documenté et isolé.

La question de la diffusion des capacités est également posée aux éditeurs de modèles. Les garde-fous mis en place dans les assistants conversationnels visent notamment à limiter l’aide à des actions informatiques nuisibles. Mais une étude comme celle-ci rappelle que le risque ne dépend pas uniquement d’une réponse isolée : il peut résulter de la coordination de plusieurs échanges, de la disponibilité d’informations contextuelles et de la persévérance d’un utilisateur.

Ce qu’il faut surveiller

Les travaux de Simon Pietro Romano et de son équipe ouvrent d’abord un chantier de recherche. Leur objectif annoncé est d’approfondir l’efficacité de cette méthode, tout en contribuant à des mesures de cybersécurité plus robustes. L’automatisation des évaluations de vulnérabilités et des tests de pénétration pourrait devenir un usage important, à condition d’être déployée dans des environnements contrôlés et au service de la défense.

Il faudra suivre la fiabilité réelle de ces systèmes sur une variété de vulnérabilités, leur capacité à reconnaître leurs propres incertitudes et la part de validation humaine qui reste indispensable. Un système qui accélère l’analyse sans fournir de garanties peut aussi multiplier les faux positifs, faire perdre du temps aux équipes ou créer une fausse impression de sécurité.

La tendance de fond est plus large que ce seul cas d’étude : les LLM deviennent des interfaces capables d’orchestrer des outils et de répartir des tâches. En cybersécurité, cette évolution rend la rapidité de correction, la qualité des pratiques de développement et la surveillance des systèmes encore plus cruciales. L’IA ne remplace pas l’expertise humaine, mais elle peut modifier l’échelle et la vitesse auxquelles les défenseurs comme les attaquants travaillent.