Contournement d'allowlist dans Cursor : les built-ins du shell empoisonnent l'environnement

De quoi s’agit-il ?

CVE-2026-22708 est un contournement d’allowlist dans l’éditeur de code Cursor, divulgué par le chercheur de Pillar Security Dan Lisichkin dans The Agent Security Paradox (publié le 14 janvier 2026 ; signalé à Cursor le 11 août 2025). Le NVD enregistre deux scores : CVSS 3.1 9.8 (Critique) et CVSS 4.0 7.2 (Élevé). La faille est corrigée dans Cursor 2.3.

La technique est simple : lorsque l’agent Cursor fonctionne en mode Auto-Run avec une allowlist, une poignée de built-ins shell — export, unset, set, typeset, declare — s’exécutent sans jamais figurer dans l’allowlist ni déclencher de demande d’approbation. Un attaquant qui contrôle les instructions de l’agent (directement, ou indirectement via un fichier ou une page web malveillants que l’agent lit) emploie ces built-ins pour empoisonner discrètement les variables d’environnement, puis attend qu’une commande de confiance s’exécute. Le sujet est revenu sur le devant de la scène le 11 juin 2026, lorsque le rapport State of Agentic AI Security de l’OWASP l’a cité parmi les CVE d’injection de prompt désormais observées contre des outils de codage en production.

Comment ça fonctionne

L’allowlist de Cursor valide les binaires externes avant leur exécution. Les built-ins shell ne sont pas des binaires distincts — ils s’exécutent au sein même de la session shell — et échappent donc entièrement à l’évaluateur de commandes côté serveur. C’est toute la faille : l’allowlist vérifie ce qui est exécuté, jamais le contexte d’environnement dans lequel cela tourne.

Dès qu’un attaquant peut définir gratuitement des variables d’environnement, il vise celles qui modifient le comportement des outils ordinaires. Une chaîne courante détourne le pager qu’invoquent git et man :

# S'exécute silencieusement — un built-in, jamais soumis à approbation :
export PAGER="[CAVIARDÉ : commande]"

# Paraît anodin, souvent déjà dans l'allowlist — déclenche la charge :
git branch

L’utilisateur approuve git branch, le croyant inoffensif ; le PAGER empoisonné exécute le code de l’attaquant au lieu d’afficher la sortie. Pillar a aussi démontré une variante entièrement « zero-click » utilisant typeset et les drapeaux d’expansion de paramètres zsh pour forcer l’évaluation d’une chaîne intégrée sans aucune approbation, ainsi qu’une chaîne plus longue via PYTHONWARNINGS → BROWSER → PERL5OPT qui obtient l’exécution de code dès qu’un script Python est lancé. Les charges réelles sont omises ici ; c’est le mécanisme, pas la chaîne d’exploitation, qui compte.

La leçon de fond que tire Pillar est un changement de modèle de confiance. Manipuler des variables d’environnement pour obtenir une RCE est ancien (Elttam l’avait documenté en 2020), mais cela exigeait auparavant un accès local et une préparation manuelle en plusieurs étapes. Un agent qui suit les instructions d’un contenu non fiable réduit toutes ces conditions préalables à une seule injection de prompt, exécutée à distance avec les privilèges du développeur.

Pourquoi c’est important

Les assistants de codage IA figurent désormais parmi les produits les plus ciblés par l’injection de prompt, car une injection réussie s’exécute sur la machine d’un développeur avec accès au code source, aux clés SSH, aux identifiants cloud et au réseau local. CVE-2026-22708 montre que la demande d’approbation avec humain dans la boucle — le contrôle sur lequel reposent la plupart des équipes — peut être amenée à mentir : la commande visible et approuvée est anodine, tandis que la préparation malveillante a eu lieu de manière invisible via des built-ins jamais affichés. Tout IDE agentique qui contrôle les commandes mais pas le contexte d’exécution partage cette classe de faiblesse, et pas seulement Cursor.

Défenses

Mettez Cursor à jour en 2.3 ou ultérieur, où l’analyseur côté serveur exige désormais une approbation explicite pour toute commande qu’il ne peut pas classifier. Au-delà du correctif :

• Ne considérez pas l’allowlist comme une frontière de sécurité. La documentation de Cursor elle-même indique que l’allowlist est au mieux indicative et que des contournements sont possibles ; n’activez jamais un mode « Run Everything ». Gardez les allowlists courtes et évitez d’auto-approuver des outils larges comme git, python ou npm.
• Traitez les built-ins shell comme sensibles pour la sécurité. Les modifications de variables d’environnement (export, typeset, declare, unset) méritent la même vigilance que l’exécution de commandes, pas un blanc-seing implicite.
• Préférez l’isolation à l’assainissement. Faites tourner l’agent dans un bac à sable ou un conteneur jetable où l’exécution de code et les changements de variables ne peuvent atteindre ni l’hôte réel, ni les clés SSH, ni les identifiants. Pillar soutient — et l’attaque le confirme — que l’isolation d’exécution, et non les allowlists, est le contrôle durable pour les agents qui ont légitimement besoin d’exécuter du code.
• Réinitialisez l’environnement entre les sessions d’agent pour qu’une variable empoisonnée ne persiste pas vers une action ultérieure de confiance.
• Limitez ce que l’agent lit. L’injection indirecte arrive via les fichiers de dépôt, les documents et les pages web ; restreindre et relire les entrées non fiables réduit la surface de déclenchement.

Statut

Élément	Détail
Identifiant	CVE-2026-22708
Affecté	Cursor antérieur à 2.3 (Auto-Run + allowlist)
Corrigé dans	Cursor 2.3
CVSS (NVD)	9.8 Critique (v3.1) / 7.2 Élevé (v4.0)
Signalé	11 août 2025
Divulgation publique	14 janvier 2026 (Pillar Security)
Prérequis d’exploitation	Injection de prompt (directe ou indirecte) dans l’agent