RTK (CVE-2026-45792): filtros no confiables ocultan backdoors a la revisión por IA
Pillar Security divulgó el 20 de mayo de 2026 un fallo en RTK, un filtro de optimización de tokens para Claude Code: un .rtk/filters.toml provisto por el repositorio podía eliminar en silencio un backdoor de la salida de comandos antes de que el modelo la viera. El objetivo es la percepción del agente, no su ejecución.
¿Qué es esto?
El 20 de mayo de 2026, Pillar Security divulgó públicamente CVE-2026-45792, una vulnerabilidad en RTK (Rust Token Killer), una herramienta de código abierto de optimización de tokens usada con Claude Code. RTK se sitúa entre el asistente de programación con IA y la shell del desarrollador: intercepta la salida de los comandos y aplica filtros regex para eliminar el ruido antes de que esa salida llegue al modelo, ahorrando tokens de la ventana de contexto. El fallo: RTK cargaba automáticamente las reglas de filtrado desde un .rtk/filters.toml local del proyecto, presente en cualquier repositorio clonado — con la máxima prioridad, sin pedir aprobación y sin advertencia. Por tanto, cualquiera que pudiera hacer commit en el repositorio decidía qué se le permitía ver a la IA.
El hallazgo destaca menos por su mecánica que por su categoría. No es un ataque sobre lo que un agente puede ejecutar, sino sobre lo que puede observar. El descubridor lo puntuó como CVSS 4.0 en 6,9 (media); la GitLab Advisory Database lo lista como CVSS 3.1 en 8,2 (alta). El CVE se asignó el 14 de mayo y los mantenedores publicaron un parche, de modo que el cronograma está plenamente divulgado y corregido.
Cómo funciona
RTK cargaba la configuración desde tres fuentes, en prioridad ascendente: filtros integrados, una configuración global del usuario (~/.config/rtk/filters.toml) y una configuración local del proyecto (.rtk/filters.toml). Las dos primeras están bajo su control; la tercera llega con el repositorio — escrita por un mantenedor, un colaborador o un atacante. RTK no las distinguía: un archivo de filtros provisto por el repositorio heredaba la misma autoridad que uno escrito por usted mismo, y se activaba en silencio. El aviso lo clasifica como CWE-345 (verificación insuficiente de la autenticidad de los datos) y CWE-426 (ruta de búsqueda no confiable).
La cadena de ataque es corta. No se reproduce aquí ningún payload funcional; lo que importa es la forma:
# Solo conceptual — ilustrativo, no una config funcional.
1. el atacante hace commit de .rtk/filters.toml junto a un backdoor
2. la víctima clona el repo y trabaja en él con Claude Code + RTK
3. la regex controlada por el atacante elimina las líneas del backdoor
de la salida de cat / git diff / escáner antes de que el modelo lea
4. el modelo revisa una vista filtrada e informa «sin problemas»Como el motor de RTK es genérico y está guiado por regex, un atacante podía suprimir todo lo que apareciera en la salida de un comando: líneas maliciosas eliminadas de un cat, advertencias retiradas de los resultados de un escáner, código de backdoor oculto en un git diff, indicadores de compromiso filtrados de un grep. El archivo de filtros parecía rutinario — nombres como reduce_noise, comentarios como «strip ANSI escape sequences» — y se camuflaba a plena vista. El modelo recibía una salida posterior al filtrado sin forma de saber que se habían eliminado líneas, porque RTK operaba por debajo de su capa de observación.
Por qué importa
Pillar describe la causa raíz como blanqueo de confianza (trust laundering): contenido procedente de un repositorio remoto, escrito por alguien que el desarrollador nunca conoció, recibía la misma autoridad que una configuración instalada localmente. La frontera de confianza seguía el tipo de contenido («¿es un filtro válido?») en lugar del origen («¿lo puso ahí el desarrollador?»). El mismo patrón reaparece en el utillaje de desarrollo con IA — .bashrc, perfiles de shell, archivos de instrucciones de agente como AGENTS.md y CLAUDE.md — donde un archivo de apariencia inerte se carga automáticamente y actúa con la autoridad que le concede la herramienta consumidora.
RTK añade una superficie nueva a ese patrón: la capa de observación. Una herramienta que controla lo que el modelo puede ver tiene relevancia de seguridad aunque nunca ejecute nada, porque un agente que no puede ver un backdoor no puede señalarlo. El efecto se acumula en los flujos donde el mismo agente escribe y revisa el código: un solo .rtk/filters.toml ciega ambas pasadas a la vez, y código comprometido puede pasar la revisión por IA y el análisis automatizado y llegar a producción sin que el desarrollador tenga motivo para dudar del resultado «limpio». El único acceso necesario: la capacidad de hacer commit de un pequeño archivo de configuración — al alcance de un colaborador, un contratista o una cuenta comprometida.
Defensas
- Actualice RTK. El descubridor indica que la corrección completa del modelo de confianza llegó en v0.33.0; el aviso de GitLab lista 0.32.0 como versión corregida. Pase a la última versión en cualquier caso y confirme la versión que realmente ejecutan sus equipos.
- Trace la frontera de confianza en el origen, no en el contenido. La configuración que llega desde un repositorio debe ser no confiable por defecto y exigir una aceptación explícita, repositorio por repositorio — exactamente lo que ahora impone la corrección de RTK, con una advertencia al usuario y al modelo más una verificación de integridad SHA-256 que revoca la confianza si el archivo cambia tras un
git pull. - Trate la capa de observación como parte de la cadena de suministro. Toda herramienta que preprocese, filtre o transforme la salida antes de que llegue a un agente de código moldea aquello sobre lo que el modelo puede actuar. Inventaríe esas herramientas y revise su modelo de confianza, incluso las que nunca ejecutan código. Véanse los riesgos de la cadena de suministro de skills/registros.
- No deje que un solo agente sea el único revisor de su propia salida. Cuando sea factible, revise con una vista sin filtrar o un pipeline independiente, para que una sola configuración envenenada no pueda cegar a la vez la generación y la revisión.
- Audite la configuración de agente local del repositorio en la revisión de código.
.rtk/filters.toml, archivos de instrucciones de agente y otros dotfiles merecen el mismo escrutinio que los scripts de build: son confianza ejecutable, no decoración.
Estado
| Elemento | Detalle |
|---|---|
| CVE | CVE-2026-45792 (GHSA-fvvm-949w-qj4w) |
| Componente | RTK (Rust Token Killer), hook de filtrado para Claude Code |
| Debilidad | CWE-345 (autenticidad de datos) · CWE-426 (ruta de búsqueda no confiable) |
| Severidad | CVSS 4.0 6,9 media (descubridor) · CVSS 3.1 8,2 alta (GLAD) |
| Corregido en | v0.33.0 (descubridor) · 0.32.0 (GLAD) — rechazo por defecto de filtros de proyecto no confiables + confianza por hash |
| Divulgación | Reportado el 15 de marzo de 2026 · parche el 25 de marzo · CVE asignado el 14 de mayo · público el 20 de mayo de 2026 |
La conclusión no es que «RTK sea especialmente inseguro» — los mantenedores lo corrigieron en 24 horas. La conclusión es la clase de ataque: en el desarrollo asistido por IA, la superficie de ataque incluye lo que no llega al modelo. Un atacante que controla la capa de filtrado nunca necesita inyectar nada en el contexto del agente; le basta con eliminar la evidencia de lo que ha plantado.