18 meses sin parche: Cómo un vacío en Argo CD abre todo el clúster de Kubernetes

6 Min. de lectura

Desde hace 18 meses, el servidor de repositorios de Argo CD contiene una vulnerabilidad para la que, hasta hoy, no existe parche ni siquiera un número CVE. El servicio interno gRPC no verifica la identidad. Quien lo alcance dentro del clúster puede ejecutar comandos, envenenar la caché Redis y desplegar sus propias cargas de trabajo en el siguiente sincronizado. Basta con un único pod comprometido.

Lo más importante en resumen

• Sin parche, sin CVE: Synacktiv reportó el fallo a los mantenedores de Argo CD en enero de 2025 y publicó los detalles el 1 de julio de 2026. La corrección sigue sin llegar.
• El servidor de repositorios es la puerta de entrada: Su servicio gRPC funciona sin autenticación. Mediante una opción manipulada de Kustomize, un atacante ejecuta código sin autenticación.
• La defensa está en la red: Las NetworkPolicies de Kubernetes aíslan el servidor de repositorios y Redis. Argo CD incluye las reglas, pero en instalaciones con Helm están desactivadas por defecto.

Relacionado:Gobernanza de Kubernetes en entornos multicloud  /  Lo que puede truncar la actualización de Cilium en el clúster

Qué descubrió Synacktiv en el servidor de repositorios

El servidor de repositorios es el componente que permite a Argo CD realizar su trabajo principal. Lee los repositorios Git y construye a partir de ellos los manifiestos de Kubernetes listos para usar. Para que los demás módulos de Argo puedan comunicarse con él, ofrece un punto final interno gRPC. Este punto final no solicita ninguna identidad. Cualquier proceso que lo alcance a través de la red puede enviarle peticiones.

Aquí es donde actúa el ataque de los investigadores de seguridad de Synacktiv. Argo CD utiliza la herramienta estándar Kustomize para construir los manifiestos. Kustomize incluye una opción que permite establecer la ruta al binario de Helm. Mediante una petición manipulada, esta opción apunta a un comando arbitrario. El resultado es la ejecución de código sin autenticación en medio de la cadena de despliegue.

El ataque no termina en el servidor de repositorios. Los investigadores extrajeron la contraseña de Redis de una variable de entorno, se conectaron a la caché de Argo CD y manipularon los datos de despliegue almacenados allí. En la siguiente sincronización automática, Argo CD desplegó obedientemente la carga de trabajo inyectada. Así, un acceso de lectura a un servicio auxiliar se convierte en el control total del clúster.

Por qué una herramienta de despliegue se convierte en la clave del clúster

GitOps tiene los argumentos de su lado. El estado deseado se define en Git, un controlador lo compara continuamente con el clúster en ejecución. Es trazable, versionado y sin manipulaciones manuales con kubectl. El precio de esta comodidad rara vez aparece en el diagrama de arquitectura: quien controla la ruta de despliegue, controla todo lo que se ejecuta al final de esa ruta.

Argo CD decide qué contenedores pasan a producción. Almacena las credenciales de acceso que necesita para la sincronización. Por definición, tiene permisos de escritura en el clúster. Un atacante que se apodere de este mecanismo ya no necesita vulnerar una aplicación individual. Se escribe a sí mismo en el estado deseado y deja que el controlador haga el trabajo sucio.

Por eso los expertos, como en este caso, argumentan que la infraestructura GitOps debe tratarse como Tier-0. Es decir, con el mismo nivel de protección que el sistema de identidad o la autoridad de certificación. No como una simple herramienta de despliegue de segundo nivel, sino como lo que realmente es: la sala de control de la producción.

Cinco pasos para proteger el servidor de repositorios ahora mismo

Esperar un parche del fabricante no es una opción, porque no existe. La buena noticia: el ataque requiere acceso a la red del servidor de repositorios. Y es justo ahí donde se puede detener.

1. Activar NetworkPolicies. Argo CD incluye reglas predefinidas que solo permiten el acceso de sus propios componentes al servidor de repositorios y a Redis. En instalaciones con Helm, están desactivadas. Activarlas es el paso individual más efectivo.
2. Segmentar el servidor de repositorios y Redis. Ambos puertos deben estar en un segmento de red propio. Ningún otro pod del clúster tiene por qué acceder allí.
3. Revisar la exposición. Comprobar qué cargas de trabajo pueden alcanzar hoy el puerto gRPC. En configuraciones estándar de Helm, suele ser todo el clúster.
4. Cuestionar los valores predeterminados de los charts. El caso muestra un patrón: las opciones seguras están disponibles, pero desactivadas. Esto no solo aplica a Argo CD, sino a muchos charts de Helm.
5. Supervisar el comportamiento de sincronización. Los despliegues inesperados o los cambios en el estado deseado son la señal de alarma. Quien manipula la caché de Redis deja huellas en la sincronización.

Instalación estándar frente a configuración reforzada

La diferencia entre vulnerable y seguro no radica en un nuevo componente, sino en los valores predeterminados que hay que conocer y aplicar.

Qué deben aprender los administradores de este caso

La verdadera lección no está en Argo CD, sino en la suposición que hay detrás. Durante mucho tiempo, los servicios internos se consideraron de confianza por estar detrás del límite del clúster. El punto final gRPC sin autenticación es la consecuencia lógica de esta suposición. Esta ya no se sostiene en cuanto un solo pod del mismo segmento es comprometido.

Quien utilice GitOps debería tratar el centro de control como las puertas de la sala de servidores: segmentado, monitorizado y con reglas explícitamente establecidas en lugar de valores predeterminados heredados. El parche para esta vulnerabilidad aún no existe. El control sobre la propia red no le falta a quien lo asume.

Preguntas frecuentes

Fuente de la imagen de portada: generada por IA (julio de 2026)