Un issue de GitHub puede tomar el control de tres agentes de código
La investigación de Novee, difundida el 6 de agosto de 2026 tras presentarse el día anterior en Black Hat USA, muestra cómo contenido de un issue de GitHub podía comprometer flujos automatizados de Claude Code, Gemini CLI y OpenAI Codex. El programa anunciado para la sesión situaba el problema en los traspasos de confianza entre componentes y documentaba ejecución de comandos, exposición de secretos, persistencia y elusión de políticas.
La publicación del 6 de agosto no demuestra que cualquier incidencia controle automáticamente cualquier instalación. La síntesis técnica de las tres cadenas describe configuraciones concretas en las que un usuario sin privilegios podía introducir texto externo, activar un workflow y conseguir que un agente con acceso a herramientas, archivos o credenciales actuara sobre esas instrucciones.
El issue se convertía en una instrucción con privilegios
El punto común no era una vulnerabilidad idéntica en los tres productos. Era una frontera de confianza mal definida: el workflow recogía texto escrito por un tercero, pero una etapa posterior lo procesaba con la autoridad de un componente interno.
El riesgo aparecía cuando el agente trabajaba sin intervención humana y podía ejecutar comandos, modificar el checkout o leer secretos disponibles en el runner. En ese contexto, tomar el control significa influir en las acciones autorizadas al agente hasta obtener ejecución, acceso a credenciales o persistencia entre etapas; no implica controlar por defecto todos los equipos que tengan instalada alguna de las tres herramientas.
La inyección de instrucciones era solo el inicio. El efecto dependía del código que rodeaba al modelo —el harness— y que decidía qué archivos leer, qué herramientas permitir, dónde escribir y qué estado conservar. Una protección aplicada en una etapa dejaba de servir si la siguiente interpretaba el mismo dato con más privilegios o bajo reglas diferentes.
Tres agentes y tres mecanismos distintos
En el flujo basado en Claude Code, la cadena combinaba contenido controlado desde GitHub con diferencias entre la validación de una operación y su ejecución efectiva. El resultado documentado incluía la posibilidad de ejecutar acciones no previstas y alcanzar secretos presentes en el runner. Las correcciones afectaron a varios puntos de la cadena, por lo que reducir el caso a una sola inyección de prompt ocultaría el fallo principal: la discrepancia entre lo aprobado y lo que finalmente hacía la herramienta.
Gemini CLI fallaba por otro camino. En ejecuciones automatizadas, versiones anteriores podían confiar automáticamente en el espacio de trabajo y cargar configuración aportada por una contribución externa; además, el modo de ejecución permisivo no respetaba correctamente las restricciones detalladas de herramientas. El registro de la vulnerabilidad de Gemini CLI identifica como versiones corregidas la 0.39.1, la 0.40.0-preview.3 y run-gemini-cli 0.1.22, e indica que el nuevo modelo exige confianza explícita y aplica la lista de herramientas también en el modo --yolo.
En el caso de Codex, el problema estaba en el estado compartido entre dos pasadas del workflow. La primera ejecución podía escribir un archivo AGENTS.md dentro del directorio común; una segunda lo cargaba después como instrucciones del repositorio. Si el contenido externo conseguía modificar ese archivo y provocar la segunda pasada, la instrucción dejaba de parecer una entrada del atacante y reaparecía como configuración local de confianza.
La diferencia importa para la defensa. Actualizar un binario puede cerrar un fallo de validación o de permisos, pero no corrige automáticamente una copia independiente de un workflow que conserva directorios escribibles, credenciales y archivos de instrucciones entre etapas.
Las defensas deben seguir la cadena completa
El primer control es impedir que una etapa expuesta a contenido externo tenga autoridad innecesaria. Un proceso dedicado a clasificar o resumir issues no necesita, por regla general, un token con escritura, credenciales de despliegue ni acceso amplio al sistema de archivos.
También debe revisarse el flujo completo, no solo la configuración visible del modelo. Esto incluye los disparadores de GitHub Actions, el alcance del token, los secretos inyectados, los directorios compartidos, los artefactos que pasan de un trabajo a otro y los archivos que el agente interpreta como instrucciones. En ese inventario deben figurar las cuentas usadas por los agentes, porque sus permisos delimitan el impacto posible.
- Actualizar Claude Code, Gemini CLI y las acciones relacionadas a versiones corregidas, fijando dependencias a revisiones verificadas.
- Tratar títulos, cuerpos, comentarios, adjuntos y archivos de contribuciones externas como entrada no confiable.
- Procesar esa entrada sin secretos y con permisos de repositorio de solo lectura.
- Separar trabajos, checkouts y runners para que una etapa no confiable no pueda dejar instrucciones a la siguiente.
- Bloquear la creación o modificación de AGENTS.md y otros archivos de configuración desde etapas expuestas.
- Exigir aprobación antes de escribir en el repositorio, publicar paquetes o iniciar despliegues.
- Rotar las credenciales que estuvieron disponibles durante ejecuciones vulnerables y revisar sus registros de uso.
Qué está confirmado y qué no
La investigación documenta cadenas reproducibles en workflows asociados a los tres fabricantes y muestra que una incidencia pública podía convertirse en el punto de entrada. También constan cambios en los productos o repositorios examinados, aunque cada cadena recibió una corrección diferente.
No hay en las páginas revisadas evidencia de explotación criminal generalizada ni base para afirmar que todas las instalaciones sean vulnerables. El riesgo pendiente está en los repositorios que copiaron esos patrones: agentes activados por contenido externo, etapas que comparten estado escribible y credenciales disponibles antes de establecer una frontera de confianza.
La conclusión técnica es más estrecha que el titular, pero también más útil: un issue puede dirigir las acciones de Claude Code, Gemini CLI o Codex cuando el workflow convierte texto no confiable en instrucciones y le añade permisos. La barrera decisiva no es pedir al modelo que reconozca el engaño, sino evitar que una entrada pública alcance una etapa capaz de ejecutar, conservar cambios o publicar software.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.