Faille VS Code - CVE-2026-81376 - un dépôt piégé peut contourner Workspace Trust

La faille VS Code CVE-2026-81376 remet en cause une protection centrale de Visual Studio Code: Workspace Trust. Un dépôt ou un espace de travail spécialement construit peut contourner le mode restreint, se connecter à un service contrôlé par un attaquant et conduire à un accès aux données locales ou à une exécution de code.

Microsoft classe CVE-2026-81376 au niveau critique avec un score CVSS 3.1 de 9,6 sur 10. L’utilisateur doit ouvrir le dépôt piégé, mais il n’a pas besoin de lui accorder explicitement sa confiance pour que le scénario décrit devienne possible.

Toutes les versions de Visual Studio Code antérieures à 1.136.2 sont indiquées comme affectées. La priorité est donc simple: vérifier la version réellement utilisée et installer VS Code 1.136.2 ou une version ultérieure.

Cette mise à jour corrige également plusieurs failles connexes touchant les agents, la navigation web intégrée et les paramètres fournis par les dépôts. Elles montrent qu’un projet Git n’est plus seulement un ensemble de fichiers à compiler: il peut aussi piloter une partie du comportement de l’environnement de développement.

Workspace Trust devait permettre d’ouvrir un dépôt sans l’exécuter

Visual Studio Code distingue normalement un dossier approuvé d’un projet encore inconnu. Lorsqu’un nouveau dépôt est ouvert en Restricted Mode, Workspace Trust limite les fonctions susceptibles d’exécuter du code automatiquement.

Le mode restreint peut notamment encadrer ou désactiver:

• les tâches définies dans le projet;
• les sessions de débogage;
• le terminal intégré;
• certains paramètres contenus dans .vscode/settings.json;
• les extensions qui ne prennent pas correctement en charge les espaces non approuvés;
• les agents IA associés à l’espace de travail.

L’objectif n’est pas de prouver qu’un dépôt est sain. Il consiste à offrir une phase de consultation pendant laquelle son contenu peut être examiné sans activer immédiatement toutes les fonctions capables d’agir sur le poste.

CVE-2026-81376 est critique précisément parce qu’elle traverse cette frontière. Selon l’avis Microsoft, un espace de travail préparé par un attaquant peut amener VS Code à contacter un service sous son contrôle pendant que le projet est encore en mode restreint. Une exploitation réussie peut permettre d’accéder à des données locales ou d’exécuter du code avec les droits de l’utilisateur.

Ouvrir le dépôt suffit, sans cliquer sur « Faire confiance »

Le scénario nécessite une interaction: l’attaquant doit convaincre sa cible d’ouvrir un dépôt ou un fichier d’espace de travail spécialement construit.

Cette condition reste importante. La vulnérabilité n’est pas décrite comme une compromission automatique de toutes les installations VS Code accessibles sur un réseau. Un utilisateur doit récupérer le projet puis l’ouvrir dans une version vulnérable.

En revanche, refuser d’accorder sa confiance au projet ne suffit pas à bloquer l’exploitation. Microsoft précise que l’utilisateur n’a pas besoin de valider le dépôt pour être exposé. Le mécanisme censé permettre son inspection prudente est justement celui qui peut être contourné.

Les sources possibles d’un dépôt hostile sont nombreuses:

• une contribution reçue depuis un fork externe;
• un projet présenté comme une démonstration ou un outil gratuit;
• une archive jointe à un ticket de support;
• un dépôt repris après la compromission de son mainteneur;
• une dépendance ou un exemple de code demandé par un assistant IA;
• un projet cloné pour analyser un comportement suspect.

Le risque concerne donc les développeurs, mais aussi les administrateurs, équipes DevOps, analystes sécurité et techniciens qui ouvrent régulièrement du code provenant de tiers.

Une seconde faille permettait de configurer un agent distant

La mise à jour 1.136.2 corrige en parallèle CVE-2026-78462, une vulnérabilité élevée notée 8,8 sur 10.

Dans ce scénario, un dépôt non fiable pouvait fournir dans .vscode/settings.json l’adresse d’un hôte d’agent distant contrôlé par l’attaquant. La configuration pouvait également contenir des autorisations donnant à cet agent l’accès à des fichiers locaux.

Après l’ouverture du dépôt, VS Code pouvait alors se connecter au service distant. L’exploitation pouvait conduire à la lecture de données locales ou à l’exécution de code dans le contexte de l’utilisateur, là encore sans qu’il soit nécessaire d’approuver l’espace de travail.

Le correctif déplace ces paramètres sensibles vers la configuration globale de l’utilisateur et les marque comme restreints. Un projet ne doit plus pouvoir décider seul à quel agent distant l’éditeur se connecte ni lui transmettre des autorisations sur le poste.

Cette faille illustre un changement de périmètre. Un fichier de configuration versionné peut désormais influencer des composants qui disposent de capacités bien supérieures à la coloration syntaxique: accès au réseau, lecture de fichiers, appels d’outils et exécution de commandes.

Les outils agentiques élargissent la surface d’attaque

Trois autres vulnérabilités élevées corrigées dans VS Code 1.136.2 concernent le filtre réseau des agents:

• CVE-2026-81378: des barres obliques inversées ou des séparateurs mélangés pouvaient être interprétés différemment par le filtre et le navigateur intégré;
• CVE-2026-81379: d’autres divergences d’analyse d’URL pouvaient permettre de joindre un hôte local, privé ou normalement interdit;
• CVE-2026-81357: une adresse IPv4 exprimée sous une forme IPv6 équivalente pouvait échapper à certaines listes de refus.

Dans les scénarios publiés, l’attaquant doit pouvoir influencer l’URL consultée par l’agent. Cela peut venir d’une instruction directe, mais aussi d’une injection indirecte de prompt présente dans une page, un document ou un contenu que l’agent traite.

Le risque ne signifie pas que toute utilisation d’un agent dans VS Code entraîne une compromission. Les fonctions concernées doivent être actives et les politiques réseau doivent correspondre aux configurations vulnérables. Il montre en revanche qu’une liste de domaines refusés n’est pas, à elle seule, une isolation réseau.

Pour un poste ayant accès à des consoles d’administration, des environnements cloud, des dépôts privés ou des secrets de développement, une requête vers une destination inattendue peut avoir des conséquences importantes.

Une configuration de dépôt pouvait aussi exposer un jeton Azure DevOps

La mise à jour corrige enfin CVE-2026-81381, classée modérée avec un score de 6,5.

L’intégration de recherche Azure DevOps utilisée par GitHub Copilot Chat acceptait une surcharge de son adresse de destination depuis la configuration de l’espace de travail. Un dépôt malveillant pouvait ainsi rediriger une requête authentifiée vers un serveur contrôlé par l’attaquant et recevoir le jeton d’accès associé.

Ce scénario n’affecte que les utilisateurs de l’intégration concernée. Il reste néanmoins révélateur: une valeur apparemment technique dans .vscode/settings.json pouvait modifier la destination d’une requête portant un secret d’authentification.

Microsoft n’indique pas de solution de contournement pour cette CVE. La mise à jour vers VS Code 1.136.2 ou une version ultérieure est nécessaire.

Comment vérifier sa version de VS Code

La version peut être consultée depuis le menu Aide, puis À propos. Depuis un terminal, lorsque la commande code est disponible:

code --version

La première ligne doit indiquer 1.136.2 ou une version ultérieure.

Il faut vérifier chaque poste et chaque canal réellement utilisé. Une version stable corrigée ne met pas automatiquement à niveau une installation portable, un poste hors ligne, une image de développement persistante ou un environnement distant conservé depuis plusieurs semaines.

Après la mise à jour, fermez toutes les fenêtres de l’éditeur puis relancez-le afin de confirmer que le processus actif utilise bien la nouvelle version.

Les actions à engager maintenant

Une réponse proportionnée peut suivre cet ordre:

1. Mettre à jour vers VS Code 1.136.2 ou une version ultérieure
   Le correctif couvre la faille critique et les vulnérabilités connexes publiées le même jour.

2. Inventorier les installations moins visibles
   Inclure les postes secondaires, machines virtuelles, environnements de formation, versions portables et images de postes administratifs.

3. Conserver Workspace Trust actif
   Le contournement connu est corrigé, mais la frontière reste utile contre d’autres mécanismes d’exécution fournis par un projet.

4. Revoir les dossiers déclarés comme fiables
   Faire confiance à un répertoire parent revient à approuver tous ses sous-dossiers. Un dossier général contenant aussi les dépôts téléchargés ne doit pas être marqué globalement comme fiable.

5. Contrôler les fonctions agentiques
   Vérifier les outils de navigation, les accès au réseau, les serveurs MCP et les autorisations de lecture ou d’exécution accordées aux agents.

6. Examiner les dépôts récemment ouverts
   Rechercher les configurations inhabituelles, les adresses distantes, les modifications de politiques et les recommandations d’extensions inattendues.

7. Révoquer les secrets en cas de doute sérieux
   Si un dépôt suspect a été ouvert avec une version vulnérable, la rotation des jetons accessibles depuis le poste peut être nécessaire après analyse.

À la date de publication de cet article, les avis officiels consultés ne signalent pas d’exploitation active ni d’indicateur de compromission propre à ces vulnérabilités.

Inspecter un dépôt inconnu avant de l’ouvrir

La mise à jour reste indispensable. Elle peut être complétée par une méthode de travail simple pour les projets externes.

Avant d’ouvrir un dépôt inconnu dans l’éditeur, examinez au minimum:

• .vscode/settings.json;
• les fichiers .code-workspace;
• .vscode/tasks.json et .vscode/launch.json;
• .devcontainer/devcontainer.json;
• les recommandations d’extensions;
• les scripts d’installation et de démarrage;
• les workflows d’intégration continue;
• les sous-modules et fichiers générés inhabituels.

La commande suivante permet d’identifier rapidement certains fichiers sensibles sans démarrer l’application:

find . -maxdepth 3 -type f \( -path '*/.vscode/*' -o -name '*.code-workspace' -o -path '*/.devcontainer/*' -o -path '*/.github/workflows/*' \) -print

Cette inspection ne remplace ni l’analyse du code ni l’isolation. Un dépôt réellement douteux doit être étudié dans un environnement jetable, sans secrets, sans montage du dossier personnel et sans accès aux réseaux d’administration.

Il faut également éviter de lancer immédiatement npm install, un script de préparation, une tâche de build ou une configuration de développement fournie par le projet. Chacune de ces actions peut exécuter du code indépendamment de la faille VS Code.

Le dépôt Git doit être traité comme une entrée non fiable

Les équipes encadrent généralement les pièces jointes, les images importées et les documents reçus de l’extérieur. Les dépôts de code bénéficient parfois d’une confiance plus large parce qu’ils sont destinés à être lus.

Pourtant, un projet moderne transporte bien plus que son code source:

• des commandes de build;
• des tâches d’administration;
• des conteneurs de développement;
• des paramètres d’éditeur;
• des extensions recommandées;
• des connexions à des outils distants;
• des instructions destinées aux assistants IA;
• des workflows capables de manipuler des secrets.

Le dépôt est donc à la fois un document, une configuration et, potentiellement, un programme. Sa provenance, ses changements et les droits du poste qui l’ouvre doivent être pris en compte.

Cette vigilance devient encore plus importante avec les assistants de développement. Nous détaillons leurs conditions d’usage dans notre guide de démarrage pour Claude Code et ChatGPT Codex: accélérer le travail ne doit pas conduire à abandonner la revue, l’isolation et la maîtrise des données.

Conclusion

La faille VS Code CVE-2026-81376 permet à un espace de travail spécialement préparé de contourner Workspace Trust. L’utilisateur doit ouvrir le projet, mais il n’a pas besoin de cliquer sur « Faire confiance ». L’impact annoncé peut atteindre l’accès aux fichiers locaux ou l’exécution de code avec les droits de la session.

La version Visual Studio Code 1.136.2 corrige cette faille critique ainsi qu’un ensemble de vulnérabilités touchant les agents distants, les filtres réseau, les paramètres imbriqués et l’intégration Azure DevOps de GitHub Copilot Chat.

Le bon ordre d’action est clair:

• mettre à jour toutes les installations;
• vérifier la version effectivement lancée;
• conserver Workspace Trust actif;
• revoir les répertoires approuvés et les fonctions agentiques;
• traiter les dépôts externes comme des entrées potentiellement hostiles;
• isoler l’analyse des projets réellement suspects.

La sécurisation des postes techniques fait partie du maintien en condition de sécurité de l’infrastructure. Si vous souhaitez cadrer les accès d’administration, la gestion des secrets ou la politique de mise à jour de vos outils, nous pouvons intervenir dans le cadre de notre offre de renfort technique.

• Découvrir notre offre de renfort technique
• Nous contacter
• Prendre rendez-vous

Sources

• Microsoft - CVE-2026-81376 - contournement critique de Workspace Trust
• Microsoft - CVE-2026-78462 - exécution de code par configuration d’un agent distant
• Microsoft - CVE-2026-81378 - contournement du filtre réseau de l’agent
• Microsoft - CVE-2026-81379 - divergences d’analyse des URL
• Microsoft - CVE-2026-81357 - contournement IPv4 et IPv6
• Microsoft - CVE-2026-81381 - exposition possible d’un jeton Azure DevOps
• Microsoft - notes de version de Visual Studio Code 1.136
• Microsoft - documentation Workspace Trust

FAQ: faille VS Code et CVE-2026-81376

Qu’est-ce que la faille VS Code CVE-2026-81376 ?

CVE-2026-81376 est un contournement critique de Workspace Trust. Un espace de travail spécialement préparé peut atteindre un service contrôlé par un attaquant, accéder à des données locales ou exécuter du code alors que VS Code est encore en mode restreint.

Faut-il accorder sa confiance au dépôt pour être exposé ?

Non. L’utilisateur doit ouvrir le dépôt ou l’espace de travail piégé, mais l’avis de Microsoft précise qu’il n’a pas besoin de lui accorder explicitement sa confiance.

Quelles versions de Visual Studio Code sont vulnérables ?

Microsoft indique que les versions de Visual Studio Code antérieures à 1.136.2 sont affectées. Le correctif est disponible dans VS Code 1.136.2 et les versions ultérieures.

Workspace Trust doit-il rester activé après la mise à jour ?

Oui. La mise à jour corrige le contournement connu, mais Workspace Trust reste une protection importante contre l’exécution automatique de tâches, de commandes, d’extensions ou de réglages provenant d’un dépôt non vérifié.

Les fonctions d’agent IA de VS Code sont-elles également concernées ?

La version 1.136.2 corrige aussi plusieurs contournements des filtres réseau utilisés par les outils agentiques de VS Code. Ils peuvent permettre à une URL manipulée ou à une injection indirecte de joindre une destination que l’administrateur pensait bloquée.