Ayudó y punto: por qué la herramienta de IA de Google empezó a ejecutar instrucciones de hackers sin hacer demasiadas preguntas

Las herramientas basadas en IA cada vez asumen más tareas rutinarias de los desarrolladores, pero junto con la comodidad aumenta el riesgo: basta con una sola configuración insegura para que el asistente ejecute por sí solo un comando malicioso. Las recientes correcciones de Google y los informes de especialistas muestran cuán peligrosos se vuelven esos escenarios en CI/CD y en entornos de desarrollo.

Google resolvió una vulnerabilidad crítica en Gemini CLI, que afectó al paquete npm @google/gemini-cli y al workflow google-github-actions/run-gemini-cli para GitHub Actions. El problema obtuvo una puntuación de 10.0 en la escala CVSS, pero aún no tiene un identificador CVE. Estaban en riesgo las versiones @google/gemini-cli anteriores a 0.39.1, @google/gemini-cli anteriores a 0.40.0-preview.3 y google-github-actions/run-gemini-cli anteriores a 0.1.22.

Según Novee Security, un atacante externo sin privilegios podría forzar a la herramienta a descargar una configuración maliciosa de Gemini. Después de eso, los comandos se ejecutaban directamente en el host antes de iniciar la sandbox. El riesgo afectaba sobre todo a los workflows en los que Gemini CLI funcionaba en modo headless y procesaba datos no confiables, por ejemplo un pull request de usuarios externos.

La causa radicaba en la confianza automática en la carpeta de trabajo actual en entornos de CI. Gemini CLI podía, sin verificación manual, cargar las configuraciones detectadas y las variables de entorno desde el directorio local .gemini. Un atacante podía colocar allí archivos preparados con antelación y convertir el pipeline en un vector de ataque contra la cadena de suministro.

En las nuevas versiones, Google exige confiar explícitamente en las carpetas antes de leer la configuración. Para entradas verificadas, la compañía propone activar la variable GEMINI_TRUST_WORKSPACE, y al trabajar con código no confiable — reforzar adicionalmente el workflow según las recomendaciones del proyecto. Google también cambió el comportamiento del modo --yolo: ahora el mecanismo de políticas toma en cuenta la lista de herramientas permitidas, para que la aprobación automática no ejecute comandos peligrosos sin control.

Así, ya no se puede considerar a los agentes de IA en desarrollo como asistentes inofensivos: cuanto más permisos recibe dicha herramienta, más estrictos deben ser los límites de confianza, la validación de entradas y el control sobre cualquier acción automática.