La connexion MCP d'OpenCode a transmis l'URL d'un serveur à PowerShell — et aucune CVE n'existe pour le signaler

Le 19 octobre 2026, Pillar Security a divulgué une faille d'exécution de code à distance dans OpenCode, l'agent de codage open source maintenu par Anomaly : un serveur distant Model Context Protocol qu'un développeur avait configuré pouvait exécuter du code arbitraire sur la machine de ce développeur pendant la connexion OAuth MCP, sans aucune invite de consentement entre-temps. La faille était limitée à Windows et au sous-système Windows pour Linux, où OpenCode transmettait l'URL de connexion fournie par le serveur à une commande PowerShell sans l'échapper. Pillar situe la plage affectée entre 1.0.137 et 1.18.32. Anomaly l'a corrigée dans la 1.18.33, publiée sur npm le 28 septembre 2026, et n'a demandé aucun CVE ni publié aucun avis — ainsi, rien dans un flux de vulnérabilités ordinaire n'indiquera à une équipe affectée qu'elle doit mettre à jour. Pillar n'a signalé aucune preuve que la faille ait été exploitée lors d'une attaque. Il s'agit d'un enregistrement parmi d'autres dans l'archive des incidents d'IA, où chaque entrée comporte ses propres sources, son niveau de gravité, sa note de confiance et son indicateur de contestation.

Ce qu'était réellement la faille

Lorsqu’un client MCP se connecte à un serveur distant qui demande une autorisation, il exécute une poignée de main de découverte OAuth. Le serveur répond par un 401 et un défi pointant vers ses documents de découverte, et un champ de ces documents — authorization_endpoint — indique au client où envoyer l’utilisateur pour se connecter. C’est une chaîne de caractères libre, et la partie qui est authentifiée est celle qui la choisit.

Dans OpenCode 1.18.32, cette chaîne est passée du réseau à un shell. Pillar a retracé le chemin depuis le document de découverte du serveur, en passant par le SDK MCP, jusqu'à oauth-provider.ts, mcp/index.ts et browser.ts, pour finir à open, le petit paquet qu'OpenCode utilise pour lancer un navigateur. Rien sur ce chemin ne vérifiait le schéma de l'URL, et rien ne le comparait à l'origine du serveur que le développeur avait configuré. La poignée de main est automatique par conception — tout l'intérêt est de vous envoyer vers une page de connexion sans vous faire copier une URL — donc aucune étape d'approbation ne se trouvait entre la réponse du serveur et le lanceur.

The launcher is where it broke. On macOS and Linux, open passes the address as an argument vector and no shell is involved. On Windows, version 10.1.2 of open — the version every affected OpenCode release pinned — builds a PowerShell command, base64-encodes it and runs it with powershell -EncodedCommand. Pillar quotes the source: the application name is escaped on one line, and the target URL is not. PowerShell evaluates $(...) subexpressions inside double-quoted strings, so an address of the form https://evil.test/$([IO.File]::WriteAllText('C:\Users\Public\pwned.txt','RCE')) runs before the browser launch fails. OpenCode discards that failure.

Deux propriétés le rendaient facile à manquer. La charge utile ne contient aucun espace, donc la normalisation d’URL la laisse intacte, et il s’agit d’une adresse https syntaxiquement ordinaire. Et le serveur n’avait pas besoin d’être hostile lors de sa configuration : Pillar note qu’une compromission ultérieure, une entrée de registre détournée, un typosquat ou un domaine expiré transformeraient chacun une entrée de configuration de confiance en mécanisme de livraison.

Qui a été exposé

La population exposée est constituée des utilisateurs de Windows et de WSL qui exécutent OpenCode avec un serveur MCP distant configuré. Pillar décrit OpenCode comme ayant environ 3 millions de téléchargements npm par semaine et 211 000 étoiles GitHub ; le rapport d’Infosecurity Magazine situe le nombre d’étoiles à plus de 218 000. Aucun de ces chiffres ne correspond à un décompte des installations affectées, et personne n’en a publié.

Le déclencheur est le seul point sur lequel les deux principaux comptes rendus divergent, et il compte à la fois pour le risque et pour la gravité. Pillar décrit l’exploitation comme ne nécessitant aucune interaction ni consentement supplémentaire de l’utilisateur. The Hacker News, dans son rapport du 22 octobre, indique que l’étape dans le navigateur ne s’exécute que lorsqu’un développeur lance la connexion — en exécutant opencode mcp auth ou en effectuant la requête correspondante — et que le simple fait d’avoir le serveur configuré, ou d’ouvrir une session, ne permet pas de l’atteindre. Dans les deux cas, le développeur ne fait rien d’inhabituel ; lancer l’authentification auprès d’un serveur déjà présent dans la configuration est une opération de routine. Mais « aucune interaction » et « une interaction de routine » sont des affirmations différentes, et cette différence alimente directement le score.

Le correctif est arrivé présenté comme une refactorisation

Pillar a signalé la faille en privé via un avis de sécurité GitHub le 29 août 2026, avec l'intégralité du matériel de reproduction. Le 25 septembre, il a relancé en dehors du fil de l'avis ; Anomaly a confirmé que le rapport était bien parvenu à son équipe et a répondu que les serveurs MCP malveillants sortaient du périmètre de son modèle de menace. Le jour même, la pull request #51414 — fusionnée sous le commit 29f07e0c — a été intégrée. Elle est décrite comme regroupant huit sites d'appel de lancement de navigateur en un seul utilitaire. La version 1.18.33 est arrivée sur npm trois jours plus tard, le 28 septembre.

Le correctif comporte trois couches. La dépendance open est passée à 11.0.4, qui encadre la cible par des guillemets simples, et PowerShell n’effectue aucune expansion à l’intérieur des guillemets simples. Un nouvel utilitaire openUrl() rejette les schémas non HTTP(S). Une vérification de schéma a été ajoutée à redirectToAuthorization lui-même, à la frontière que Pillar avait nommée dans son rapport. Ni la pull request ni les notes de version ne mentionnent une faille de sécurité, et Anomaly n’a demandé aucun CVE.

The Hacker News rapporte que la politique de sécurité publiée par Anomaly indique que les serveurs MCP qu'un utilisateur configure se trouvent « en dehors de notre périmètre de confiance », et que l'entreprise a publié des avis pour d'autres failles d'exécution de code OpenCode cette année, dont une corrigée en août. Le compte rendu de Pillar sur la réponse qu'il a reçue est plus direct : « nous avons mis à jour la dépendance, mais de manière générale, tenter de gérer un serveur MCP malveillant sort de notre modèle de menace. »

Lue comme une séquence, la chronologie place le bug OpenCode à la fin d’une chaîne de cinq ans plutôt qu’à son commencement. Le défaut qui l’a produit était déjà public, et son correctif avait déjà été livré, avant même que la ligne qui l’utilisait ne soit écrite.

Pourquoi la validation de schéma ne l’aurait pas arrêté

La solution convenue pour cette catégorie de bugs est la validation du schéma d’URL : bloquer les schémas étranges, autoriser http et https, point final. C’est ce que fournit le SDK TypeScript MCP, et c’est ce qu’OpenCode a ajouté dans la 1.18.33. La charge utile de Pillar passe chacun de ces contrôles, car elle est en https. La liste de blocage du SDK bloque javascript:, data: et vbscript: ; une liste d’autorisation http/https plus stricte a été proposée dans la pull request #841 du SDK en août 2025 et close sans être fusionnée, tandis que la pull request #877 a livré la liste de blocage à trois schémas dans la v1.17.4 — et Pillar affirme que c’était encore la politique du SDK 1.32.0 au moment de sa publication. Ce qui a réellement bouché la faille dans OpenCode, c’est la mise à jour de dépendance, pas les contrôles qui ressemblent au correctif de sécurité.

L’historique plaide contre le fait de n’y voir qu’une erreur d’un seul projet. Le paquet open porte depuis 2021 un avertissement dans son README indiquant qu’il n’offre aucune garantie de sécurité et que l’assainissement des entrées incombe à l’appelant. En octobre 2020, un utilisateur a ouvert le ticket #202 signalant qu’une URL contenant un signe dollar perdait une partie d’elle-même sous WSL 2 — l’expansion de chaîne, consignée comme un désagrément de lien cassé. En octobre 2023, un ingénieur d’Adobe a ouvert le ticket #323, « OS command injection on windows when opening urls », avec une preuve de concept d’une ligne : open('https://$(calc.exe)'). Le mainteneur a cité le README et déclaré que les pull requests améliorant l’échappement étaient les bienvenues ; le ticket a été fermé comme non planifié trois jours avant qu’open 11.0.0 ne publie tout de même l’échappement, le 15 novembre 2025. OpenCode a écrit son appel de lancement du navigateur le 7 décembre 2025, trois semaines après l’existence de la version corrigée d’open, en s’appuyant sur une version épinglée déjà vieille de plusieurs mois.

Dans les mois qui ont précédé la rédaction de cet appel, l’écosystème MCP a enregistré trois CVE sur le même sink ou le même champ : CVE-2025-6514 dans mcp-remote (CVSS 9.6, divulguée par JFrog le 9 juillet 2025), CVE-2025-58062 dans openmcp-client, et CVE-2025-10619 dans sequa-mcp. Le contraste établi par Pillar concerne les clients qui ne construisent jamais de commande shell à partir d’une chaîne distante, du tout : il cite gemini-cli, Claude Code, github-mcp-server et mcp-gateway de Docker comme transmettant l’URL sous forme de vecteur d’arguments, ce qui fait que la question de savoir ce que contient la chaîne cesse d’être déterminante.

Ce qui est établi, et ce qui ne l’est pas

Le dossier est classé avec une confiance de niveau A par l’archive, et le reportage qui le sous-tend tient la route. Infosecurity Magazine a publié le 20 octobre son propre entretien avec Eilon Cohen, de Pillar ; The Hacker News a publié son propre récit le 22 octobre ; DKCERT, le CERT national du Danemark, a résumé la découverte le 21 octobre en citant Infosecurity ; et le laboratoire de recherche de la Cloud Security Alliance a publié une analyse qui ajoute la seule réserve substantielle ci-dessous. Aucun d’entre eux n’est à l’origine de l’information, et ils s’accordent sur le mécanisme, les versions et le correctif silencieux. Anomaly n’a lui-même rien publié sur la faille.

Établi, officiellement :

• Le défaut, son mécanisme et sa portée sur les plateformes. Pillar identifie des lignes source précises et le correctif est visible dans le diff public entre les versions 1.18.32 et 1.18.33 ; les deux articles de presse indépendants décrivent le même flux de données.

La plage concernée, de 1.0.137 à 1.18.32, et la version corrigée, 1.18.33, publiée le 28 septembre 2026.

• Qu’il n’existe ni CVE ni avis. C’est vérifiable, et c’est le fait déterminant pour les défenseurs.

• Qu'aucune exploitation n'a été signalée. Pillar indique n'avoir constaté aucun signe d'utilisation dans des attaques, et The Hacker News note qu'aucun indicateur de compromission n'a été publié. L'absence d'indicateurs publiés ne prouve pas l'absence, et sans télémétrie du fournisseur, aucune des deux interprétations ne peut être confirmée.

Non établi, ou en tension :

• Le 9.8. Ce nombre est le score CVSS v3.1 proposé par Pillar, et non un score officiel : sans CVE, il n’y a ni score NVD ni score de fournisseur. La note de recherche de la Cloud Security Alliance souligne que 9.8 suppose l’absence d’interaction utilisateur et que, si le compte rendu de The Hacker News concernant le déclencheur est exact, une note nécessitant une interaction utilisateur — environ 8.8 — conviendrait mieux. Cet article ne tranche pas la question ; l’étiquette de haute gravité propre à l’archive est une classification, pas un score.

• La date de publication. Le rapport de Pillar est daté du 19 octobre 2026 dans son en-tête, et les deux articles de presse utilisent cette date ; la chronologie des divulgations au bas du rapport de Pillar indique une publication le 4 octobre. Les archives enregistrent le 19 octobre à la précision du jour.

• La taille de la population exposée. Aucun décompte n’a été publié. Les chiffres de téléchargements et d’étoiles ci-dessus sont des métriques de dépôt, et non des installations.

• Si une machine a réellement été compromise. Rien de ce qui a été publié ne vient l'étayer, et le dossier ne fait état d'aucun préjudice réel.

Qu’est-ce qui a changé, et que faire ?

La remédiation consiste en une vérification de version, car rien d'autre ne vous le dira. OpenCode 1.18.33 ou une version ultérieure est corrigé. Les installations affectées doivent être identifiées en inventorant directement le paquet : la recommandation de Pillar est d'inventorier OpenCode lui-même plutôt que d'attendre un flux, et la note de la Cloud Security Alliance suggère d'interroger la version du paquet opencode-ai, car il n'existe aucun identifiant auquel un flux puisse correspondre. Les équipes qui ne peuvent pas effectuer la mise à niveau et qui utilisent Windows ou le sous-système Windows pour Linux doivent supprimer de leur configuration OpenCode les serveurs MCP distants qu'elles n'ont pas vérifiés ; opencode mcp list indique quels serveurs sont présents.

Pour quiconque maintient un client MCP, les recommandations de Pillar sont plus restrictives que les conseils habituels : transmettez les URL sous forme de vecteur d'arguments et ne construisez jamais une ligne de commande à partir d'une chaîne distante, liez la découverte OAuth à l'origine du serveur configuré par l'utilisateur, et traitez les documents de découverte, les métadonnées de serveur et les descripteurs d'outils comme des entrées non fiables plutôt que comme des paramètres de configuration. La note de la Cloud Security Alliance ajoute des heuristiques de chasse — un processus OpenCode lançant powershell.exe avec -EncodedCommand, par exemple — tout en soulignant qu'il s'agit de suggestions pour l'ingénierie de détection, et non d'indicateurs de compromission publiés.

Pas la faille de la Console

La divulgation de Pillar est intervenue quelques jours après qu'Anomaly a confirmé une violation distincte du Console hébergé d'OpenCode, qui aurait pu exposer des clés de fournisseur d'API stockées. Les deux événements ne sont pas liés, et Eilon Cohen, de Pillar, a été explicite quant à la différence lors de son entretien avec Infosecurity Magazine. « La violation a touché un système hérité situé derrière un proxy de clés hébergé, et a exposé les clés de fournisseur que les utilisateurs y avaient stockées », a-t-il déclaré. « La vulnérabilité que nous avons signalée va dans l'autre sens : un serveur MCP distant malveillant qui exécute du code sur la machine d'un développeur lors de la poignée de main OAuth. Cible et position de l'attaquant différentes. » La violation du Console constitue une entrée distincte dans l'archive, et les deux doivent être lues comme des entrées séparées.

Ce qui les relie, dans la formulation de Cohen, c'est la question qui sous-tend les deux : « À qui vous laissez confier des identifiants et des données d’entrée pour un outil de codage IA, et ce que cet outil en fait. »

Le déficit de divulgation est ce qui survit à la faille. Une faille que ses découvreurs jugent critique, corrigée à l’occasion d’une mise à jour de dépendance et absente de tous les signaux automatisés sur lesquels un défenseur s’appuie habituellement, laisse l’inventaire direct comme seule méthode de détection — et le fournisseur n’a publié aucun avis invitant quiconque à en réaliser un.