Bypass de allowlist en Cursor: los built-ins del shell envenenan el entorno

¿Qué es esto?

CVE-2026-22708 es un bypass de allowlist en el editor de código Cursor, divulgado por el investigador de Pillar Security Dan Lisichkin en The Agent Security Paradox (publicado el 14 de enero de 2026; reportado a Cursor el 11 de agosto de 2025). El NVD registra dos puntuaciones: CVSS 3.1 9.8 (Crítica) y CVSS 4.0 7.2 (Alta). La falla está corregida en Cursor 2.3.

La técnica es simple: cuando el agente de Cursor se ejecuta en modo Auto-Run con una allowlist, un puñado de built-ins del shell — export, unset, set, typeset, declare — se ejecutan sin aparecer nunca en la allowlist y sin pedir aprobación. Un atacante que controla las instrucciones del agente (de forma directa, o indirecta mediante un archivo o una página web maliciosa que el agente lee) usa esos built-ins para envenenar de forma silenciosa las variables de entorno y luego espera a que se ejecute un comando de confianza. El tema resurgió el 11 de junio de 2026, cuando el informe State of Agentic AI Security de OWASP lo citó entre los CVE de inyección de prompt que ya se observan contra herramientas de codificación en producción.

Cómo funciona

La allowlist de Cursor valida los binarios externos antes de su ejecución. Los built-ins del shell no son binarios separados —se ejecutan dentro de la propia sesión del shell— por lo que esquivan por completo el evaluador de comandos del lado del servidor. Ahí está toda la brecha: la allowlist comprueba qué se ejecuta, nunca el contexto de entorno en el que se ejecuta.

En cuanto un atacante puede fijar variables de entorno gratis, recurre a las que cambian el comportamiento de las herramientas habituales. Una cadena común abusa del pager que invocan git y man:

# Se ejecuta en silencio — un built-in, nunca sometido a aprobación:
export PAGER="[REDACTADO: comando]"

# Parece inofensivo, a menudo ya en la allowlist — dispara la carga:
git branch

El usuario aprueba git branch creyéndolo inofensivo; el PAGER envenenado ejecuta el código del atacante en lugar de mostrar la salida. Pillar también demostró una variante totalmente «zero-click» usando typeset y las banderas de expansión de parámetros de zsh para forzar la evaluación de una cadena incrustada sin ninguna aprobación, además de una cadena más larga vía PYTHONWARNINGS → BROWSER → PERL5OPT que logra ejecución de código la próxima vez que se lanza cualquier script de Python. Las cargas reales se omiten aquí; lo que importa es el mecanismo, no la cadena de explotación.

La lección de fondo que extrae Pillar es un cambio en el modelo de confianza. Manipular variables de entorno para lograr RCE es antiguo (Elttam lo documentó en 2020), pero antes exigía acceso local y una preparación manual en varios pasos. Un agente que sigue las instrucciones de contenido no confiable reduce todas esas condiciones previas a una sola inyección de prompt, ejecutada de forma remota con los privilegios del desarrollador.

Por qué importa

Los asistentes de codificación con IA están hoy entre los productos más atacados por inyección de prompt, porque una inyección exitosa se ejecuta en la máquina de un desarrollador con acceso al código fuente, claves SSH, credenciales en la nube y la red local. CVE-2026-22708 muestra que la solicitud de aprobación con humano en el bucle —el control en el que se apoyan la mayoría de los equipos— puede ser inducida a mentir: el comando visible y aprobado es inofensivo, mientras que la preparación maliciosa ocurrió de forma invisible mediante built-ins que nunca se mostraron. Cualquier IDE agéntico que controle los comandos pero no el contexto de ejecución comparte esta clase de debilidad, no solo Cursor.

Defensas

Actualice Cursor a 2.3 o posterior, donde el analizador del lado del servidor ahora exige aprobación explícita para todo comando que no pueda clasificar. Más allá del parche:

• No trate la allowlist como una frontera de seguridad. La propia documentación de Cursor indica que la allowlist es de mejor esfuerzo y que los bypasses son posibles; nunca active un modo «Run Everything». Mantenga las allowlists cortas y evite auto-aprobar herramientas amplias como git, python o npm.
• Trate los built-ins del shell como sensibles para la seguridad. Los cambios de variables de entorno (export, typeset, declare, unset) merecen la misma vigilancia que la ejecución de comandos, no un pase implícito.
• Prefiera el aislamiento al saneamiento. Ejecute el agente dentro de un sandbox o un contenedor desechable donde la ejecución de código y los cambios de variables no puedan alcanzar el host real, las claves SSH ni las credenciales. Pillar sostiene —y el ataque lo confirma— que el aislamiento de ejecución, no las allowlists, es el control duradero para los agentes que legítimamente necesitan ejecutar código.
• Reinicie el entorno entre sesiones del agente para que una variable envenenada no persista hacia una acción de confianza posterior.
• Limite lo que el agente lee. La inyección indirecta llega a través de archivos del repositorio, documentos y páginas web; restringir y revisar las entradas no confiables reduce la superficie de disparo.

Estado

Elemento	Detalle
Identificador	CVE-2026-22708
Afectado	Cursor anterior a 2.3 (Auto-Run + allowlist)
Corregido en	Cursor 2.3
CVSS (NVD)	9.8 Crítica (v3.1) / 7.2 Alta (v4.0)
Reportado	11 de agosto de 2025
Divulgación pública	14 de enero de 2026 (Pillar Security)
Requisito de explotación	Inyección de prompt (directa o indirecta) en el agente