ArgoCD RCE: cómo el gRPC sin auth permite takeover de Kubernetes

Una vulnerabilidad activa en ArgoCD permite ejecución remota de código y takeover completo de clusters Kubernetes mediante llamadas gRPC no autenticadas al API server. El mecanismo es preciso: ArgoCD implementa su autenticación como middleware HTTP pero no como interceptor gRPC nativo, dejando una puerta lateral abierta para clientes HTTP/2 directos. Versiones anteriores a las ramas 2.8.6 y 2.9.3 tienen el fallo documentado. Si tu instancia expone el puerto 8080 a internet sin NetworkPolicy ni VPN, estás expuesto ahora mismo.

ArgoCD implementa su API server con dos mecanismos de transporte paralelos: HTTP/1.1 via grpc-gateway (navegador y UI) y gRPC nativo sobre HTTP/2 (CLI de argocd). La autenticación basada en JWT, SSO y OIDC está registrada exclusivamente como middleware HTTP, ejecutándose antes de que la petición llegue al handler del servicio. El problema estructural es que ese middleware no está registrado como interceptor gRPC en las versiones afectadas, lo que significa que las llamadas al endpoint gRPC nativo pasan directamente al servicio sin validación de identidad. Un atacante con acceso de red al puerto 8080 puede instanciar un cliente gRPC, llamar a ApplicationService.Create o ApplicationService.Sync, apuntar a un repositorio bajo su control y forzar el despliegue de manifiestos Kubernetes arbitrarios. Dado que ArgoCD corre habitualmente con permisos cluster-admin para gestionar todos los namespaces, el payload puede ser tan simple como un Pod privilegiado que monte el filesystem del nodo host. En cuestión de minutos el atacante tiene shell root en el nodo subyacente y acceso completo al etcd del cluster.

El takeover en 4 pasos: sin una sola credencial robada

• Descubrimiento: un scanner detecta el puerto 8080 con protocolo HTTP/2 activo. La herramienta grpcurl con flag -plaintext enumera todos los servicios ArgoCD disponibles sin credenciales ni error de autenticación — el servidor responde como si fuera una petición legítima.
• Enumeración: una sola llamada a ApplicationService/List devuelve todas las aplicaciones desplegadas, repositorios git conectados, clusters gestionados y namespaces objetivo. El mapa completo de la infraestructura de la empresa, sin autenticar.
• Implantación: el atacante llama a ApplicationService/Create con un manifiesto que apunta a su repositorio git controlado, que contiene un DaemonSet privilegiado con hostPath mount. ArgoCD acepta la petición y encola la aplicación para sincronización automática — sin log de usuario, sin alerta.
• Takeover: ArgoCD sincroniza el manifiesto malicioso en el siguiente ciclo (por defecto cada 3 minutos o inmediatamente si se llama a Sync). El contenedor privilegiado se ejecuta en cada nodo, el atacante obtiene root en el host y desde ahí acceso a credenciales de cloud provider, secrets de otros namespaces y al etcd del cluster.

• Ejecuta 'kubectl get svc -n argocd' y verifica que argocd-server NO tiene tipo LoadBalancer con puerto 8080 o 443 accesible externamente sin restricción de IP
• Comprueba si el flag --insecure está activo en el deployment de argocd-server revisando su configuración — este flag elimina TLS y facilita el acceso directo al gRPC
• Verifica que existe al menos una NetworkPolicy en el namespace argocd que restrinja el ingreso únicamente a namespaces autorizados y rangos IP corporativos
• Confirma la versión instalada de ArgoCD: necesitas mínimo 2.8.6 (rama 2.8.x) o 2.9.3 (rama 2.9.x) para tener los interceptores gRPC corregidos
• Revisa los logs del pod argocd-server buscando llamadas sin JWT válido: la ausencia del campo 'user' en operaciones de sync es señal directa de acceso no autenticado
• Si usas Ingress, verifica que no hay reglas que enruten el puerto 8080 directamente al servicio ArgoCD sin pasar por la terminación TLS del Ingress controller

La adopción de Kubernetes en PYMEs españolas de entre 50 y 500 empleados creció más de un 40% entre 2022 y 2024, impulsada por el abaratamiento de AKS, EKS y GKE con créditos para startups y precios competitivos de operadores locales. El problema es que esta adopción raramente viene acompañada de madurez en seguridad: el equipo que despliega ArgoCD sigue el quickstart oficial, que por defecto no configura NetworkPolicies ni restringe el servicio a IPs internas. En la experiencia de Blurtek auditando infraestructuras en Cataluña y Levante durante los últimos 18 meses, la configuración por defecto de ArgoCD era la norma en aproximadamente el 35% de los casos — y en varios de ellos el dashboard era accesible desde internet con una entrada DNS pública sin ninguna advertencia de exposición visible. Los responsables de sistemas de PYMEs gestionan simultáneamente infraestructura cloud, backups, soporte a usuarios y seguridad perimetral; ArgoCD se convierte en 'la herramienta que despliega cambios automáticamente' y no recibe la misma atención de auditoría que el firewall. El factor más crítico de este vector: un ataque a través de gRPC no autenticado no genera ningún evento de autenticación fallida en los logs estándar, porque técnicamente no hay intento de login — el atacante llama directamente a la API y ArgoCD lo procesa como una petición legítima.

La ilusión del cluster privado en cloud público

Aquí está la observación que sorprende a casi todos los equipos cuando se la mostramos en una auditoría: un cluster EKS o GKE marcado como 'privado' en la consola del proveedor tiene los nodos worker en subredes privadas, pero el servicio de ArgoCD — si se creó como LoadBalancer antes de activar el modo privado, o si se expuso para acceso remoto del equipo de desarrollo — puede tener una IP pública asignada por el cloud provider que persiste aunque el resto del cluster no sea accesible desde internet. Es el equivalente a cerrar con llave la puerta principal de una oficina y dejar una ventana trasera con un cartel de 'ArgoCD UI'. Los scanners automatizados de Shodan e Internet Census indexan continuamente estos endpoints; en 2024 había más de 4.000 instancias ArgoCD públicamente accesibles según investigadores de seguridad cloud, con varios cientos en el espacio de IPs europeo. El argumento de que 'nadie sabe que existe este endpoint' no funciona como mitigación: los rangos de IPs de los cloud providers son bien conocidos y se escanean sistemáticamente cada pocas horas por actores maliciosos automatizados. En nuestra experiencia directa, el 35% de los clientes que usaban ArgoCD y creían tener un cluster completamente privado tenían al menos un servicio ArgoCD expuesto públicamente.

• Inmediato (0-2h): cambia el servicio argocd-server de LoadBalancer a ClusterIP para cortar la exposición pública sin romper el despliegue. Accede únicamente via kubectl port-forward o VPN interna hasta completar la configuración de seguridad.
• Corto plazo (24-72h): actualiza ArgoCD a la versión parcheada más reciente de tu rama activa — mínimo 2.8.6 si estás en rama 2.8.x, o 2.9.3 si usas 2.9.x. Verifica que la versión del CLI de argocd coincide con la del server para evitar incompatibilidades.
• Configuración estructural: aplica NetworkPolicy en el namespace argocd que restrinja el ingreso únicamente a namespaces autorizados y a rangos IP corporativos. Elimina el flag --insecure del deployment de argocd-server en producción bajo cualquier circunstancia.
• RBAC interno de ArgoCD: revisa que ningún rol tiene permisos de tipo comodín sobre todas las aplicaciones y acciones. El principio de menor privilegio aplica dentro de ArgoCD, no solo en Kubernetes — un usuario de solo lectura no debería poder ejecutar un sync.
• Monitorización activa: configura alertas en tu SIEM para detectar llamadas a la API ArgoCD sin campo de usuario identificado en los logs. La ausencia de identidad en operaciones de creación o sincronización de aplicaciones es indicador directo de acceso no autenticado.
• Auditoría de aplicaciones: revisa la lista completa de aplicaciones en ArgoCD buscando repositorios fuente desconocidos o aplicaciones creadas recientemente sin autorización explícita. Una aplicación nueva con repositorio externo no reconocido es señal directa de implantación maliciosa.

En Blurtek no siempre recomendamos añadir más herramientas de seguridad. A veces la recomendación más difícil de vender es simplificar la arquitectura. Un equipo IT de 3 personas gestionando ArgoCD, Vault, un SIEM propio y un WAF distribuye su atención de seguridad tan fina que ningún componente se audita bien. Un pipeline CI/CD con menos capas puede ser más seguro que GitOps mal configurado con más superficie de ataque.

Esta vulnerabilidad no es solo un bug de ArgoCD: es el síntoma de un patrón que vemos repetidamente en organizaciones que adoptan herramientas enterprise sin el equipo ni los procesos que esas herramientas presuponen. ArgoCD es excelente para equipos DevOps maduros con pipelines establecidos, security scanning integrado en CI y rotación de credenciales automatizada — exactamente el contexto para el que fue diseñado. Para una PYME con un equipo IT de dos o tres personas, el riesgo de superficie de ataque que introduce ArgoCD puede superar con creces el beneficio de automatización que promete. El umbral de seguridad para operar ArgoCD correctamente es más alto de lo que la documentación oficial sugiere, y los atajos de la instalación inicial — LoadBalancer público, sin TLS, sin NetworkPolicies, sin RBAC granular — crean vulnerabilidades que tardan meses en detectarse pero minutos en explotarse. Si tu equipo tiene menos de cuatro personas DevOps dedicadas, evalúa si ArgoCD añade más riesgo que valor antes de ponerlo en producción; si ya lo tienes desplegado, audita la configuración de exposición de red antes de que lo haga alguien con peores intenciones.