Descripción
KEDA es un componente de escalado automático basado en eventos para Kubernetes. En la versión 2.20.2 y anteriores, un administrador de namespace que pueda crear recursos TriggerAuthentication y ScaledObject puede establecer hashiCorpVault.address en un endpoint controlado por el tenant y seleccionar la autenticación de Kubernetes sin una credencial explícita. KEDA utiliza entonces el token proyectado de ServiceAccount del pod del operador y lo envía a ese endpoint como credencial de inicio de sesión de Vault. El filtro de formato JWT de la corrección previa de CVE-2025-68476 acepta el token del operador porque su sujeto es una ServiceAccount de Kubernetes, por lo que el atacante puede obtener los permisos del operador a nivel de todo el clúster, incluidas lecturas amplias de Secrets y operaciones relacionadas con cargas de trabajo o admisión. Esta vulnerabilidad está corregida en la versión 2.21.0.
Qué hacer
Revisa si usas el producto afectado y en qué versión, y aplica la actualización o la mitigación que indique el aviso del fabricante. CISA no ha confirmado que se esté explotando; si eso cambia, esta ficha pasa a «explotada» y te avisamos en el boletín.
Versiones afectadas
- keda Afectadas: < 2.21.0
Según el registro de la vulnerabilidad en CVE.org, tal como lo publicó el fabricante. Confirma tu versión exacta en el aviso del fabricante.
Referencias
- Referencia en github.comgithub.com/kedacore/keda/security/advisories/GHSA-637c-6jxx-4rwm
- Referencia en github.comgithub.com/kedacore/keda/commit/1e21cc798dedd079e696cdb45388eddc5e183…
- Referencia en github.comgithub.com/kedacore/keda/releases/tag/v2.21.0
Ver el texto original en inglés (CVE.org)
KEDA: Privilege escalation from namespace admin to cluster admin via KEDA TriggerAuthentication
KEDA is a Kubernetes-based Event Driven Autoscaling component. In version 2.20.2 and earlier, a namespace administrator who can create TriggerAuthentication and ScaledObject resources can set hashiCorpVault.address to a tenant-controlled endpoint and select Kubernetes authentication without an explicit credential. KEDA then uses the operator pod's projected ServiceAccount token and sends it to that endpoint as a Vault login credential. The JWT-shape filter from the prior CVE-2025-68476 remediation accepts the operator token because its subject is a Kubernetes ServiceAccount, so the attacker can obtain the operator's cluster-wide permissions, including broad Secret reads and workload or admission-related operations. This vulnerability is fixed in 2.21.0.