RTK (CVE-2026-45792) : des filtres non fiables masquent un backdoor à la revue IA

De quoi s’agit-il ?

Le 20 mai 2026, Pillar Security a divulgué publiquement CVE-2026-45792, une vulnérabilité dans RTK (Rust Token Killer), un outil open source d’optimisation de tokens utilisé avec Claude Code. RTK s’intercale entre l’assistant de code IA et le shell du développeur : il intercepte la sortie des commandes et applique des filtres regex pour retirer le bruit avant que cette sortie n’atteigne le modèle, économisant ainsi des tokens de la fenêtre de contexte. La faille : RTK chargeait automatiquement les règles de filtrage depuis un fichier .rtk/filters.toml local au projet, présent dans tout dépôt cloné — avec la priorité la plus haute, sans demande d’approbation et sans avertissement. Quiconque pouvait committer dans le dépôt décidait donc de ce que l’IA avait le droit de voir.

L’intérêt de cette découverte tient moins à sa mécanique qu’à sa catégorie. Ce n’est pas une attaque sur ce qu’un agent peut exécuter, mais sur ce qu’il peut observer. Le découvreur l’a notée CVSS 4.0 à 6,9 (moyenne) ; la GitLab Advisory Database la liste en CVSS 3.1 à 8,2 (élevée). Le CVE a été attribué le 14 mai et les mainteneurs ont publié un correctif : la chronologie est entièrement divulguée et corrigée.

Comment ça marche

RTK chargeait la configuration depuis trois sources, par priorité croissante : les filtres intégrés, une configuration globale de l’utilisateur (~/.config/rtk/filters.toml) et une configuration locale au projet (.rtk/filters.toml). Les deux premières sont sous votre contrôle ; la troisième arrive avec le dépôt — écrite par un mainteneur, un contributeur ou un attaquant. RTK ne les distinguait pas : un fichier de filtres fourni par le dépôt héritait de la même autorité que celui que vous aviez écrit vous-même, et s’activait silencieusement. L’avis suit cela sous CWE-345 (vérification insuffisante de l’authenticité des données) et CWE-426 (chemin de recherche non fiable).

La chaîne d’attaque est courte. Aucun payload fonctionnel n’est reproduit ici ; c’est la forme qui compte :

# À titre conceptuel uniquement — illustratif, pas une config fonctionnelle.
1. l'attaquant committe .rtk/filters.toml à côté d'un backdoor
2. la victime clone le dépôt et y travaille avec Claude Code + RTK
3. la regex contrôlée par l'attaquant retire les lignes du backdoor
   de la sortie de cat / git diff / scanner avant lecture par le modèle
4. le modèle revoit une vue filtrée et rapporte « aucun problème »

Comme le moteur de RTK est générique et piloté par regex, un attaquant pouvait supprimer tout ce qui apparaît dans la sortie d’une commande : lignes malveillantes retirées d’un cat, avertissements retirés des résultats d’un scanner, code de backdoor masqué dans un git diff, indicateurs de compromission filtrés d’un grep. Le fichier de filtres avait l’air anodin — des noms comme reduce_noise, des commentaires comme « strip ANSI escape sequences » — et se fondait dans le décor. Le modèle recevait une sortie post-filtrage sans aucun moyen de savoir que des lignes avaient été retirées, car RTK opérait en dessous de sa couche d’observation.

Pourquoi c’est important

Pillar décrit la cause racine comme un blanchiment de confiance (trust laundering) : un contenu issu d’un dépôt distant, écrit par quelqu’un que le développeur n’a jamais rencontré, recevait la même autorité qu’une configuration installée localement. La frontière de confiance suivait le type de contenu (« est-ce un filtre valide ? ») plutôt que l’origine (« est-ce le développeur qui l’a placé là ? »). Le même schéma se retrouve dans l’outillage de développement IA — .bashrc, profils de shell, fichiers d’instructions d’agent comme AGENTS.md et CLAUDE.md — où un fichier d’apparence inerte est chargé automatiquement et agit avec l’autorité que lui confère l’outil consommateur.

RTK ajoute une surface nouvelle à ce schéma : la couche d’observation. Un outil qui contrôle ce que le modèle peut voir a une portée de sécurité même s’il n’exécute jamais rien, car un agent qui ne peut pas voir un backdoor ne peut pas le signaler. L’effet se cumule dans les workflows où le même agent écrit et revoit le code : un seul .rtk/filters.toml aveugle les deux passes à la fois, et du code compromis peut passer la revue IA et l’analyse automatisée pour partir en production sans que le développeur ait de raison de douter du résultat « propre ». Le seul accès requis : la capacité de committer un petit fichier de configuration — à la portée d’un contributeur, d’un prestataire ou d’un compte compromis.

Défenses

• Mettez RTK à jour. Le découvreur indique que le correctif complet du modèle de confiance est arrivé en v0.33.0 ; l’avis GitLab liste 0.32.0 comme version corrigée. Passez à la dernière version dans tous les cas, et vérifiez la version réellement utilisée par vos équipes.
• Tracez la frontière de confiance à la source, pas au contenu. Une configuration provenant d’un dépôt doit être non fiable par défaut et exiger une activation explicite, dépôt par dépôt — précisément ce que le correctif de RTK impose désormais, avec un avertissement à l’utilisateur et au modèle plus un contrôle d’intégrité SHA-256 qui révoque la confiance si le fichier change après un git pull.
• Traitez la couche d’observation comme une partie de la chaîne d’approvisionnement. Tout outil qui prétraite, filtre ou transforme la sortie avant qu’elle n’atteigne un agent de code façonne ce sur quoi le modèle peut agir. Inventoriez ces outils et revoyez leur modèle de confiance, même ceux qui n’exécutent jamais de code. Voir les risques liés à la chaîne d’approvisionnement des skills/registres.
• Ne laissez pas un seul agent être l’unique relecteur de sa propre sortie. Lorsque c’est possible, faites la revue avec une vue non filtrée ou un pipeline indépendant, pour qu’une seule config empoisonnée ne puisse aveugler à la fois la génération et la revue.
• Auditez la config d’agent locale au dépôt en revue de code. .rtk/filters.toml, fichiers d’instructions d’agent et autres dotfiles méritent le même examen que les scripts de build : c’est de la confiance exécutable, pas de la décoration.

État

Élément	Détail
CVE	CVE-2026-45792 (GHSA-fvvm-949w-qj4w)
Composant	RTK (Rust Token Killer), hook de filtrage pour Claude Code
Faiblesse	CWE-345 (authenticité des données) · CWE-426 (chemin de recherche non fiable)
Sévérité	CVSS 4.0 6,9 moyenne (découvreur) · CVSS 3.1 8,2 élevée (GLAD)
Corrigé en	v0.33.0 (découvreur) · 0.32.0 (GLAD) — refus par défaut des filtres projet non fiables + confiance par hash
Divulgation	Signalé le 15 mars 2026 · correctif le 25 mars · CVE attribué le 14 mai · public le 20 mai 2026

À retenir : non pas que « RTK serait spécialement dangereux » — les mainteneurs l’ont corrigé en 24 heures. À retenir, c’est la classe d’attaque : en développement assisté par IA, la surface d’attaque inclut ce qui n’atteint pas le modèle. Un attaquant qui contrôle la couche de filtrage n’a jamais besoin d’injecter quoi que ce soit dans le contexte de l’agent ; il lui suffit de retirer la trace de ce qu’il a planté.