Un investigador de seguridad afirma que Microsoft corrigió silenciosamente una vulnerabilidad en Azure Backup para AKS después de rechazar su informe y bloquear la asignación de un CVE. La falla descrita es una escalada de privilegios crítica que permitía obtener acceso cluster-admin desde el rol de 'Backup Contributor'. Microsoft niega la validez del hallazgo, pero el investigador documenta cambios en el comportamiento del sistema tras la notificación.
CERT/CC abre caso, pero Microsoft bloquea el CVE
El investigador Justin O'Leary descubrió la falla en marzo de 2026 y la reportó a Microsoft el 17 de marzo. El MSRC rechazó el informe el 13 de abril, argumentando que el ataque requería acceso administrativo previo. O'Leary afirma que esto es incorrecto: la vulnerabilidad permite a un usuario sin permisos en Kubernetes obtener cluster-admin. Tras el rechazo, O'Leary escaló el caso a CERT/CC, que asignó el identificador VU#284781 el 16 de abril. Posteriormente, Microsoft contactó a MITRE para evitar la asignación de un CVE, y CERT/CC cerró el caso bajo las reglas de jerarquía CNA, dejando a Microsoft como autoridad final.
Cómo funcionaba el ataque
Azure Backup para AKS utiliza Trusted Access para otorgar privilegios de cluster-admin a las extensiones de respaldo. O'Leary descubrió que un atacante con solo el rol de Backup Contributor en un vault podía activar esa relación Trusted Access sin tener permisos previos en Kubernetes. Al habilitar la copia de seguridad en un clúster AKS objetivo, Azure configurada automáticamente Trusted Access con privilegios elevados, permitiendo extraer secretos o restaurar cargas de trabajo maliciosas. El investigador clasificó el problema como vulnerabilidad de 'Confused Deputy' (CWE-441).
Microsoft dice que no hubo cambios, pero el comportamiento indica lo contrario
Un portavoz de Microsoft declaró a BleepingComputer: 'Nuestra evaluación concluyó que esto no es una vulnerabilidad de seguridad, sino un comportamiento esperado que requiere privilegios administrativos preexistentes. Por lo tanto, no se realizaron cambios en el producto y no se emitió ningún CVE'. Sin embargo, O'Leary observó que la ruta de ataque original ya no funciona: Azure Backup para AKS ahora requiere que Trusted Access se configure manualmente antes de habilitar la copia de seguridad, y se agregaron comprobaciones de permisos adicionales que no existían en marzo. El investigador afirma que la vulnerabilidad parece haber sido corregida, sin aviso público ni notificación a los clientes.
El problema de visibilidad para los defensores
Sin un CVE ni un aviso, los equipos de seguridad tienen poca visibilidad sobre la ventana de exposición o el cronograma de remediación. O'Leary señala que las organizaciones que otorgaron el rol de Backup Contributor entre una fecha desconocida y mayo de 2026 estuvieron expuestas a escalada de privilegios. 'Sin un CVE, los equipos de seguridad no pueden rastrear esta exposición. La corrección silenciosa protege a los vendedores, no a los clientes', concluye.
Este caso destaca un problema estructural en la divulgación responsable, donde los desacuerdos entre investigadores y grandes empresas sobre la gravedad y explotabilidad son cada vez más comunes. Sin un marco que realinee los incentivos, la divulgación responsable corre el riesgo de convertirse en un ejercicio burocrático que deja expuestas a las organizaciones.
