GitHub Copilot CLI: cómo un archivo podía ocultar comandos

CVE-2026-29783 permitía ocultar comandos peligrosos en operaciones aparentemente seguras e involucraba repositorios, MCP y prompt injection.

Ainoa · 22 de octubre de 2026 · Seguridad · 4 Min Read

GitHub Copilot CLI: cómo un archivo podía ocultar comandos

Un desarrollador abre un repositorio y pide a un agente que revise el proyecto. El asistente encuentra instrucciones dentro de un README, un comentario o la respuesta de una herramienta. Después propone un comando que parece inofensivo, pero contiene una expansión capaz de ejecutar otra operación escondida. Ese fue el riesgo detrás de la vulnerabilidad de GitHub Copilot CLI CVE-2026-29783.

El caso es importante porque une tres superficies que muchas empresas ya utilizan: agentes de programación, contenido de repositorios y herramientas conectadas mediante MCP. Una fuente que parece documental puede influir en una acción con efectos reales sobre el equipo del desarrollador.

¿Qué permitía CVE-2026-29783?

Según el aviso revisado de GitHub, la herramienta de shell de GitHub Copilot CLI no identificaba correctamente ciertos patrones de expansión de parámetros de Bash. Un comando podía presentarse como una operación de solo lectura y, al evaluarse, construir y ejecutar otro comando.

La vulnerabilidad afecta versiones hasta la 0.0.422 y fue corregida en la 0.0.423. La recomendación inmediata es actualizar y evitar el uso de clientes antiguos, especialmente en entornos donde el agente puede ejecutar shell.

Por qué el contenido del repositorio también es una entrada

Los agentes de código leen más que la pregunta del usuario. Pueden consultar archivos, documentación, issues, comentarios y resultados de servidores MCP. Para el modelo, todo ese material forma parte del contexto. Si no se conserva una separación clara entre datos e instrucciones, un texto malicioso puede orientar la siguiente acción.

Esto se conoce como prompt injection indirecta. El atacante no necesita conversar con el agente: coloca contenido donde sabe que el agente lo leerá.

El problema de clasificar un comando por su apariencia

Un control de seguridad puede decidir que comandos como echo son inocuos. Sin embargo, Bash posee mecanismos de expansión que construyen expresiones durante la ejecución. Analizar únicamente la primera palabra o la forma superficial del comando deja espacios para comportamientos ocultos.

La protección debe evaluar el resultado real, limitar las funciones admitidas y mantener la aprobación humana para acciones que salen de un conjunto comprobado.

Qué deberían hacer los equipos de desarrollo

Actualizar GitHub Copilot CLI

Comprueba que la versión sea 0.0.423 o posterior. Incluye los equipos locales, imágenes de desarrollo, runners y ambientes temporales.

Tratar el repositorio como contenido no confiable

Revisa cambios provenientes de forks, dependencias, issues y archivos generados. No permitas que instrucciones encontradas en esos recursos adquieran automáticamente la misma autoridad que la solicitud del usuario.

Restringir el shell del agente

Utiliza listas permitidas, directorios de trabajo específicos, contenedores desechables y bloqueo de red. Evita montar credenciales personales o llaves de producción.

Revisar servidores MCP

Un servidor MCP puede devolver contenido o exponer herramientas. Verifica su origen, fija versiones, limita el token utilizado y revisa los parámetros en el código que ejecuta la acción.

Separar propuesta y ejecución

El agente puede explicar un comando antes de ejecutarlo. Para operaciones sensibles, la aprobación debe mostrar la acción final ya expandida, el directorio, los archivos afectados y el destino de red.

Un escenario posible en una empresa

Un agente recibe la tarea de revisar una dependencia. Dentro de su documentación encuentra una instrucción encubierta que le pide consultar una variable de entorno y enviarla a una URL. Si tiene acceso a secretos y red sin restricciones, la cadena puede terminar en una filtración. Si el entorno no contiene secretos, la red está limitada y la llamada requiere aprobación, el ataque pierde su camino.

MCP no elimina la necesidad de gobernar herramientas

MCP estandariza la conexión entre asistentes, datos y acciones. No convierte automáticamente una herramienta en segura. La aplicación debe validar permisos, argumentos, identidad y contexto en cada llamada.

En Ainoa diseñamos agentes inteligentes a la medida e integraciones que respetan los límites de cada proceso. Definimos qué puede leer el agente, qué puede proponer y qué requiere aprobación antes de ejecutar.

Si tu equipo está conectando agentes a repositorios, terminales o servicios MCP, podemos ayudarte a revisar la arquitectura y reducir accesos innecesarios. Hablemos sobre agentes útiles y controlables.

Fuentes

Contenido relacionado

¿Diagnóstico gratis en 5 min?