La pile d'agents a un problème de 1998

Durant la dernière semaine de juin 2026, une petite grappe de CVE a frappé l’outillage des agents IA, dont deux dans le même client d’agent de bureau, toutes deux des failles d’autorisation, l’une logée en plein cœur d’un callback OAuth MCP. Lue isolément, chacune n’est qu’une faille de sévérité moyenne qu’un mainteneur corrige en un week-end. Lues ensemble, elles forment un signal, et ce signal est structurel : l’écosystème des agents IA accumule de la surface d’attaque plus vite qu’il n’accumule la culture de sécurité capable de la défendre. Ce n’est pas la faute morale d’un projet en particulier. C’est exactement l’état dans lequel se trouvait le web vers 1998, quand un langage s’est répandu avec des réglages par défaut non sécurisés, que les identifiants traînaient partout et que le parc installé croissait plus vite que quiconque ne pouvait le durcir. Les outils qui détiennent vos clés et exécutent votre shell sont livrés avec une maturité de sécurité de 1998 face à un modèle de menace de 2026.

TL;DR

• Cherry Studio, un client d’agent IA de bureau très répandu, a écopé de deux CVE le 29 juin 2026 : une faille d’autorisation incorrecte dans son serveur de callback OAuth MCP (CVE-2026-13524) et un contournement d’autorisation dans une API de préchargement (CVE-2026-13534).¹²
• Le schéma n’est pas propre à une seule application. L’outillage de référence de MCP a lui-même livré des failles critiques d’exécution de code à distance en 2025 : mcp-remote à CVSS 9,6 (CVE-2025-6514) et le MCP Inspector d’Anthropic à CVSS 9,4 (CVE-2025-49596).³⁴
• Les outils d’agents sont structurellement plus exposés que ne l’ont jamais été les applications web : ils détiennent des identifiants, exécutent du code par conception et se tiennent à l’intérieur de vos frontières de confiance (IDE, shell, navigateur) plutôt que derrière elles.
• Le savoir nécessaire pour éviter ces bugs existe déjà. La spécification MCP documente en détail les classes d’attaque de l’adjoint confus et des flux OAuth ; la culture qui l’appliquerait à chaque intégration développée à toute vitesse, elle, ne se propage pas encore.⁵
• Le web de 1998 n’a mûri qu’une fois que les vers ont rendu l’insécurité coûteuse. L’écosystème des agents n’a pas encore de fonction de forçage équivalente, et les modèles mêmes qui trouvent aujourd’hui ces bugs peuvent écrire celui qui le deviendra.

La grappe, concrètement

Cherry Studio est un client de bureau multiplateforme qui se présente comme un « studio de productivité IA doté d’un chat intelligent, d’agents autonomes et de plus de 300 assistants », avec une prise en charge explicite des serveurs Model Context Protocol. C’est exactement le type d’outil dont parle cet essai : un agent grand public qui gère vos clés d’API, exécute des intégrations locales et sollicite le réseau en votre nom.

Le 29 juin 2026, VulDB a publié deux avis à son encontre. CVE-2026-13524 est une faille d’autorisation incorrecte (CWE-285) dans le MCP OAuth Local Callback Server, dans src/main/services/mcp/oauth/callback.ts, pour les versions 1.9.0 à 1.9.6. Le libellé est limpide : « La manipulation de l’argument code conduit à une autorisation incorrecte. » Elle obtient un score CVSS 3.1 de 5,6, moyen.¹ CVE-2026-13534 est un contournement d’autorisation (CWE-639) dans l’API de préchargement CherryIN, jusqu’à la version 1.9.7 incluse, avec un score de 5,0.² Aucune ne fait la une. Toutes deux sont l’erreur d’autorisation discrète que commet une équipe qui avance vite sur une surface nouvelle pour tout le monde.

La première est révélatrice. Un callback OAuth dans un client MCP est une frontière de confiance de manuel : le point où un serveur d’autorisation externe renvoie un code à votre machine et où votre machine décide de lui faire confiance ou non. Le mal gérer n’est pas une classe de bugs exotique et inédite. C’est celle à laquelle le document de sécurité de la spécification MCP consacre le plus d’encre.

J’ai écarté deux CVE voisines de la même fenêtre, parce que la grappe doit être réelle : CVE-2026-13533 concerne agentejo Cockpit CMS, un gestionnaire de contenu PHP et non un framework d’agents, et CVE-2026-13543 n’a pas pu être vérifiée du tout. Quelques exemples solides valent mieux qu’une liste gonflée.

Pourquoi les outils d’agents sont structurellement plus mal lotis

Une application web classique de 1998 était non sécurisée, mais elle vivait derrière une frontière. Elle tournait sur un serveur dans lequel vous ne vous trouviez pas, son rayon d’action se limitait à la base de données et à la session, et une compromission donnait à l’attaquant les données de l’application.

Un outil d’agent inverse cette géométrie. Il tourne sur votre machine ou dans votre IDE, détient des identifiants à longue durée de vie vers votre cloud et vos dépôts, et exécute du code comme fonctionnalité centrale plutôt que comme exploit. Il n’existe aucune frontière derrière laquelle s’abriter, parce que l’outil est la frontière, et qu’elle est poreuse par conception.

Simon Willison a nommé le danger avec précision en juin 2025 avec le « trio mortel » (lethal trifecta) : un agent devient exploitable lorsqu’il combine « l’accès à vos données privées », « l’exposition à du contenu non fiable » et « la capacité de communiquer vers l’extérieur » d’une manière qui permet de dérober ces données.⁷ Tout agent capable possède les trois par défaut, car lire vos secrets, ingérer du contenu influencé par un attaquant et émettre des requêtes sortantes sont ses fonctionnalités, non ses défauts. Le trio n’est pas un cas limite. C’est la configuration de base.

Voilà la différence structurelle. L’application web de 1998 devait être piégée pour laisser fuir la valeur d’une seule frontière de données. L’agent de 2026 arrive précâblé avec toutes les capacités dont a besoin une chaîne d’exfiltration, et la seule chose qui sépare une entrée malveillante de vos identifiants, c’est de savoir si l’outil a correctement tracé ses frontières de confiance internes. Le bug de callback de Cherry Studio, voilà à quoi cela ressemble quand l’une de ces frontières est tracée un peu de travers.

L’amplification MCP

Model Context Protocol est le tissu conjonctif de la pile d’agents de 2026, et il multiplie la surface d’une manière bien précise : chaque serveur MCP est une nouvelle intégration privilégiée, généralement écrite à la hâte, que le modèle peut invoquer. En ajouter un se fait sans friction. En auditer un, non. Le parc installé d’intégrations distance la population de gens qui en lisent le code.

L’outillage de référence montre que ce n’est pas un problème de projet amateur. En juillet 2025, JFrog a divulgué CVE-2025-6514, une injection de commandes système dans mcp-remote, un connecteur utilisé par Claude Desktop, Cursor et Windsurf, qu’un serveur malveillant déclenche avec une URL authorization_endpoint forgée pendant le flux OAuth : critique, CVSS 9,6.³ Le même mois, Tenable a divulgué CVE-2025-49596, une faille d’exécution de code à distance notée 9,4 dans le MCP Inspector d’Anthropic, où l’absence de contrôle d’authentification permettait à un site web malveillant d’atteindre un port local et, par réattribution DNS, d’exécuter des commandes arbitraires.⁴

Deux des quatre CVE de cet essai sont des failles de flux OAuth dans l’outillage MCP : l’une dans le serveur de callback, l’autre dans la découverte des endpoints. Ce n’est pas une coïncidence. OAuth dans un client d’agent est une frontière ratée à répétition, et la spécification le dit tout haut. Le document « Security Best Practices » de MCP, daté du 18 juin 2025, consacre sa plus longue section au « problème de l’adjoint confus » (confused deputy) et impose que les serveurs mandataires implémentent un consentement par client, valident le paramètre OAuth state et fassent correspondre exactement les URI de redirection.⁵ Cela a été publié un an avant que Cherry Studio ne livre son bug de callback. L’écart ne tient pas au savoir. Il tient à la distance entre l’annexe sécurité d’une spécification et l’intégration médiane écrite mardi dernier.

Le prompt injection rend l’amplification qualitativement pire que tout ce qu’a connu l’ancien web. Willison a forgé le terme en septembre 2022, en écrivant « Je propose que le nom évident pour cela soit prompt injection », par analogie avec l’injection SQL : des instructions de confiance et une entrée non fiable concaténées en une seule chaîne qu’un moteur interprète ensuite.⁶ Pour un agent, la donnée est un vecteur, pas seulement le code. Une page web empoisonnée, un fichier piégé, une description d’outil hostile : le moindre octet lu par le modèle peut porter une instruction. La spécification MCP est catégorique là-dessus et avertit qu’un serveur malveillant peut transformer le client en relais d’exfiltration de données.⁵ Vous ne pouvez pas corriger cela par échappement de l’entrée, parce que l’entrée est du langage naturel et que l’interpréteur est un modèle.

L’analogie de 1998, rendue précise

L’analogie doit survivre à la vérification des faits, sinon ce n’est qu’une impression ; voici donc l’époque, avec exactitude.

PHP 3 est sorti en juin 1998 et a mis un langage web dynamique entre des millions de mains, avec un réglage par défaut qui paraît aujourd’hui téméraire : les entrées externes, venues de la chaîne de requête, des cookies ou du serveur, étaient enregistrées directement dans la portée globale. register_globals était activé, et une variable contrôlée par un attaquant pouvait discrètement devenir une variable à laquelle votre code faisait confiance. Le correctif a pris quatre ans. PHP 4.2.0, sorti en avril 2002, a changé ce réglage par défaut, et l’annonce de version le dit sans détour : « Les variables externes (issues de l’environnement, de la requête HTTP, des cookies ou du serveur web) ne sont plus enregistrées dans la portée globale par défaut. »⁸ L’autre béquille emblématique de l’époque, les magic quotes, appliquait addslashes pour simuler une protection contre l’injection SQL sans en avoir la substance, et a survécu de plusieurs années à register_globals avant que le projet ne finisse par la supprimer. Des réglages par défaut non sécurisés, une illusion de sécurité, plusieurs années de décalage avant que la culture ne rattrape son retard. Voilà ce qu’était la couche applicative du jeune web.

La culture n’est pas venue d’elle-même. Elle a été forcée. Le 19 juillet 2001, le ver Code Red a exploité un dépassement de tampon dans le serveur web IIS de Microsoft et, selon le décompte du CAIDA, « plus de 359 000 ordinateurs ont été infectés par le ver Code-Red (CRv2) en moins de 14 heures ».⁹ Le 25 janvier 2003, le ver Sapphire/Slammer a frappé un dépassement de tampon dans Microsoft SQL Server, s’est glissé dans des paquets de 376 octets et « a infecté la plupart des hôtes vulnérables qu’il pouvait trouver en moins de dix minutes », le ver à propagation la plus rapide de l’histoire jusqu’alors.¹⁰ C’étaient des vers d’infrastructure, pas des bugs PHP, et je ne les confondrai pas. Ce qui compte, c’est la forme de la décennie : des réglages par défaut non sécurisés à chaque couche, et une culture de sécurité qui n’a mûri qu’une fois l’insécurité devenue viscéralement, publiquement coûteuse. Le sécurisé par défaut est une leçon que l’industrie a payée en vers.

Reportez cela sur 2026 et la correspondance met mal à l’aise. Réglages par défaut non sécurisés : des clients d’agents qui font confiance aux codes de callback et sautent les contrôles de consentement. L’illusion de sécurité : une demande d’autorisation portant sur un jeton dont la portée est admin:*. Le parc installé qui explose : un serveur MCP pour tout, ajouté en un clic, audité par personne. Ce que l’écosystème n’a pas encore, c’est le ver. Il a les réglages par défaut de 1998 et le profil de cible de 2001, et il attend sa fonction de forçage.

La posture de l’opérateur

Vous n’avez pas le luxe d’attendre la culture. Vous utilisez ces outils dès maintenant, alors vous tracez les frontières que l’écosystème n’a pas encore tracées pour vous. Le cadre que j’emploie, c’est le trio comme liste de contrôle opérationnelle : pour chaque agent, demandez ce qu’il peut lire, ce qu’il peut exécuter et ce qu’il peut exfiltrer, et posez un garde-fou déterministe sur chacun de ces points.

La colonne des garde-fous n’a rien d’un vœu pieux. Elle est déterministe, et le déterminisme est tout l’enjeu. Les hooks se déclenchent sur des événements du cycle de vie avec des codes de sortie que le modèle ne peut pas discuter, et les règles de permission sont évaluées avant l’exécution d’un outil, pas après. C’est la couche où « l’agent ne devrait pas faire X » devient « l’agent ne peut pas faire X », et c’est la seule couche qu’une charge utile de prompt injection ne peut pas contourner par la parole. Quand vous ne pouvez pas faire confiance à l’entrée, et que vous ne pouvez pas compter sur le modèle pour se surveiller lui-même sur cette entrée, vous appliquez la contrainte à la frontière que le modèle ne contrôle pas.

Un second contrôle passe pour une fonctionnalité de productivité, mais relève en réalité de la sécurité. Quand un agent compile son travail en un plan relisible avant de l’exécuter, relire ce plan est une revue de sécurité. Un script de workflow de quarante lignes qui nomme chaque outil qu’il appellera et chaque fichier qu’il touchera est un modèle de menace que vous lisez en une minute. Vous ne pouvez pas auditer dix mille décisions prises à la volée ; vous pouvez auditer le plan qui les produirait, avant qu’il ne dépense quoi que ce soit.

Et gardez l’asymétrie en tête : la capacité même qui produit ces CVE les trouve aussi. Un chercheur d’Anthropic a utilisé un agent de code et un script de dix lignes pour faire remonter une vulnérabilité du noyau Linux vieille de 23 ans et 22 CVE de Firefox. L’outil posé sur votre bureau est un scanner de vulnérabilités pointé sur votre propre pile, si vous le pointez. Les défenseurs peuvent automatiser la découverte dès aujourd’hui et construisent la couche de tri en ce moment même. C’est le seul avantage que le web de 1998 n’avait pas.

Mise à jour du 24 août : le relevé depuis la publication

Ce billet soutenait que la grappe de juin était un signal structurel, pas de la malchance. Sept semaines de relevé depuis :

La longue traîne MCP produit un flux régulier de CVE. En une seule semaine de la mi-août, trois serveurs MCP communautaires ont écopé de CVE : injection de code dans le REPL Python de Jij-MCP-Server (CVE-2026-19964), exécution de commandes par manipulation d’arguments dans android-mcp-server (CVE-2026-19978) et falsification de requête côté serveur dans mcp-florence2 (CVE-2026-19984).¹¹¹²¹³ Toutes de sévérité moyenne — deux déclenchables à distance, la troisième locale à l’hôte sur lequel tourne l’agent — et toutes des classes classiques : injection, exec non assaini, SSRF, atterrissant dans des outils qui s’exécutent avec les privilèges d’un agent. C’est le scénario que la section sur l’amplification MCP jugeait structurel — une longue traîne de petites intégrations, chacune un mcp-remote en puissance — qui arrive maintenant à l’heure dite.

Il n’y a pas que la traîne communautaire. Azure SRE Agent — l’agent d’exploitation maison de Microsoft — a écopé de CVE-2026-62830 le 7 août : autorisation manquante permettant une élévation de privilèges par le réseau, notée 9,9 critique.¹⁴ L’argument structurel n’a jamais porté sur des mainteneurs amateurs ; il porte sur ce que sont les outils d’agents.

La recherche offensive a rattrapé la chaîne d’approvisionnement. ElasticBack a démontré une porte dérobée conditionnelle plantée dans un unique document de skill d’agent, présentant les skills comme « une chaîne d’approvisionnement émergente où une seule skill empoisonnée peut compromettre durablement chaque agent qui l’installe ».¹⁵ Et la réponse de l’écosystème à la distribution, Agent Plugins 1.0, est sortie en laissant les permissions et la provenance à la charge du client, sans la moindre couche de signature — la couche d’empaquetage est arrivée avant la couche de sécurité, exactement l’ordre dont ce billet soutenait qu’il définit toute la pile : la capacité arrive d’abord, la culture de sécurité suit avec du retard.

La prévision ci-dessous reste inchangée.

La position

Voici ce que je pense qu’il va se passer, assez précis pour pouvoir être faux. L’écosystème des agents connaîtra son moment Code Red avant d’avoir sa culture de sécurité, parce que c’est dans cet ordre que le web l’a fait. La fonction de forçage sera très probablement une charge utile de prompt injection auto-propagée circulant d’agent en agent via des serveurs MCP partagés, ou un événement d’exfiltration massive d’identifiants remontant à une seule intégration populaire et sous-auditée. Elle coûtera peu à construire, parce que les modèles mêmes qui trouvent des bugs de noyau peuvent l’écrire, et l’avertissement selon lequel « une grande vague arrive » n’a jamais concerné la seule défense.

Une fois qu’elle aura frappé, le sécurisé par défaut cessera d’être optionnel. Les clients MCP seront livrés avec les dialogues de consentement activés par défaut, les audiences de jetons validées, des callbacks qui rejettent les URI de redirection non concordantes, comme PHP a fini par être livré avec register_globals désactivé. Les couches de permission passeront de l’opt-in au refus par défaut. Les intégrations qui survivront seront celles qui auront traité l’annexe sécurité de la spécification comme la spécification elle-même.

Le point inconfortable, c’est le calendrier. Il a fallu au web de 1998 à 2005 environ pour intérioriser le sécurisé par défaut, avec des années entre les vers pour réfléchir. La pile d’agents compose plus vite, avec une cible de plus grande valeur sur la machine de chaque développeur et une chaîne d’outils d’attaquant qui s’améliore à chaque génération de modèles. Le problème de 1998 est réel. La seule question ouverte est de savoir si nous agirons sur l’analogie avant que le ver n’en écrive la fin, ou après.

À retenir

• Faites passer l’audit du trio à chaque agent. Notez ce que chaque outil peut lire, exécuter et exfiltrer, puis confirmez la présence d’un garde-fou déterministe sur chaque ligne. Une capacité sans garde-fou, c’est votre exposition, et l’endroit où atterrira la prochaine charge utile.
• Mettez les serveurs MCP en liste d’autorisation ; traitez chaque paramètre de commande comme une exécution non fiable. Ajouter une intégration prend un clic, l’auditer non : conditionnez donc l’enregistrement à une liste revue. Deux des quatre CVE citées ici étaient des bugs de flux OAuth dans des clients MCP : la poignée de main est une frontière, pas une formalité.
• Faites du temps de planification votre point de contrôle. Demandez aux agents de compiler leur intention en un plan relisible et lisez-le comme un modèle de menace avant l’exécution. Un script qui nomme ses outils et ses fichiers s’audite en une minute ; dix mille appels d’outils à la volée, non.
• Pointez le scanner sur vous-même d’abord. La capacité qui produit ces CVE les trouve aussi. Lancez des balayages de sécurité assistés par agent sur votre propre code et vos dépendances avant que quelqu’un d’autre ne lance les siens sur vous.

FAQ

Les serveurs MCP sont-ils sûrs ?

Pas par défaut, et pas de manière uniforme. MCP est un protocole ; sa sécurité dépend de la façon dont chaque serveur et chaque client l’implémentent. Les divulgations de 2025 visant mcp-remote (CVSS 9,6) et le MCP Inspector d’Anthropic (CVSS 9,4) montrent que même l’outillage de référence a livré des failles RCE critiques.³⁴ La spécification documente les principales classes d’attaque — adjoint confus, passthrough de jetons, SSRF, compromission d’un serveur local — et prescrit des mesures d’atténuation concrètes.⁵ Traitez chaque serveur comme une intégration privilégiée : n’exécutez que ceux auxquels vous faites confiance ou que vous avez audités, mettez-les explicitement en liste d’autorisation, et partez du principe que tout serveur auquel vous vous connectez peut influencer votre agent.

Qu’est-ce que le prompt injection ?

Le prompt injection, c’est lorsqu’un attaquant fait passer des instructions dans l’entrée non fiable que lit un système d’IA, et que le modèle les suit comme si elles venaient de vous. Simon Willison a forgé le terme en septembre 2022 par analogie avec l’injection SQL : des instructions de confiance et une entrée non fiable concaténées en une seule invite que le modèle interprète ensuite, sans moyen fiable de distinguer quelle partie venait de l’attaquant.⁶ Pour les agents, c’est particulièrement dangereux parce que la donnée devient un vecteur, et l’échappement n’y peut rien puisque l’interpréteur est un modèle de langage.

Qu’est-ce que le trio mortel ?

C’est le nom donné par Simon Willison, en juin 2025, aux trois capacités qui, réunies, rendent un agent exploitable : l’accès à vos données privées, l’exposition à du contenu non fiable et la capacité de communiquer vers l’extérieur.⁷ Un agent qui possède les trois peut être manipulé par du contenu injecté pour lire vos secrets et les expédier à un attaquant. La plupart des agents capables possèdent les trois par défaut, d’où la consigne : protéger chaque capacité plutôt qu’espérer que le modèle résiste.

Comment sécuriser un agent qui tourne sur ma machine ?

Commencez par la frontière que le modèle ne contrôle pas. Utilisez des règles de permission et des hooks évalués avant l’exécution d’un outil, afin qu’une invite compromise ne puisse pas s’ouvrir par la parole la voie vers une action que vous aviez interdite. Mettez les outils et les serveurs MCP en liste d’autorisation, exigez un consentement avant qu’un nouveau serveur local ne s’exécute, et donnez à chaque identifiant la portée la plus étroite possible pour qu’un jeton volé ait un faible rayon d’action. Bloquez les requêtes sortantes vers les plages d’IP privées et link-local afin de fermer la voie d’exfiltration. Relisez ensuite le plan de l’agent avant les opérations importantes, là où se fait prendre l’injection qui a survécu à la frontière de lecture.

Sources