El repo no debería poder votar sobre su propia confianza

El 24 de abril de 2026, Anthropic publicó GHSA-q5hj-mxqh-vv77, una evasión del diálogo de confianza de Claude Code con CVSS 7.7. Treinta y siete días antes, el 18 de marzo, el mismo proyecto publicó GHSA-mmgp-wc2j-qcv7 con la misma puntuación CVSS. Dos evasiones del diálogo de confianza en el mismo runtime de agente en la misma ventana de seis semanas no son una coincidencia.¹²

La forma compartida es la lección. En el bug de marzo, el archivo .claude/settings.json controlado por el proyecto se leía antes de la verificación de confianza del workspace, y un modo de permiso bypassPermissions en ese archivo satisfacía trivialmente la barrera.² En el bug de abril, un repositorio malicioso incluye un archivo commondir manipulado dentro de .git/, el evaluador de confianza sigue el puntero hacia un directorio que el usuario ya considera de confianza, y el workspace hereda esa confianza sin que jamás se muestre el diálogo.¹

Dos líneas de texto dentro de un repo que nadie había abierto aún podían votar que un workspace fuera de confianza. Las superficies a nivel de proyecto que el repo trae consigo (hooks, configuraciones de servidor MCP, skills, subagentes) pueden entonces resolverse contra ese voto, ya sea con avidez al inicio de la sesión o de forma diferida cuando se invocan. Las defensas posteriores en cualquier runtime de agente están supeditadas a una decisión que el runtime toma antes de que existan.

Resumen

• Dos CVE de evasión del diálogo de confianza de Claude Code en 37 días muestran qué se rompe cuando bytes controlados por el repo influyen sobre la confianza del workspace.
• La solución inmediata del lado del usuario es actualizar más allá de la 2.1.84, restringir las rutas de confianza en ~/.claude.json y evitar la confianza amplia sobre rutas padre como ~/Projects.
• La solución estructural es un invariante de orden de carga: no interpretar ningún byte del workspace hasta que la ruta del workspace sea explícitamente de confianza.

Lo que realmente parchearon los dos avisos

Leer los parches contra la documentación hace visible la falla de orden de carga. Las versiones corregidas reordenan qué bytes puede consultar el evaluador de confianza.

El aviso de marzo describe que Claude Code resolvía la configuración del proyecto antes de resolver la confianza del workspace. La corrección en la 2.1.53 invierte ese orden, de modo que la verificación de confianza ya no lee .claude/settings.json desde dentro del workspace antes de que el usuario haya decidido.² El aviso de abril describe que el evaluador de confianza seguía el archivo commondir en el directorio .git/ de un repositorio mientras resolvía la propia ruta del workspace. La corrección en la 2.1.84 impide que el evaluador honre el contenido de commondir controlado por el repositorio durante la evaluación de confianza.¹ Ambos parches restauran el mismo invariante: la decisión de confianza no debe consultar bytes que residan dentro del workspace candidato.

Las clasificaciones de CVE apuntan al mismo diagnóstico. El bug de marzo está catalogado como CWE-807, Reliance on Untrusted Inputs in a Security Decision.³ El bug de abril está catalogado como CWE-20 más CWE-77, Improper Input Validation e Improper Neutralization of Special Elements, porque la resolución de commondir trataba bytes controlados por el repositorio como si fueran autoritativos.¹ CWE distintos, mismo supuesto roto: una barrera de seguridad que lee del artefacto al que está poniendo la barrera.

La superficie pre-confianza es más amplia de lo que sugiere la referencia de configuración

Claude Code documenta un conjunto de superficies controladas por el proyecto que se cargan al inicio de la sesión y que deben permanecer detrás de la barrera de confianza. Las dos CVE de esta clase prueban que el invariante se rompe cuando cualquiera de ellas entra en la propia decisión de confianza. Las superficies se dividen en dos ámbitos que el análisis de confianza tiene que mantener separados: bytes que vienen con un repositorio clonado, y bytes que un usuario añade a un workspace localmente sin commitearlos.⁴⁵⁶⁷

Superficies committeadas en el repo (vienen con git clone). Esta es la superficie de cadena de suministro. Cualquier cosa en este grupo es lo que un atacante controla cuando crea un repositorio malicioso.

Superficies locales del workspace (no commiteadas por defecto). Estas no llegan al workspace por la cadena de suministro; aparecen cuando un usuario local las crea. Aun así residen dentro de la ruta del workspace, por lo que la barrera de confianza debe seguir tratándolas como no confiables hasta que la ruta sea aprobada.

Los hooks viven dentro de .claude/settings.json en lugar de un archivo aparte; el aviso de abril describe al atacante poblando esa clave directamente.¹⁶ El bug de abril también reveló una superficie que no forma parte en absoluto de la referencia de configuración de Claude Code: un archivo interno de git llamado commondir, que resuelve un worktree de regreso a su repositorio padre.⁸ Un repositorio malicioso que trae una disposición de commondir manipulada hereda la confianza de la ruta objetivo cuando Claude Code sigue el puntero durante la evaluación de confianza. La superficie interna de git rompió el conteo de superficies de configuración del proyecto, y esa es la verdadera lección. La taxonomía no está cerrada. La superficie de ataque está definida por qué bytes se leen antes de que se dispare el diálogo, y cualquier cosa que pueda influir en la resolución de rutas o en la configuración entra al juego.

El patrón es el mismo que Los servidores MCP son la nueva superficie de ataque nombró en otra altitud.⁹ Los servidores MCP hicieron explotar la superficie de proveedores de herramientas antes de que el ecosistema alcanzara las implicaciones. La evasión del diálogo de confianza es la misma forma una capa más abajo. Cada función de conveniencia que permite a un repositorio preconfigurar el agente añade una fila a la taxonomía de arriba. Cada fila es candidata a ser la próxima CVE de la clase.

El reverso del mueble: un invariante de orden de carga, no un diálogo más inteligente

Paul Jobs le enseñó a Steve que la parte de abajo del mueble merece el mismo cuidado que el acabado.¹⁰ La metáfora del mueble no es decorativa aquí. Es la columna vertebral de la solución.

Un diálogo de confianza es el reverso del mueble. Los usuarios no ven el orden de carga. Ven un diálogo, hacen clic en Confiar, y asumen que cada byte dentro del workspace está inerte hasta ese clic. La implementación tiene que ganarse esa suposición. Cuando no lo hace, la suposición es la superficie de ataque.

El orden de carga es el invariante que decide si la suposición está ganada. El modelo mínimo implícito en los dos avisos y en la documentación pública de configuración de Claude Code es aproximadamente:²¹⁶

1. Leer la configuración del usuario desde ~/.claude/settings.json.
2. Leer la configuración del usuario desde ~/.claude/settings.local.json.
3. Evaluar si la ruta actual del workspace es de confianza.
4. Si no lo es, mostrar el diálogo. Si el usuario hace clic en Confiar, persistir la ruta.
5. Leer .claude/settings.json con ámbito de proyecto dentro del repo.
6. Leer .claude/settings.local.json con ámbito de proyecto.
7. Resolver hooks, servidores MCP, skills y subagentes a partir de la configuración fusionada.
8. Ejecutar los hooks de SessionStart.

Los avisos no documentan cada paso con exactitud, y la ubicación de skills, subagentes y MCP relativa a la fusión de configuración es un detalle de implementación que el usuario no ve. Lo que los avisos sí establecen es la frontera en el paso 3. Cualquier cosa resuelta antes del paso 3 está en la zona de entrada confiable. Cualquier cosa resuelta en el paso 3 o después no debe consultar bytes del workspace. El bug de marzo intercambió los pasos 3 y 5: la configuración del proyecto se resolvía primero, y el modo de permiso que esa configuración establecía (bypassPermissions) satisfacía trivialmente la verificación de confianza en el paso 3.² El bug de abril trasladó el ataque al propio paso 3: la resolución de la ruta del workspace consultaba un archivo commondir controlado por el repositorio, y una falsificación hacía que la verificación de confianza se resolviera contra la ruta de confianza elegida por el atacante.¹ De cualquier modo, para cuando llega el paso 7 o el paso 8, el workspace ya es de confianza, y cada superficie a nivel de proyecto se carga contra ese voto.

La regla que exige el reverso del mueble es una sola oración: no interpretar ningún byte dentro del workspace hasta que el usuario haya confiado explícitamente en la ruta del workspace. Ni .claude/settings.json. Ni commondir. Ni CLAUDE.md. Ni una lista de nombres de archivos. Ni un archivo de hook. Ni una configuración de servidor MCP. Si vive dentro del workspace, el código que decide la confianza no lo mira.

Visual Studio Code lanzó esta solución en mayo de 2021 como Workspace Trust (release 1.57). La clase central de confianza de carpetas no ha producido una evasión publicada desde que la función se lanzó, aunque siguen apareciendo problemas adyacentes en torno a dominios de confianza y comportamiento de extensiones.¹¹¹² La versión 2.1.53, la corrección referenciada por el aviso de marzo, aterrizó la versión Claude Code del invariante reordenando los pasos 3 y 5.² La versión 2.1.84, la corrección referenciada por el aviso de abril, lo aterrizó negándose a seguir archivos commondir controlados por el repositorio durante la evaluación de confianza.¹ Ambos son parches que restauran el invariante en lugar de inventar una nueva defensa.

El test de Steve tira del siguiente hilo: ¿firmaría Blake con su nombre esto?¹³ La respuesta para Claude Code en esta ventana de seis semanas es no, porque el vendor ha firmado, enviado y parcheado dos veces evasiones de esta clase. Esa es la barra del vendor a corregir. Producto Mínimamente Digno es el estándar al que se refiere la firma.¹⁴ Mínimo es una restricción de alcance, no un descuento de calidad. Un diálogo de confianza mínimo viable es un diálogo que bloquea el caso barato. Un diálogo de confianza mínimamente digno es el primer paso de un orden de carga que se niega a interpretar ningún byte del repositorio antes de que el usuario haya decidido. El producto que envías son los bytes que te niegas a interpretar hasta que tienes permiso.

Tres soluciones que exige el invariante

La regla es el invariante. Tres patrones se desprenden directamente de ella.

Barreras unidireccionales. El código que crea la confianza lee solo la ruta, el clic del usuario y el estado de confianza persistido fuera del workspace en ~/.claude.json.¹⁵ Nada más. Cualquier refactor en el que un archivo del workspace contribuya a la decisión de confianza es una regresión.

Sin confianza transitiva a través de la resolución de rutas. El invariante preferido es que worktrees, submódulos, archivos incluidos y destinos de symlinks reciban cada uno su propio prompt. Workspace Trust de Visual Studio Code, en cambio, permite que la confianza de la carpeta padre se aplique a las subcarpetas, y esa elección es lo que la confianza amplia sobre rutas padre como ~/Projects explota cuando la resolución de rutas es falsificada. La regla más estricta paga unos pocos diálogos extra y elimina toda la superficie de confianza transitiva; la regla más laxa mantiene baja la fricción y acepta que los bugs de resolución de rutas se conviertan en bugs de resolución de confianza.¹¹

Fixtures adversariales en el test de regresión del orden de lectura de confianza. Un repo adversarial creado deliberadamente que commitea archivos canario en el workspace. El test asegura que ninguna ruta de código lea esos canarios antes de que el diálogo sea confirmado. Si un cambio futuro al runtime lee cualquier archivo canario durante la evaluación de confianza, el build falla. CWE-501, Trust Boundary Violation, es la familia más amplia que vale la pena rastrear en la taxonomía del test junto con las clasificaciones más específicas CWE-807 y CWE-20/CWE-77 que ya usan los avisos publicados.¹⁶

Ninguna de las tres es costosa. La primera es la ausencia de código. La segunda cuesta fricción visible para el usuario. La tercera es una pasada de ingeniería más disciplina de ahí en adelante. El compromiso del bootstrap de confianza es una categoría donde la postura habitual de defensa en profundidad no se aplica, porque cada capa posterior a la confianza se ejecuta contra la decisión de confianza que el workspace acaba de ayudar a tomar. Construir defensa fuera de la confianza es imposible en la capa del scaffolding porque el scaffolding es exactamente lo que el workspace puede leer una vez que la confianza se resuelve.

El vendor tiene que enviar el invariante. Las CVE de evasión del diálogo de confianza son la manera en que los observadores miden si el vendor está cumpliendo con la barra. Dos en seis semanas no es ruido. Es una señal de que el invariante no ha sido codificado en la suite de tests como una aserción que el build hace cumplir. Hasta que lo esté, la próxima CVE de la clase es cuestión de encontrar la décima entrada.

El repo no debería poder votar sobre su propia confianza. La confianza es la única decisión que el artefacto evaluado no debe ayudar a tomar. Cada otra capa de la defensa del agente (hooks, skills, validadores, detectores, guardas) vive aguas abajo de ese único voto. Cuando el voto está amañado, el trabajo aguas abajo es mobiliario. El acabado del mueble no salva al reverso.

Preguntas frecuentes

¿Qué es la evasión del diálogo de confianza de Claude Code?

Una evasión del diálogo de confianza de Claude Code ocurre cuando un workspace no confiable es tratado como de confianza antes de que el usuario lo apruebe explícitamente. En la CVE de marzo de 2026, la configuración controlada por el repo influía en el modo de permiso antes de que se evaluara la confianza. En la CVE de abril de 2026, una disposición de worktree/commondir manipulada en git hacía que la confianza se resolviera a través de una ruta ya confiable.

¿Cómo debo restringir las rutas de confianza en ~/.claude.json?

Abre ~/.claude.json e inspecciona el mapa projects. Busca entradas donde hasTrustDialogAccepted esté en true sobre directorios que ya no contienen código activo, sobre rutas padre amplias como ~/Projects, y sobre cualquier ruta que se solape con disposiciones adyacentes a worktrees. La confianza por repositorio añade diálogos pero impide que una ruta padre aceptada cubra silenciosamente a cada hijo.

¿Por qué es peligrosa la confianza sobre rutas padre para Claude Code?

La confianza sobre rutas padre es peligrosa porque un directorio aceptado puede cubrir muchos workspaces hijos. Si la resolución de rutas es falsificada, o un worktree malicioso apunta de regreso a ese padre, el repo hijo puede heredar una confianza que nunca le fue otorgada. La confianza por repo añade fricción, pero impide la confianza transitiva entre repos no relacionados.

¿Qué invariante previene las evasiones del diálogo de confianza?

El invariante es: no interpretar ningún byte dentro del workspace hasta que el usuario confíe explícitamente en la ruta del workspace. El código de confianza puede leer la ruta, el clic del usuario y el estado de confianza persistido fuera del repo. No debe leer .claude/settings.json, CLAUDE.md, .mcp.json, hooks, skills, commondir, ni ningún archivo controlado por el repo antes del diálogo.

Referencias