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

Au cours de 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 nichée en plein cœur d’un callback OAuth MCP. Prise isolément, chacune est un bug de gravité moyenne qu’un mainteneur corrige en un week-end. Prises ensemble, la grappe est 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é pour la défendre. Ce n’est pas un échec moral d’un projet en particulier. C’est exactement l’état dans lequel se trouvait le web autour de 1998, lorsqu’un langage s’est répandu dans le grand public avec des réglages par défaut non sécurisés, des identifiants partout, et une base installée qui grandissait plus vite que quiconque ne pouvait la 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. {.answer-block}

TL;DR

• Cherry Studio, un client d’agent IA de bureau populaire, a récolté 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 preload (CVE-2026-13534).¹²
• Le schéma n’est pas propre à une seule application. L’outillage de référence MCP lui-même a 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 trouvent à l’intérieur de vos frontières de confiance (IDE, shell, navigateur) plutôt que derrière elles.
• Les connaissances pour prévenir ces bugs existent déjà. La spécification MCP documente en détail les classes d’attaques du député confus et des flux OAuth ; la culture pour l’appliquer à chaque intégration développée à la hâte ne se propage pas encore.⁵
• Le web de 1998 n’a mûri qu’après que des vers ont rendu l’insécurité coûteuse. L’écosystème des agents n’a pas encore de force de contrainte équivalente, et les mêmes modèles qui trouvent aujourd’hui ces bugs peuvent écrire celui qui la 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 genre d’outil dont parle cet essai : un agent grand public qui gère vos clés API, exécute des intégrations locales et se connecte au réseau en votre nom.

Le 29 juin 2026, VulDB a publié deux avis à son sujet. 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 sans détour : « La manipulation de l’argument code mène à 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 preload CherryIN, jusqu’à la version 1.9.7, avec un score de 5.0.² Aucune ne fait la une. Toutes deux sont la discrète erreur d’autorisation qu’une équipe commet en avançant 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 bug exotique et inédite. C’est celle à laquelle le propre 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, car la grappe se doit d’être réelle : CVE-2026-13533 concerne agentejo Cockpit CMS, un gestionnaire de contenu PHP plutôt qu’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 étoffée artificiellement.

Pourquoi les outils d’agents sont structurellement plus mal lotis

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

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

Simon Willison a nommé le danger avec précision en juin 2025 avec la « triade létale » : 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 peut voler ces données.⁷ Tout agent compétent possède les trois par défaut, car lire vos secrets, ingérer du contenu influencé par un attaquant et effectuer des requêtes sortantes sont ses fonctionnalités, non ses bugs. La triade n’est pas un cas marginal. C’est la configuration de base.

Voilà la différence structurelle. L’application web de 1998 devait être trompée pour laisser fuiter la valeur d’une frontière de données. L’agent de 2026 arrive précâblé avec toutes les capacités dont une chaîne d’exfiltration a besoin, 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, c’est ce à 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. La base installée d’intégrations dépasse 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 commande OS 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 propre MCP Inspector d’Anthropic, où l’absence de vérification d’authentification permettait à un site web malveillant d’atteindre un port local et, via DNS rebinding, 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 de endpoint. Ce n’est pas une coïncidence. OAuth dans un client d’agent est une frontière maladroitement gérée à répétition, et la spécification le dit haut et fort. Le document de bonnes pratiques de sécurité MCP, daté du 18 juin 2025, consacre sa plus longue section au « problème du député confus », et impose que les serveurs proxy mettent en œuvre 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. Le fossé n’est pas celui du savoir. C’est la distance entre l’annexe sécurité d’une spécification et l’intégration médiane écrite mardi dernier.

La prompt injection rend l’amplification qualitativement pire que tout ce à quoi l’ancien web a été confronté. Willison a forgé le terme en septembre 2022, é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 du code. Une page web empoisonnée, un fichier piégé, une description d’outil hostile : n’importe quel octet que le modèle lit peut porter une instruction. La spécification MCP est sans ambages à ce sujet, avertissant qu’un serveur malveillant peut transformer le client en proxy pour l’exfiltration de données.⁵ Vous ne pouvez pas corriger cela par échappement de l’entrée, car l’entrée est du langage naturel et 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 imprudent : les entrées externes, provenant de la query string, 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 que votre code jugeait fiable. Le correctif a pris quatre ans. PHP 4.2.0, sorti en avril 2002, a changé le réglage par défaut, et l’annonce de version le dit sans détour : « Les variables externes (provenant 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, exécutait addslashes pour simuler une protection contre l’injection SQL sans en avoir la substance, et a survécu à register_globals pendant des années avant que le projet ne la supprime enfin. Des réglages par défaut non sécurisés, une illusion de sécurité, un décalage de plusieurs années avant que la culture ne rattrape son retard. Voilà ce qu’était la couche applicative du jeune web.

La culture n’est pas arrivée d’elle-même. Elle a été imposé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 compacté en paquets de 376 octets et « a infecté la plupart des hôtes vulnérables qu’on 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 amalgamerai pas. Ce qui compte, c’est la forme de la décennie : des réglages par défaut non sécurisés à toutes les couches, et une culture de sécurité qui n’a mûri qu’après que l’insécurité est devenue viscéralement, publiquement coûteuse. Le sécurisé-par-défaut fut une leçon que l’industrie a payée en vers.

Reportez cela sur 2026 et la correspondance est inconfortable. Réglages par défaut non sécurisés : des clients d’agents qui font confiance aux codes de callback et sautent les vérifications de consentement. L’illusion de sécurité : une invite de permission au-dessus d’un token dont la portée est admin:*. La base installée 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 force de contrainte.

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 la triade comme liste de contrôle opérationnelle : pour tout agent, demandez-vous ce qu’il peut lire, ce qu’il peut exécuter et ce qu’il peut exfiltrer, et posez une protection déterministe sur chacun.

La colonne protection n’est pas un vœu pieux. Elle est déterministe, et le déterminisme est bien là l’essentiel. 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 contester, et les règles de permission s’évaluent avant qu’un outil ne s’exécute, 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 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 a l’apparence d’une fonctionnalité de productivité, mais en est en réalité une de sécurité. Lorsqu’un agent compile son travail en un plan révisable avant de l’exécuter, réviser 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 en direct ; vous pouvez auditer le plan qui les générerait, avant qu’il ne dépense quoi que ce soit.

Et gardez l’asymétrie à l’esprit : la même capacité qui produit ces CVE les trouve aussi. Un chercheur d’Anthropic a utilisé un agent de codage et un script de dix lignes pour faire remonter une vulnérabilité du noyau Linux vieille de 23 ans et 22 CVE 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 triage en ce moment. C’est le seul avantage que le web de 1998 n’avait pas.

La position

Voici ce qui, selon moi, va se produire, assez précis pour avoir tort. L’écosystème des agents connaîtra son moment Code Red avant d’acquérir sa culture de sécurité, car c’est l’ordre dans lequel le web l’a fait. La force de contrainte sera très probablement une charge de prompt injection auto-propagée circulant entre agents via des serveurs MCP partagés, ou un événement d’exfiltration massive d’identifiants remontant à une intégration populaire et peu auditée. Elle sera peu coûteuse à construire, car les mêmes modèles qui trouvent des bugs du noyau peuvent l’écrire, et l’avertissement d’« une grande vague qui 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 token validées, des callbacks qui rejettent les URI de redirection non concordantes, à la manière dont 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.

La partie inconfortable, c’est le calendrier. Le web a mis à peu près de 1998 à 2005 pour intérioriser le sécurisé-par-défaut, avec des années entre les vers pour réfléchir. La pile d’agents s’aggrave plus vite, avec une cible à plus forte 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èle. 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.

Points clés à retenir

• Effectuez l’audit de la triade sur chaque agent. Notez ce que chaque outil peut lire, exécuter et exfiltrer, puis confirmez une protection déterministe sur chaque ligne. Une capacité sans protection, c’est votre exposition, et l’endroit où atterrira la prochaine charge.
• Mettez les serveurs MCP en liste blanche ; traitez chaque paramètre de commande comme une exécution non fiable. Ajouter une intégration se fait en un clic, l’auditer non, alors verrouillez l’enregistrement derrière une liste révisée. Deux des quatre CVE présenté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 moment de planification le point de contrôle de la revue. Faites compiler par les agents l’intention en un plan révisable et lisez-le comme un modèle de menace avant l’exécution. Un script qui nomme ses outils et ses fichiers est auditable en une minute ; dix mille appels d’outils en direct ne le sont pas.
• Pointez d’abord le scanner sur vous-même. 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 contre 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’attaques, député confus, token passthrough, SSRF, compromission de 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 blanche et partez du principe que tout serveur auquel vous vous connectez peut influencer votre agent.

Qu’est-ce que la prompt injection ?

La prompt injection, c’est lorsqu’un attaquant glisse 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 un seul prompt que le modèle interprète ensuite, sans moyen fiable de distinguer quelle partie était celle de l’attaquant.⁶ Pour les agents, elle est particulièrement dangereuse, car la donnée devient un vecteur, et l’échappement ne peut pas y remédier, car l’interpréteur est un modèle de langage.

Qu’est-ce que la triade létale ?

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 doté des trois peut être manipulé par du contenu injecté pour lire vos secrets et les expédier à un attaquant. La plupart des agents compétents possèdent les trois par défaut, ce qui explique pourquoi la démarche consiste à protéger chaque capacité plutôt qu’à espérer que le modèle résiste.

Comment sécuriser un agent qui s’exécute 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 qui s’évaluent avant qu’un outil ne s’exécute, afin qu’un prompt compromis ne puisse pas s’ouvrir par la parole la voie vers une action que vous avez interdite. Mettez en liste blanche les outils et les serveurs MCP, exigez un consentement avant qu’un nouveau serveur local ne s’exécute, et attribuez à chaque identifiant le moindre privilège afin qu’un token volé n’ait qu’un faible rayon d’impact. Bloquez les requêtes sortantes vers les plages d’IP privées et link-local pour fermer la voie d’exfiltration. Ensuite, révisez le plan de l’agent avant les grosses opérations, là où l’injection qui a survécu à la frontière de lecture se fait attraper.

Sources