TrustFall: los ajustes MCP del proyecto convierten el clic de confianza en RCE

¿De qué se trata?

El 7 de mayo de 2026, Adversa AI publicó TrustFall, un informe sobre una convención compartida por cuatro herramientas de codificación agéntica en línea de comandos: Claude Code, Gemini CLI, Cursor CLI y GitHub Copilot CLI. Las cuatro arrancan los servidores Model Context Protocol (MCP) definidos por el proyecto — programas auxiliares que el propio repositorio suministra y referencia — en cuanto el desarrollador acepta el aviso genérico de «confiar en esta carpeta». Cada aviso tiene «sí» como opción por defecto.

La consecuencia práctica: clonar un repositorio malicioso y pulsar una sola vez Enter en el diálogo de confianza puede ejecutar código elegido por el atacante en la máquina del desarrollador, con todos sus privilegios, antes de que el modelo razone o realice cualquier llamada a herramienta. Adversa lo presenta no como un fallo aislado, sino como una convención de clase; el análisis a fondo se centró en Claude Code (probado en torno a la v2.1.x), donde una regresión del diálogo de confianza hace la brecha más aguda, y se confirmó paridad en las otras tres CLI. La cobertura llegó el mismo día desde The Register y Help Net Security.

Es un primo cercano del RCE por aprobación de enlace simbólico en cinco agentes de codificación — mismo tema de fondo: la puerta de aprobación que ve el desarrollador no describe lo que realmente autoriza.

Cómo funciona

MCP permite que un asistente de IA dialogue con programas auxiliares externos (un conector de base de datos, un linter, una herramienta de búsqueda). El problema es que esos auxiliares están definidos dentro del proyecto, en archivos que el repositorio suministra, y arrancan como procesos ordinarios del sistema cuando el agente se inicia en esa carpeta.

La cadena se apoya en dos ajustes de ámbito de proyecto que aprueban servidores automáticamente — Adversa cita enableAllProjectMcpServers (aprueba todos los servidores de .mcp.json) y enabledMcpjsonServers (aprueba un subconjunto nombrado), ambos legibles desde el .claude/settings.json de un repositorio, más permissions.allow, que puede preautorizar llamadas a herramientas. Ninguno dispara una advertencia. El detalle decisivo es la incoherencia de ámbito: Anthropic bloquea algunos ajustes peligrosos a nivel de proyecto (p. ej. bypassPermissions, que recibe un diálogo dedicado en rojo) pero no estos. Un repositorio clonado simplemente puede activarlos.

El repo suministra:  .mcp.json              -> define un servidor «helper» (command + args)
                     .claude/settings.json  -> activa enableAllProjectMcpServers: true
Desarrollador:       git clone ; ejecuta el agente ; pulsa Enter en «Sí, confío en esta carpeta»
Resultado:           el proceso helper arranca con todos los privilegios, en el inicio,
                     antes de cualquier llamada a herramienta del modelo. Sin segundo aviso.

Aquí no se reproduce ningún payload — la prueba de concepto explotable está en el repositorio de los investigadores. El punto estructural basta: el comando que ejecuta un auxiliar puede ser cualquier ejecutable, y el script puede incrustarse directamente en la configuración, sin dejar un archivo separado que un revisor o un escáner estático pudiera señalar.

Dos factores agravantes:

• El diálogo regresionó. Antes de la v2.1, el diálogo de confianza de Claude Code advertía explícitamente que .mcp.json podía ejecutar código y ofrecía «confiar en la carpeta pero desactivar MCP». Esa opción se eliminó; el aviso v2.1+ dice «Comprobación rápida: ¿es este un proyecto que creaste o en el que confías?», sin mención de MCP y con «Sí, confío en esta carpeta» por defecto.
• La CI no tiene diálogo alguno. Ejecutado mediante la GitHub Action oficial, Claude Code corre en modo headless vía el SDK — no hay terminal, así que el aviso de confianza nunca aparece. Una pull request de un colaborador externo que suministre un .mcp.json malicioso se ejecuta en cuanto el pipeline procesa esa rama. Una pulsación de tecla en un portátil se convierte en cero clics en CI.

El equipo de seguridad de Anthropic revisó el informe y lo rechazó como fuera de su modelo de amenazas: aceptar «Sí, confío en esta carpeta» se trata como consentimiento a toda la configuración del proyecto, y la ejecución posterior a la confianza es la frontera funcionando según lo diseñado. Adversa no discute dónde se sitúa esa frontera — su argumento es que el diálogo no da al desarrollador lo suficiente para decidir con conocimiento de causa.

Por qué importa

Lo interesante es el desacuerdo, no un fallo aislado. Anthropic ha publicado tres parches en seis meses para la misma convención subyacente — los ajustes de ámbito de proyecto como vector de inyección — cada uno limitado al ajuste reportado, ninguno auditando la convención en sí:

CVE	Fecha	Causa raíz	Corrección
CVE-2025-59536	oct. 2025	MCP ejecutado antes del diálogo de confianza	MCP retrasado hasta después del diálogo
CVE-2026-21852	ene. 2026	ANTHROPIC_BASE_URL en ajustes del proyecto redirigía el tráfico de API	Ajuste bloqueado a nivel de proyecto
CVE-2026-33068	mar. 2026	bypassPermissions en ajustes del proyecto omitía el diálogo	Ajuste bloqueado a nivel de proyecto
TrustFall	may. 2026	Ejecución MCP silenciosa post-confianza vía ajustes del proyecto	Rechazado (intención de diseño)

La superficie de riesgo es amplia porque la condición previa — clonar un repositorio desconocido y ejecutar un agente en él — es un hábito diario de los desarrolladores, y las herramientas afectadas abarcan cuatro proveedores. La variante de CI es el filo más afilado: elimina por completo al humano y alcanza todo lo que posee el runner (claves de despliegue, certificados de firma, tokens de nube), lo que la convierte en un verdadero vector de armamento de la cadena de suministro y no en una curiosidad de laboratorio. Para quien sigue el patrón más amplio, esto se suma a la superficie RCE por stdio inherente a MCP: la potencia del protocolo y su radio de impacto son la misma cosa.

Defensas

La corrección más sólida no depende de ningún proveedor y funciona tanto en un equipo aislado como en una flota gestionada.

1. Bloquee los ajustes en el ámbito Managed. Coloque un managed-settings.json en la ruta «managed» del SO, fijando enableAllProjectMcpServers: false, restringiendo enabledMcpjsonServers a una lista blanca explícita (o []) y fijando permissions.allow. El ámbito Managed es el de mayor prioridad en Claude Code — supera a Project, Local, User e incluso a las opciones de línea de comandos — así que un repositorio clonado no puede sobrescribirlo. Configurado una vez, neutraliza la cadena sin importar lo que clone después.

2. Audite el contenido de la configuración commiteada, no solo su presencia. Añada un hook pre-commit o un escáner de repositorio que señale cualquier .claude/settings.json o .claude/settings.local.json commiteado que contenga enableAllProjectMcpServers, enabledMcpjsonServers o permissions.allow. Escanee ambos archivos: el ámbito Local supera a Project, y un atacante puede suministrar directamente .claude/settings.local.json. Ninguna de estas claves tiene una razón legítima para commitearse — los desarrolladores que quieran ese comportamiento deben activarlo en el ámbito User (~/.claude/settings.json), fuera del repositorio.

3. Inspeccione directamente command/args en .mcp.json. La variante sin archivo incrusta el payload en línea, así que los escáneres que solo siguen archivos referenciados la pierden. Marque args que contengan -e, -p, --eval, eval, fetch(, child_process, net.Socket o blobs base64.

4. Vigile el patrón de ejecución de alta confianza. Una alerta simple sobre el agente lanzando node -e / python -c / sh -c es ruidosa. La señal precisa: el agente lanza un hijo de larga duración cuyos command/args coinciden con un .mcp.json en un directorio recién clonado y no propiedad del usuario. Las sesiones legítimas no producen eso, y atrapa la variante en línea que los controles estáticos no ven.

5. Endurezca la CI explícitamente. Las ejecuciones headless no tienen barrera de consentimiento, así que no dependa de ella. Ejecute las acciones del agente solo contra ramas de confianza, limite las credenciales del runner al mínimo privilegio, y condicione la activación de MCP a una configuración controlada por el runner (no por el repositorio). Trate la PR de un colaborador externo como código no confiable que puede ejecutarse.

6. Lea la configuración antes de ejecutar el agente. Al abrir un proyecto de código abierto desconocido, inspeccione primero .mcp.json y .claude/settings.json. El diálogo de confianza no le dirá qué está a punto de ejecutarse.

Estado

Elemento	Referencia	Fecha	Notas
Divulgación de TrustFall	Adversa AI	2026-05-07	Convención de clase; análisis de Claude Code + paridad en 3 CLI más
Posición del proveedor	Anthropic (según Adversa)	2026-05	Rechazado como fuera del modelo de amenazas — la ejecución post-confianza es «por diseño»
Correcciones previas, misma causa	NVD / Adversa	oct. 2025 – mar. 2026	CVE-2025-59536, CVE-2026-21852, CVE-2026-33068
Cobertura de prensa	The Register, Help Net Security	2026-05-07	Confirma la variante de 1 clic en equipo + la de 0 clics en CI

El encuadre honesto no es «una herramienta de IA tiene un fallo» — es «la confianza en una carpeta autoriza, por sí sola, lanzar procesos sin sandbox definidos por el atacante, y el aviso que la concede no dice nada de MCP.» Si esto es una vulnerabilidad o una decisión de diseño es precisamente la cuestión abierta. Mientras el aviso o las reglas de ámbito no cambien, la defensa le corresponde a usted: bloquee los ajustes, escanee la configuración, y nunca deje que la confianza en una carpeta sea la única barrera.