Un fallo sin parche en Argo CD Repo-Server podría exponer los clústeres de Kubernetes a una toma de control

Investigadores de seguridad afirman que una vulnerabilidad sin parche en el componente repo-server de Argo CD podría permitir a un atacante ejecutar código y obtener potencialmente el control de un clúster de Kubernetes, siempre que pueda acceder al servicio en la red interna.

Synacktiv identificó el problema y afirmó que lo comunicó a los responsables de Argo CD en enero de 2025. Tras esperar aproximadamente 18 meses sin que se publicara una solución ni se asignara un CVE, la empresa divulgó los hallazgos para alertar a los usuarios. Según su análisis, la debilidad afecta a la interfaz gRPC de repo-server, que no requiere autenticación.

Cómo funciona el ataque

Argo CD utiliza repo-server para obtener repositorios de Git y generar manifiestos de Kubernetes. Synacktiv descubrió que se puede elaborar una solicitud no autenticada al servicio GenerateManifest de forma que se indique a kustomize que invoque un script de un repositorio controlado por el atacante en lugar del binario de Helm esperado. Cuando el servicio procesa la solicitud, el script se ejecuta.

La exposición depende en gran medida de la posibilidad de acceso a la red. Argo CD ofrece políticas de red de Kubernetes destinadas a aislar repo-server y Redis del resto del clúster, pero Synacktiv señala que la instalación habitual basada en Helm deja estas protecciones desactivadas de forma predeterminada. En esa configuración, un pod comprometido en otra parte del clúster podría comunicarse con repo-server y activar el fallo.

Por qué el impacto es grave

Obtener la ejecución de código en repo-server puede ser suficiente para avanzar dentro del entorno. Synacktiv demostró que un atacante podría leer la contraseña de Redis desde el entorno del componente, conectarse a la caché Redis de Argo CD y modificar los datos de despliegue almacenados. En el siguiente ciclo de sincronización, Argo CD desplegaría contenido proporcionado por el atacante.

Los investigadores afirmaron que esto también reabre el patrón de riesgo asociado a CVE-2024-31989, un problema anterior en el que unas protecciones débiles de Redis permitían a un pod envenenar el estado del despliegue. Aunque Argo CD añadió posteriormente una contraseña para Redis, los datos de la caché no están firmados criptográficamente, por lo que los secretos expuestos desde el servicio en ejecución aún pueden utilizarse de forma indebida.

Qué deben hacer los administradores

• Activar las políticas de red de Kubernetes para los componentes de Argo CD, especialmente repo-server y Redis.
• Verificar las protecciones con kubectl get networkpolicy -A.
• Confirmar que las políticas previstas están presentes en todos los espacios de nombres utilizados por Argo CD.

Synacktiv afirmó que ha creado una herramienta de ataque llamada argo-cdown, pero está retrasando su publicación para dar tiempo a los defensores a proteger sus despliegues. Hasta que haya un parche disponible, la empresa recomienda tratar la red del clúster como no confiable y restringir el acceso tanto como sea posible.