Claude Code 2.1.292 : six failles de sécurité refermées en une seule version

La 2.1.292 de Claude Code, sortie le 6 octobre 2026, compte 92 entrées, dont une bonne part de correctifs ponctuels destinés aux auteurs de plugins et de mods, ou propres à Slack, aux sessions cloud et à Code Review. Mais au milieu de ce lot, six correctifs distincts, dont un étiqueté « Security » dans le changelog lui-même, touchent tous la même chose : un contrôle déjà posé, sur le sandbox, sur un réglage managé ou sur un chemin de fichier, qui ne tenait pas dans un cas précis. Trois touchent le sandbox et les réglages managés, deux concernent la lecture de fichiers déjà approuvés, et le dernier referme un déguisement Windows classique pour rm -rf. Pris ensemble, c'est une concentration notable de correctifs de sécurité pour une seule version.

Le sandbox et les réglages managés : quand le contrôle lui-même peut être trafiqué

Le sandbox Bash limite surtout les écritures et le réseau des commandes shell. Les lectures restent larges par défaut, la doc le dit sans détour : elles couvrent « most of the machine, including credential files such as ~/.ssh and ~/.aws/credentials », sauf si tu listes explicitement un chemin à refuser. Le premier correctif referme un accès que ce défaut n'explique pas : une commande sandboxée pouvait lire les copies mises en scène des fichiers envoyés via /ultrareview, stockées sous ~/.claude/seed-admin. Ces copies portent le contenu que tu uploades pour une revue, pas des fichiers de projet ordinaires, et rien ne justifiait qu'une commande shell sandboxée y ait accès.

Le deuxième touche un cas plus subtil, côté règles de lecture refusée. La même doc précise que Claude Code « merges the deny entries from every settings scope the session loads [...] any scope can add one, but no scope can remove one that another scope added » : une règle deny ne fait que restreindre l'accès, aucune portée de réglages ne peut l'affaiblir. Le changelog corrige un cas où un chemin refusé en lecture, géré par l'organisation ou par toi-même, qui apparaissait ou se faisait repointer après le début de la session, ne retirait pas les autorisations de projet accordées à l'intérieur de ce chemin et ne coupait pas non plus l'injection d'identifiants provenant des fichiers qu'il couvre. Une règle censée se resserrer qui restait, dans ce cas précis, ouverte.

Le troisième protège le gardien lui-même. Sur une machine gérée, Claude Code charge avant tout mod installé par l'utilisateur un plugin de politique intégré, cc-plugin-sec-default, décrit dans la doc sur les mods comme un garde qui « fails closed: if the guard can't read managed settings, it refuses every user's mod at load ». C'est le comportement voulu quand la récupération des réglages managés échoue en direct. Le correctif de la 2.1.292 referme un autre chemin vers le même échec : un cache local de ces réglages, trafiqué sur le disque, pouvait désactiver ou déloger ce garde justement pendant que la récupération en direct échouait. Un cache qu'on peut modifier sur le disque ne devrait jamais pouvoir éteindre le gardien qui est censé tenir bon quand tout le reste a échoué.

Un lien qui change sous le nez du contrôle, et un rm -rf qui ne reconnaît pas sa cible

Les deux correctifs suivants touchent le même principe que la doc sur les permissions pose pour les symlinks : une fois qu'un chemin est approuvé, Claude Code vérifie qu'il mène toujours au même endroit avant de l'ouvrir, et « when a tool then opens the approved file, it confirms that the path still resolves to the location the permission check approved ». Le premier corrige un cas où cette seconde vérification ne suffisait pas : sur macOS et Windows, la lecture d'un notebook ou d'un PDF pouvait renvoyer un fichier hors de ce qui avait été approuvé, via un lien substitué en cours de lecture. Le second touche un chemin différent vers le même genre de problème, sur Windows cette fois : la doc explique pourquoi un chemin réseau (UNC) déclenche normalement une invite, même pour une commande en lecture, « because accessing a network path can send your Windows credentials to the host it names ». La 2.1.292 referme un cas où cette invite ne se déclenchait pas pour une lecture de fichier approuvée par un hook PreToolUse ou par le mode auto, exactement le genre de chemin que la règle visait à couvrir.

Le dernier de la salve touche une commande, pas un chemin de fichier. Sur Windows, un dossier a souvent deux noms : le nom long habituel, et un nom court au format 8.3 (PROGRA~1 pour Program Files, par exemple), conservé pour la compatibilité avec les anciens systèmes de fichiers. Un rm -rf lancé sur ce nom court, ou sur une autre orthographe alternative du dossier personnel ou d'un lecteur, n'était pas reconnu par la protection censée empêcher Claude de supprimer ces répertoires. La commande visait la même cible, sous un nom différent, et la protection ne la reconnaissait pas sous ce déguisement.

Le reste, en vrac

• claude plugin install --marketplace <source> : ajoute la marketplace si besoin, sous les mêmes contrôles de politique qu'un ajout manuel, puis installe le plugin.
• Effort des sous-agents : le tool Agent accepte désormais un paramètre effort, pour faire tourner un sous-agent au niveau de raisonnement demandé plutôt qu'au niveau par défaut.
• MCP local : les connexions aux serveurs MCP locaux (stdio) négocient désormais par défaut une version de protocole plus récente, y compris sur Bedrock, Vertex et Foundry ; MCP_PROTOCOL_NEGOTIATION=legacy permet de revenir en arrière.
• Sous-agents et mode auto : un sous-agent défini avec permissionMode: auto entrait en mode auto même quand ce mode était indisponible (désactivé par les réglages, coupe-circuit déclenché ou modèle incompatible). Autre correctif de permissions : la règle allowed-tools d'un skill ou d'une commande slash revenait au tour suivant quand on quittait le mode auto ou le mode plan en cours de tour.
• Hooks et <system-reminder> : les balises <system-reminder> écrites dans la sortie d'un hook sont désormais échappées avant d'atteindre Claude, pour qu'elles ne puissent plus se faire passer pour une balise système.
• Fichiers illisibles : Grep et Glob répondaient « aucune correspondance » sans erreur quand le chemin donné ne pouvait pas être lu ; Claude retente désormais une fois ou te le signale.
• Fichiers mentionnés avec @ de plus de 256 Ko : étaient exclus en silence, Claude est maintenant informé de leur taille et invité à les lire par portions.
• Mode plan : ne se restaurait pas toujours à la reprise d'une session via claude --resume ou /resume.
• Tâches planifiées : celles créées après /resume, /branch ou /clear ne se déclenchaient jamais ; après deux écritures du fichier de tâches à quelques millisecondes d'intervalle, les tâches enregistrées ignoraient aussi les créations et suppressions suivantes.
• Les sessions cloud, Claude Tag dans Slack, Code Review et VS Code ont aussi leur lot : surtout des correctifs d'affichage et de fiabilité propres à ces surfaces, et une vingtaine d'entrées concernent le développement de plugins et de mods, sans effet pour qui n'en écrit pas.

Ce qu'il faut retenir

Aucun de ces six correctifs n'annonce une faille béante en soi : chacun referme un cas précis, un déguisement de commande, un lien qui change au mauvais moment, un cache qu'on peut trafiquer sur le disque. Mais leur nombre et leur variété dans une seule version comptent plus que chacun pris isolément. Si tu gères des mods ou des réglages managés pour une équipe, retiens le troisième correctif, sur le garde intégré : même un cache local trafiqué ne devrait plus pouvoir l'éteindre. Si tu lis des PDF et des notebooks sur macOS ou Windows, ou si Claude Code tourne sur une machine Windows où les noms courts 8.3 existent encore, ces deux correctifs te concernent directement. Pour le reste, cette version confirme ce que ce digest répète depuis plusieurs semaines : les garde-fous de permissions tiennent dans l'ensemble, et c'est précisément pour ça que chaque angle mort qui leur échappe encore vaut la peine d'être traqué, un par un.