Un investigador de seguridad afirma que **Microsoft** corrigió discretamente una vulnerabilidad de **Azure Backup** para AKS después de rechazar su informe y bloquear la emisión de una CVE. El informe del investigador describe una falla crítica de escalada de privilegios que permitía el acceso de administrador de clúster desde el rol de bajo privilegio "Backup Contributor". Microsoft disputa la afirmación, indicando a BleepingComputer que el comportamiento era el esperado y que "no se realizaron cambios en el producto", a pesar de que el investigador documentó nuevas verificaciones de permisos e intentos de exploit fallidos después de la divulgación, lo que sugiere un parche silencioso. ## CERT coincide en que es un error, pero Microsoft bloquea la CVE El investigador de seguridad **Justin O'Leary** descubrió la falla de seguridad en marzo y la reportó a **Microsoft** el 17 de marzo. El Centro de Respuesta de Seguridad de Microsoft (MSRC) rechazó el informe el 13 de abril, alegando que el problema solo implicaba obtener acceso de administrador de clúster en un clúster donde "el atacante ya tenía acceso de administrador", una caracterización que O'Leary dice que tergiversa completamente el ataque. "Esto es factualmente incorrecto", afirma el investigador. "La vulnerabilidad permite que un usuario sin permisos de Kubernetes obtenga acceso de administrador de clúster. El ataque no requiere acceso de clúster existente, lo otorga." O'Leary añade que Microsoft describió la presentación a **MITRE** como "contenido generado por IA", algo que, según él, no abordó los méritos técnicos del informe. Después del rechazo, O'Leary escaló el problema al **CERT Coordination Center**, que validó independientemente la vulnerabilidad el 16 de abril y, según el investigador, le asignó un identificador, VU#284781:  **CERT/CC** había programado inicialmente la divulgación pública para el 1 de junio de 2026, pero esa divulgación nunca ocurrió. El 4 de mayo, personal de Microsoft supuestamente contactó a **MITRE** recomendando no asignar una CVE, argumentando nuevamente que el problema requería acceso administrativo preexistente:  **CERT/CC** luego cerró el caso bajo las reglas de la jerarquía CNA, dejando efectivamente a **Microsoft** (que es una CNA) con la autoridad final sobre la emisión de CVE para sus propios productos. ## Cómo funcionaba el ataque **Azure Backup** para AKS utiliza Trusted Access para otorgar privilegios de administrador de clúster a las extensiones de copia de seguridad dentro de los clústeres de Kubernetes. Según O'Leary, la falla permitía a cualquier persona con solo el rol de Backup Contributor en un bóveda de copias de seguridad activar esa relación de Trusted Access sin tener permisos de Kubernetes preexistentes. Un atacante podría habilitar la copia de seguridad en un clúster AKS objetivo, lo que haría que Azure configurara automáticamente Trusted Access con privilegios de administrador de clúster. A partir de ahí, un atacante podría extraer secretos a través de operaciones de copia de seguridad o restaurar cargas de trabajo maliciosas en el clúster. O'Leary clasificó el problema como una vulnerabilidad de **Confused Deputy** (CWE-441), donde los límites de confianza de Azure RBAC y Kubernetes RBAC interactuaron de una manera que eludió los controles de autorización esperados. ## Microsoft dice que no se hicieron cambios, el comportamiento dice lo contrario BleepingComputer se comunicó con Microsoft para comprender si el gigante tecnológico consideraba que este hallazgo era una vulnerabilidad de seguridad válida. Un portavoz de Microsoft dijo a BleepingComputer: "Nuestra evaluación concluyó que esto no es una vulnerabilidad de seguridad, sino un comportamiento esperado que requiere privilegios administrativos preexistentes dentro del entorno del cliente. Por lo tanto, no se realizaron cambios en el producto para abordar este informe y no se emitieron CVE ni puntuación CVSS." Sin embargo, tras la divulgación de su informe este mes, O'Leary observó que la ruta de ataque original ya no funciona. "El comportamiento actual devuelve errores que no existían en marzo de 2026", afirma: ERROR: UserErrorTrustedAccessGatewayReturnedForbidden "La vinculación de roles de Trusted Access falta/ha sido eliminada" Según O'Leary, **Azure Backup** para AKS ahora requiere que Trusted Access se configure manualmente antes de que se pueda habilitar la copia de seguridad, revirtiendo el comportamiento anterior donde Azure lo configuraba automáticamente. También observó verificaciones de permisos adicionales que no estaban presentes durante sus pruebas originales en marzo. El MSI de la bóveda ahora requiere permisos de Lector tanto en el clúster AKS como en el grupo de recursos de instantáneas, mientras que el MSI del clúster AKS requiere permisos de Colaborador en el grupo de recursos de instantáneas. En otras palabras, la vulnerabilidad parece haber sido corregida, pero **Microsoft** no ha emitido un aviso público ni ha notificado a los clientes. ## El problema de visibilidad para los defensores Sin una CVE o un aviso, los defensores tienen poca visibilidad sobre la ventana de exposición o el cronograma de remediación. "Las organizaciones que otorgaron Backup Contributor entre una fecha de inicio desconocida y mayo de 2026 estuvieron expuestas a escalada de privilegios", escribe el investigador. "Sin una CVE, los equipos de seguridad no pueden rastrear esta exposición. Los parches silenciosos protegen a los proveedores, no a los clientes." El caso destaca un problema estructural sin una solución fácil. Las disputas entre investigadores de seguridad y grandes proveedores sobre la gravedad, la explotabilidad y la divulgación se han vuelto comunes en los últimos años, especialmente a medida que los programas de divulgación de vulnerabilidades enfrentan volúmenes crecientes de informes. Algunos mantenedores de código abierto también se han quejado públicamente de que los informes asistidos por IA están abrumando los sistemas de recompensas por errores y triaje de seguridad, lo que dificulta que los hallazgos legítimos reciban atención oportuna. Los casos en los que las grandes tecnológicas ignoraron parchar fallas válidas a pesar del contacto repetido por parte de diferentes investigadores tampoco son infrecuentes. Sin un marco que realinee los incentivos para todas las partes, la divulgación responsable corre el riesgo de convertirse en un ejercicio burocrático que no beneficia a nadie, y mucho menos a las organizaciones que quedan expuestas en la oscuridad.  ## La brecha de validación: las pruebas de penetración automatizadas responden una pregunta. Necesitas seis. Las herramientas de pruebas de penetración automatizadas brindan un valor real, pero fueron diseñadas para responder una pregunta: ¿puede un atacante moverse por la red? No fueron diseñadas para probar si tus controles bloquean amenazas, si tus reglas de detección se activan o si tus configuraciones en la nube se mantienen. Esta guía cubre las 6 superficies que realmente necesitas validar. [Descargar ahora](https://hubs.li/Q048zztN0)