Vulnerabilidad en Argo CD Repo-Server Puede Comprometer Clusters de Kubernetes
Publicado el
Vulnerabilidad en Argo CD Repo-Server
Argo CD, una herramienta ampliamente utilizada para implementar software en Kubernetes, presenta una vulnerabilidad no corregida en su componente repo-server. Esta falla permite a un atacante no autenticado ejecutar código, siempre que tenga acceso al puerto de red interno del componente.
El descubrimiento de este bug fue realizado por Synacktiv, que advirtió que podría conducir a la toma completa del cluster. A pesar de que la vulnerabilidad se reportó a los responsables de Argo CD en enero de 2025, dieciocho meses después sigue sin ser solucionada. Synacktiv decidió hacer públicos los detalles para advertir a los usuarios.
La vulnerabilidad se encuentra en el repo-server, el componente que lee repositorios Git y genera manifiestos de Kubernetes, los archivos que definen lo que se despliega en el cluster. Su servicio gRPC interno carece de autenticación, lo que permite que cualquiera que logre acceder a él envíe una solicitud manipulada para ejecutar un comando.
Método de Ataque
Synacktiv demostró cómo llevar a cabo el ataque contra Argo CD v2.13.3, señalando que no existe una versión corregida y no se publicó una lista completa de las versiones afectadas. La técnica empleada explota kustomize, una herramienta estándar utilizada por Argo CD para convertir archivos de repositorio en manifiestos. Kustomize tiene una opción --helm-command que apunta al binario de helm que debe invocar. Al enviar una solicitud no autenticada al servicio GenerateManifest del repo-server, un atacante puede modificar esa opción para que apunte a un script diseñado por él, que se extrae de un repositorio Git controlado por el atacante.
Cuando kustomize se ejecuta, en lugar de invocar helm, ejecuta el script malicioso. Sin embargo, el término "interno" no implica aislamiento por defecto. Argo CD incluye políticas de red de Kubernetes que aíslan el repo-server de otros componentes, pero Synacktiv descubrió que el Helm chart utilizado para instalar Argo CD no activa estas políticas por defecto, dejando la opción `networkPolicy.create` configurada como falsa. Esto significa que un atacante que comprometa un único pod en el cluster puede alcanzar el repo-server y activar la vulnerabilidad.
Consecuencias del Ataque
El acceso al repo-server permite al atacante ejecutar código, pero eso no es todo. Synacktiv utilizó ese acceso para leer la contraseña de Redis del cluster desde una variable de entorno, conectarse a la caché de Redis de Argo CD y modificar los datos de despliegue almacenados. Durante la siguiente sincronización automática, Argo CD despliega una carga de trabajo proporcionada por el atacante.
Este escenario recuerda la vulnerabilidad CVE-2024-31989, identificada por Cycode, donde Redis no contaba con contraseña, lo que permitía que cualquier pod en el cluster pudiera envenenar la caché de despliegue. Aunque Argo CD solucionó este problema añadiendo una contraseña para Redis, la caché en sí misma sigue sin estar firmada, lo que reabre la misma vía de ataque si se roba la contraseña nuevamente.
Medidas de Protección
Dado que no existe una versión corregida, la única defensa viable es el aislamiento de redes. Es crucial activar las políticas de red de Kubernetes para que solo los componentes propios de Argo CD puedan acceder a los puertos del repo-server y Redis. Argo CD proporciona los archivos de política necesarios; los usuarios de Helm deben habilitarlas manualmente, ya que el chart las desactiva por defecto.
Para comprobar qué políticas están activas, se puede utilizar el comando: `kubectl get networkpolicy -A`. Una instalación correcta mostrará una política de red por cada componente, incluyendo el repo-server y Redis. Si estas políticas están ausentes, los puertos del repo-server y Redis serán accesibles desde el resto del cluster.
Synacktiv ha desarrollado una herramienta llamada argo-cdown que automatiza el ataque completo. Por el momento, han decidido no publicarla para dar tiempo a los defensores a asegurar sus políticas de red, pero planean lanzarla en GitHub más adelante para que los administradores puedan probar sus propias implementaciones.
Este no es el primer problema de seguridad que enfrenta Argo CD. En septiembre de 2025, se corrigió la vulnerabilidad CVE-2025-55190, donde un token API con acceso básico podía recuperar las credenciales del repositorio Git de un proyecto. En mayo de 2026, otra falla, CVE-2026-42880, permitía a usuarios con acceso solo de lectura leer secretos de Kubernetes en texto plano. El patrón es evidente: Argo CD concentra el acceso al cluster y los secretos del repositorio, y sus superficies internas continúan exponiéndolos, ya sea a través de solicitudes no autenticadas o mediante tokens de bajo privilegio.
Hasta que se publique un parche, tratar la red del cluster como un entorno hostil es la única defensa real que se puede implementar.