Un 10.0 en el kit de agentes de Google, y una mitigación que lo dice todo

Ayer, 9 de septiembre, Google Cloud publicó un registro de vulnerabilidad actuando como su propia autoridad de numeración. El identificador es CVE-2026-79696 y el título oficial que le puso Google es explícito: ejecución remota de código en ADK para Python por una lista de bloqueo incompleta de la biblioteca estándar.

El puntaje CVSS 4.0 es 10.0. No hay puntaje más alto.

Escribo sobre esto porque el número va a circular solo, y el número no es lo interesante.

Qué pasó

El Agent Development Kit para Python es el kit con el que muchos equipos están construyendo agentes sobre infraestructura de Google. La falla afecta a las versiones 2.0.0 hasta 2.6.0, en despliegues propios, en Cloud Run y en GKE, con una condición: que pytest esté instalado en el entorno.

El vector es el peor posible. Red, complejidad baja, sin privilegios previos, sin interacción del usuario. Y los tres impactos sobre el sistema vulnerable —confidencialidad, integridad, disponibilidad— están en alto, igual que los tres impactos sobre los sistemas subsiguientes. Eso último es lo que empuja el puntaje a 10.0: el compromiso no se queda en el proceso afectado.

Técnicamente es un CWE-184, lista incompleta de entradas no permitidas. Alguien intentó enumerar qué módulos de la biblioteca estándar no se podían invocar, y la enumeración quedó corta. Un atacante sin autenticar ejecuta código arbitrario enviando una repetición de sesión de prueba manipulada a la interfaz adk web.

La solución oficial de Google tiene dos partes. La primera es actualizar a google-adk 2.7.0 o posterior. La segunda, textual: no exponer adk web a una red.

Por qué importa

Esa segunda línea es la nota. Nadie escribe «no expongas esto a una red» sobre una herramienta que nadie está exponiendo a una red.

Y hay algo más, que es lo que de verdad me hizo sentarme a escribir. La versión 2.7.0, la que contiene el arreglo, se subió a PyPI el 13 de agosto. Sus notas de versión no mencionan el fallo. El CVE que le pone nombre y puntaje apareció el 9 de septiembre: veintisiete días después. Todo ese tiempo el parche existía y el aviso no. Hoy la versión vigente ya es la 2.8.0, del 26 de agosto.

Eso no es negligencia de Google: es cómo funciona la divulgación coordinada, y publicar el arreglo antes que el aviso es exactamente lo correcto. Pero tiene una consecuencia operativa que conviene decir en voz alta: si tu proceso de actualización de dependencias se dispara con los avisos de seguridad y no con las versiones, estuviste un mes sin saber que tenías que moverte.

El enriquecimiento que la agencia de ciberseguridad de Estados Unidos añadió al registro cierra el cuadro con tres campos. Explotación observada: ninguna. Automatizable: sí. Impacto técnico: total. Ese es el estado más incómodo posible. Todavía no hay exploit público, el impacto es completo, y cuando aparezca se automatiza.

Qué implica si diriges una empresa de tecnología

Hay tres lecturas concretas, y ninguna es «actualiza el paquete». Eso ya lo sabes.

La primera es de higiene de imagen. La condición de explotación es que pytest esté instalado. En una imagen de producción bien construida, pytest no está. Si tu despliegue es vulnerable, el CVE te está informando de dos cosas al mismo tiempo: que usas ADK, y que empaquetaste tus dependencias de desarrollo dentro del contenedor que corre en producción. La segunda es tuya, no de Google, y probablemente no aplica solo a este paquete.

La segunda es de superficie. Casi todo framework de agentes de esta generación trae una interfaz de inspección: para ver trazas, reproducir sesiones, depurar la cadena de llamadas. Esa interfaz nace pensada para localhost y termina viajando dentro del mismo contenedor que el servicio. El salto de prototipo a producción, cuando se hace rápido, no borra esa interfaz: solo le cambia la dirección IP. Vale la pena tratar cada panel de depuración del stack como una superficie expuesta hasta que alguien demuestre lo contrario.

La tercera es de arquitectura, y es la más incómoda. Una lista de bloqueo es una apuesta a que enumeraste todo lo peligroso. Siempre falla del mismo modo: alguien encuentra el módulo que no estaba en la lista. Una lista de permitidos falla cerrada —rompe algo legítimo y te enteras en pruebas— mientras que una lista de bloqueo falla abierta, y de eso te enteras cuando ya es tarde. En cualquier punto donde tu producto ejecute algo que vino de afuera, y un agente hace precisamente eso todo el día, ese detalle deja de ser una preferencia de estilo.

Mi lectura

Llevo meses viendo la misma escena en conversaciones con equipos: el agente funciona en la laptop de alguien, el resultado impresiona, y esa misma configuración se empuja a la nube porque ya está lista. La velocidad de la demo se confunde con madurez del despliegue.

Este CVE no dice que ADK sea malo. ADK es una herramienta seria y el manejo del reporte fue correcto. Lo que dice es que la capa de herramientas de desarrollo del stack de agentes es hoy la parte menos auditada de todo lo que estamos poniendo en producción, y también la que más cambia de versión a versión.

Si tuviera que dejar una sola pregunta para tu próxima reunión técnica, sería esta: además del servicio que sí querías exponer, ¿qué otra cosa está escuchando en ese contenedor? En la mayoría de los equipos, la respuesta honesta es que nadie lo revisó desde el día que funcionó por primera vez.