La falla de autorización 9.9 del Azure SRE Agent podría haber permitido que un llamador heredara su identidad

CVE-2026-62830 es una vulnerabilidad de falta de autorización en Azure SRE Agent, el agente de Microsoft impulsado por IA para los equipos de confiabilidad de sitios de Azure, que clasifica incidentes, consulta telemetría y, cuando está configurado, ejecuta la remediación. Microsoft lo reveló en agosto de 2026 y le otorgó 9,9 sobre 10 — Crítica — según CVSS 3.1. Cualquier inquilino de Azure que ejecutara el agente estaba dentro del alcance del fallo; el archivo de incidentes no registra ninguna víctima confirmada ni ninguna explotación. La descripción de Microsoft sobre la vulnerabilidad es una sola frase: «La falta de autorización en Azure SRE Agent permite a un atacante autorizado elevar privilegios a través de una red». El servicio se corrigió del lado del servidor, y Microsoft afirma que los clientes no tenían nada que parchear. La entrada completa, con sus calificaciones de gravedad y confianza, se encuentra en el Orca AI Incident Archive junto con los incidentes vecinos de esta serie.

Lo que Microsoft publicó y lo que omitió

La entrada de la Guía de actualizaciones de seguridad de Microsoft para CVE-2026-62830 registra una elevación de privilegios en Azure SRE Agent, debilidad CWE-862 (Autorización faltante), una puntuación base de 9.9 y una puntuación temporal de 8.6. El vector — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — describe un ataque de red que requiere solo privilegios bajos, ninguna interacción del usuario y que produce un impacto alto en la confidencialidad, la integridad y la disponibilidad. Microsoft atribuye el hallazgo al investigador de seguridad wtm, de Offensi, en los agradecimientos del aviso.

Dos partes de ese vector explican lo esencial. La métrica de alcance es Changed (S:C), que la propia documentación de métricas de Microsoft define como un caso en el que el componente vulnerable y el componente afectado son diferentes y están gestionados por autoridades de seguridad distintas. Las métricas temporales son código de exploit no probado, corrección oficial y Confirmado, por lo que la puntuación temporal queda por debajo de la base.

El FAQ del aviso explica por qué existe un 9.9 sin enlace de descarga: "Esta vulnerabilidad ya ha sido completamente mitigada por Microsoft. No hay ninguna acción que los usuarios de este servicio deban tomar. El propósito de este CVE es proporcionar una mayor transparencia". Microsoft etiqueta el producto como un servicio exclusivamente alojado, y por eso la entrada no incluye número de compilación ni rango de versiones afectadas.

La tabla de explotabilidad es tan clara como las preguntas frecuentes. Divulgado públicamente: No. Explotado: No. Evaluación de explotación: Menos probable. Lo que el aviso no describe es el flujo on-behalf-of, la identidad administrada ni los runbooks. Tampoco ofrece un intervalo de versiones: el CPE es el producto sin versión, y la única versión afectada listada es un guion. Todo lo que un lector querría saber sobre el mecanismo tiene que venir de otro sitio, y ese otro sitio es, en su mayoría, la propia entrada del archivo.

Qué es el agente y por qué su identidad es lo que vale la pena alcanzar

Azure SRE Agent no es un chatbot acoplado a un panel de control. La documentación de Microsoft sobre Azure SRE Agent describe un agente que se conecta a recursos de Azure, herramientas de observabilidad, plataformas de incidentes y repositorios de código fuente, recopila señales, correlaciona implementaciones, propone mitigaciones y — según el modo de ejecución que establezca un cliente — las ejecuta. En el modo Review, un administrador aprueba las acciones de escritura; en el modo Autonomous, el agente las aplica sin esperar. Su alcance se amplía mediante skills y runbooks, operaciones de Azure CLI, agentes personalizados, herramientas de Python, conectores MCP y hooks de agente.

La misma documentación afirma el hecho que hace interesante el CVE: «El agente se autentica con identidad administrada y opera bajo el control de acceso basado en roles (RBAC) de Azure». Una identidad administrada es una identidad de Entra asignada a un servicio, y lo que puede hacer es exactamente lo que permiten sus asignaciones de roles. Por lo tanto, la autoridad del agente no es una propiedad de su código, sino de los roles asociados a esa identidad, que es el límite que una comprobación de autorización ausente no lograría proteger.

Un análisis técnico independiente, la entrada de HackTricks Cloud sobre la escalada de privilegios de Azure SRE Agent, describe la versión estructural de este problema sin citar CVE-2026-62830. Enumera operaciones del plano de control que permiten a un solicitante dirigir a un agente —abrir un hilo, aprobar una remediación propuesta, revincular la configuración del agente, redirigir un conector de datos— y enmarca el resultado como un confused deputy: el solicitante no necesita los permisos del agente, solo una forma de hacer que el agente los use. Esa entrada no se refiere a este CVE y no debe interpretarse como corroboración del mismo. Es útil por la misma razón que la puntuación: muestra dónde reside realmente la autoridad.

El mecanismo: lo que describe el archivo y lo que confirma el proveedor

La entrada del archivo describe el fallo como una falla en lo que denomina el flujo Scope-Changed OBO (on-behalf-of). Un flujo on-behalf-of es un intercambio de tokens en el que un servicio cambia la credencial de un llamador por un token que le permite llamar a un servicio descendente como ese llamador. Si la comprobación de autoridad en ese intercambio falla, según el archivo, la llamada descendente puede recurrir a la identidad administrada con ámbito de inquilino del propio agente en lugar de la identidad del llamador. Un llamador autenticado pero con pocos privilegios heredaría entonces los permisos del principal de servicio del agente y podría modificar runbooks, telemetría e infraestructura, no solo el agente, sino cada recurso de Azure sobre el que la identidad administrada tiene un rol.

Esa descripción es coherente con todo lo que Microsoft publicó, y no está en lo que Microsoft publicó. El texto del proveedor confirma tres piezas: faltaba la comprobación de autorización, el llamador solo necesita privilegios bajos y el impacto cruza un límite de autoridad de seguridad. No confirma el intercambio de tokens, la herencia de identidad ni los ejemplos de runbook y telemetría. La entrada del archivo es la fuente de esos puntos, y el archivo es un conjunto de datos secundario, no el proveedor.

Una búsqueda de reportajes independientes da con el mismo párrafo en más de un lugar: el titular sobre el flujo OBO y el radio de impacto aparece sindicado en forkast.news y en Yahoo Tech, entre otros. La sindicación hace que esa cobertura sea una sola fuente, no varias. Ningún medio revisado para este artículo publicó su propia telemetría, prueba de concepto o reproducción del mecanismo.

Lo que está establecido, lo que se describe y lo que nunca se afirmó.

El archivo califica este registro como A — bien documentado, las fuentes primarias coinciden — y no lo marca como disputado. No registra ningún daño en el mundo real. Esa calificación se refiere a los hechos centrales del registro, y estos sí coinciden entre las fuentes; no implica que cada frase de la entrada haya sido reproducida de forma independiente.

• Establecido por el proveedor. CVE-2026-62830 afecta a Azure SRE Agent, es CWE-862, falta de autorización, tiene una puntuación base CVSS 3.1 de 9.9 y una puntuación temporal de 8.6, no requirió ninguna acción por parte del cliente, no se divulgó públicamente y no se ha registrado como explotada.

• Establecido por informes y enriquecimiento de seguridad independientes.El resumen de Patch Tuesday de agosto de 2026 de Cisco Talos enumera la CVE con la misma puntuación de 9.9 y la misma debilidad por falta de autorización, y la sitúa bajo la evaluación de explotación "menos probable" de Microsoft. La evaluación SSVC de CISA, registrada a través de NVD, califica la explotación como ninguna, la automatización como no y el impacto técnico como total. El enriquecimiento de OpenCVE incluye una puntuación EPSS de 0.00778 y registra que la CVE no está en el catálogo Known Exploited Vulnerabilities de CISA.

• Descrito, no confirmado de forma independiente. El fallo de intercambio de tokens OBO, la herencia de la identidad administrada del agente y las consecuencias para el runbook, la telemetría y la infraestructura provienen de la entrada del archivo y de la cobertura secundaria sindicada. El aviso de Microsoft no los menciona. Son la parte más útil del registro y la menos documentada de él.

• No se ha establecido en ninguna parte. No hay explotación, ni víctima, ni prueba de concepto pública, ni número de compilación, ni intervalo de versiones afectadas. La línea de explotabilidad de Microsoft — divulgada públicamente: No, explotada: No, menos probable — es lo más parecido a un informe de estado que existe.

• No hay cobertura en medios generalistas. Las búsquedas de este CVE en la prensa generalista de tecnología y seguridad no arrojaron ningún artículo de The Register, BleepingComputer, SecurityWeek ni Help Net Security. Su huella pública está compuesta por el aviso del proveedor, bases de datos de vulnerabilidades, un resumen de Patch Tuesday y la pieza sindicada. Para un 9.9, eso es inusual, y es un hecho sobre el registro, no un juicio sobre el riesgo.

La corrección, y las comprobaciones que le sobreviven

Como Azure SRE Agent es un servicio hospedado, la corrección se aplicó del lado de Microsoft. No hay ninguna actualización que instalar, ningún número de compilación que comparar con un inventario y ninguna forma de que un cliente confirme desde fuera que un inquilino estuvo protegido antes de una fecha determinada. La postura de Microsoft es que no se requiere ninguna acción y, en lo que respecta a la vulnerabilidad en sí, esa postura es correcta.

La entrada del archivo añade orientación que el aviso no especifica: auditar las asignaciones de identidad administrada, revisar RBAC según lo que el agente realmente necesita y monitorear en busca de una escalada de privilegios anómala. Esa orientación es del archivo, no una cita de Microsoft.

La consecuencia práctica se deriva de la arquitectura y no de la recomendación de ninguna fuente, por lo que debe considerarse una inferencia. Si la autoridad del agente son sus asignaciones de roles, entonces los controles duraderos son el alcance de esas asignaciones y la retención de los registros del plano de control que mostrarían su uso. Una corrección del lado del servicio cierra la ruta; no reduce retroactivamente una identidad administrada que se aprovisionó en exceso, y no puede ayudar a una organización que no conservó los registros. Ambas son responsabilidades que el cliente sigue teniendo una vez cerrada la CVE.

Dónde queda dentro del lote de agosto de 2026

El resumen de Talos hace inevitable la comparación. Ese mes también incluye CVE-2026-59118 en Copilot Cowork, una elevación de privilegios mediante autorización indebida con una puntuación de 9.3, y CVE-2026-56162 en Azure SQL Database, una elevación de privilegios con una puntuación de 10.0. La única vulnerabilidad que Talos informa como explotada en la naturaleza ese mes no era ninguna de estas: era CVE-2026-68820, en Windows AFD para WinSock. Las entradas de productos de IA en la lista de Talos son errores de autorización, y esa es la forma específica del riesgo que documenta este registro.

Nada de eso convierte CVE-2026-62830 en una vulneración. Es un CVE de transparencia para un servicio que ya estaba corregido, publicado para que los clientes puedan ver qué estaba mal y comprobar sus propias configuraciones. El valor del registro es la cuestión de configuración que deja tras de sí —aquello a lo que podía llegar la identidad del agente, y si alguien habría notado que se estaba utilizando—, no un parche que programar.