système : OPÉRATIONNEL
← retour à tous les hacks
AGENTS CRITICAL NEW

CVE-2026-26268 : l'agent de Cursor transforme un git checkout en exécution de code

Un dépôt malveillant cache un dépôt Git « bare » doté d'un hook automatique. Quand l'agent IA de Cursor lance git checkout pour « expliquer le code », le hook se déclenche — exécution de code arbitraire sur la machine du développeur, sans confirmation. Corrigé dans Cursor 2.5.

2026-06-19 // 6 min affects: cursor, ai-coding-agents

De quoi s’agit-il ?

CVE-2026-26268 est une faille d’exécution de code arbitraire de gravité élevée dans l’IDE assisté par IA Cursor, touchant toutes les versions antérieures à la 2.5. Cursor a publié l’avis (GHSA-8pcm-8jpx-hv8r) en février 2026, et le chercheur Assaf Levkovich (Novee Security) en a détaillé publiquement le mécanisme le 28 avril 2026 (relayé par The Hacker News le 30 avril). La faille porte un score CVSS de 8,1 ; l’éditeur la qualifie d’évasion de sandbox via la configuration .git. La divulgation a été coordonnée avec Cursor et le correctif a été livré avant publication.

Le bug ne réside pas dans la logique du modèle de Cursor. C’est une interaction de fonctionnalités de Git qui devient exploitable dès qu’un agent IA exécute des commandes Git de façon autonome dans un dépôt qu’il ne contrôle pas. Résultat : le code de l’attaquant s’exécute directement sur le poste du développeur, sans dialogue de confirmation.

Comment ça marche

Deux fonctionnalités légitimes de Git se combinent pour créer la condition :

  • Les hooks Git sont des scripts exécutés automatiquement sur des événements comme post-checkout ou pre-commit. Ils vivent dans le répertoire .git d’un dépôt, qui ne fait pas partie de l’arborescence suivie et relue.
  • Les dépôts « bare » ne contiennent que les données .git, sans répertoire de travail. On peut en imbriquer un à l’intérieur d’un dépôt ordinaire.

Un attaquant publie un dépôt public d’apparence normale qui dissimule un dépôt bare porteur d’un hook malveillant. Le déclencheur, c’est l’autonomie de l’agent. Selon la séquence divulguée :

  1. Un développeur clone le dépôt public et l’ouvre dans Cursor.
  2. Il pose une question anodine — « explique-moi le code ».
  3. L’agent de Cursor lit le fichier AGENTS.md / les Cursor Rules du dépôt, qui lui ordonnent de se déplacer dans le dépôt bare imbriqué et de lancer un git checkout.
  4. Le checkout déclenche le hook planté → exécution de code.

Aucun payload n’est reproduit ici, et aucun n’est nécessaire pour saisir la leçon. L’utilisateur a autorisé « explique-moi le code », pas « exécute le script shell d’un attaquant ». Mais l’agent a lancé git checkout pour satisfaire la demande, et le hook s’est exécuté hors de la chaîne de raisonnement de l’agent et hors du champ de vision de l’utilisateur. L’agent n’a jamais signalé avoir lancé un script : à sa connaissance, il a exécuté une commande Git de routine.

C’est le même schéma structurel que d’autres divulgations sur les agents de code : un fichier d’instructions présent dans du contenu non fiable (injection de chaîne d’approvisionnement via AGENTS.md) oriente l’agent, et une action auto-approuvée ou invisible transforme cette orientation en exécution — voir le faux dialogue d’approbation de SymJack et le contournement d’allowlist de Cursor.

Pourquoi c’est important

Une machine de développeur est une cible équivalente à la production. Elle contient du code source, des clés SSH, des identifiants cloud et des jetons de signature, et elle se trouve à l’intérieur du réseau de l’entreprise. Une exécution de code arbitraire à cet endroit est souvent la première étape d’une compromission plus large ou d’un pivot de chaîne d’approvisionnement.

Ce qui rend cette catégorie nouvellement dangereuse, c’est l’effondrement de la contrainte d’action requise. Les attaques « côté client » classiques contre les développeurs exigeaient une erreur délibérée : ouvrir un fichier malveillant, lancer un script, cliquer sur un lien. Ce besoin d’action humaine constituait en soi un frein à l’exploitabilité. Un agent autonome supprime ce frein. Cloner un dépôt public et poser une question suffit désormais à atteindre l’exécution de code — et les workflows assistés par IA automatisent précisément cette boucle à grande échelle.

Cela élargit aussi la surface d’audit. Quand une équipe de sécurité examine un outil de code IA, le code de l’outil n’est qu’une partie du tableau. Le contenu sur lequel l’agent opère — dépôts, AGENTS.md, Cursor Rules, hooks dans une arborescence clonée — fait désormais partie de la surface d’attaque, et l’environnement d’exécution que l’agent pilote (ici Git) est directement pertinent pour la sécurité de l’outil.

Défenses

Cursor possède le correctif spécifique ; les défenseurs possèdent le rayon d’impact environnant et la prochaine variante du schéma.

  • Mettez Cursor à jour en 2.5 ou ultérieure. C’est la remédiation éditeur pour CVE-2026-26268. Suivez les avis sur les agents de code à votre cadence de patch habituelle.
  • Désactivez ou isolez les hooks Git pour les dépôts non fiables. Pointez core.hooksPath vers un répertoire vide et contrôlé quand vous clonez du code hors de votre périmètre de confiance, et inspectez tout répertoire .git imbriqué avant de laisser un agent opérer. git clone --no-checkout suivi d’une relecture manuelle évite de déclencher les hooks au checkout.
  • Traitez les fichiers d’instructions de l’agent comme des entrées non fiables. AGENTS.md, Cursor Rules, directives de README et équivalents dans un dépôt cloné sont contrôlables par l’attaquant. Ne les laissez pas autoriser silencieusement la navigation dans le système de fichiers ou des opérations Git sur des chemins que vous n’avez pas choisis.
  • Exécutez les agents de code dans un sandbox. Conteneurs, VM ou utilisateurs restreints limitent ce qu’un hook déclenché peut atteindre — identifiants, réseau et reste du système de fichiers. Gardez les secrets hors de l’environnement où l’agent s’exécute.
  • Rendez les actions autonomes visibles et relisables. Préférez les configurations qui exposent les commandes concrètes exécutées par l’agent (en particulier les opérations Git et shell) à l’auto-approbation. La supervision « human-on-the-loop » de ce qui a tourné est le contrôle dont l’absence a été exploitée par cette CVE.
  • Ouvrez d’abord les dépôts non fiables dans un environnement jetable. Clonez, relisez, puis seulement ensuite amenez le code dans l’environnement où votre agent dispose de vrais privilèges.

Statut

ÉlémentDétail
CVECVE-2026-26268
ComposantCursor IDE (interaction agent IA + Git)
ClasseÉvasion de sandbox via config .git → exécution de code arbitraire
CVSS8,1 (élevé)
AffectéCursor < 2.5
Corrigé dansCursor 2.5
Avis éditeurFévr. 2026 (GHSA-8pcm-8jpx-hv8r)
Divulgation publique28 avr. 2026 (Novee Security)
DivulgationCoordonnée ; corrigée avant publication

Le bon cadrage n’est pas « un bug de Cursor ». C’est que l’autonomie convertit des fonctionnalités d’environnement anodines et connues de longue date en chemins d’attaque en un clic. Les hooks Git et les dépôts bare se comportent ainsi depuis des années ; ce qui a changé, c’est un agent prêt à lancer git checkout sur un dépôt non fiable sans surveillance humaine. Tout outil de code IA qui pilote de façon autonome un environnement local puissant hérite de la même forme, et la défense durable consiste à considérer comme hostile le contenu que l’agent manipule et à garder un humain capable de voir ce que l’agent a réellement exécuté.

Sources