Microsoft 365 Copilot: una redirección abierta que difuminó la frontera entre inquilinos
Microsoft divulgó a principios de julio de 2026 un fallo crítico de elevación de privilegios en 365 Copilot. Una redirección abierta permitía a un atacante autenticado cruzar la frontera de confianza que aísla los datos de un inquilino de los de otro.
¿De qué se trata?
El 2 de julio de 2026, Microsoft publicó un aviso de seguridad sobre una vulnerabilidad de elevación de privilegios en Microsoft 365 Copilot, clasificada como crítica. Se trata de una redirección abierta —una URL que se podía inducir a Copilot a tratar como confiable aunque apuntara a un destino no controlado— cuya consecuencia resulta inusual para esta clase de fallo: podía permitir que un atacante autenticado cruzara la frontera de confianza que se supone aísla los datos de un inquilino (tenant) de Microsoft 365 de los de otro. En el peor escenario descrito por Microsoft, una cuenta de bajos privilegios en una organización podía alcanzar archivos, correos o mensajes de Teams pertenecientes a una organización distinta que usara el mismo servicio Copilot. Microsoft corrigió el problema del lado del servicio, por lo que los clientes no tienen que instalar ningún parche. Aun así, el incidente ilustra cómo una debilidad web trivial se vuelve grave en cuanto un asistente LLM se sitúa en medio de una cadena de autorización.
Cómo funciona
Copilot no es un simple modelo que responde a una pregunta. Es una capa de orquestación que difunde la petición del usuario a través de Microsoft Graph, SharePoint Online, Exchange y Entra ID, recupera lo que el usuario está autorizado a ver y compone una respuesta. Cada una de esas recuperaciones debe autorizarse en nombre del usuario solicitante, en el momento de la consulta.
La vulnerabilidad residía en esa costura de orquestación. Una redirección abierta significaba que un enlace gestionado por el asistente podía enviarlo a un destino influenciado por el atacante mientras la petición conservaba la apariencia de un flujo interno y de confianza. Según el aviso público y los análisis posteriores, esto difuminó momentáneamente la distinción entre «datos de este inquilino» y «datos de aquel otro inquilino»: bajo ciertas condiciones, el motor de orquestación trataba contenidos de inquilinos distintos como si pertenecieran al mismo dominio de autoridad. Como Copilot registra sus recuperaciones como acciones de la aplicación y no del usuario, el origen real de una petición también podía quedar oculto, lo que hace que esta clase de fallo sea difícil de detectar a posteriori.
No hay código de explotación público, y no lo reproducimos. El mecanismo importa más que cualquier payload: cuando un asistente LLM dispone de un acceso de lectura amplio y entre servicios, y luego confía en una redirección que debería haber revalidado, el alcance del modelo se convierte en el alcance del atacante.
Por qué importa
Las redirecciones abiertas suelen catalogarse como «severidad baja». Lo que eleva el riesgo aquí es el radio de impacto del componente situado detrás de la redirección. Un copiloto capaz de razonar sobre todo el correo, los documentos y las conversaciones de un inquilino tiene, por diseño, una visión muy amplia de datos sensibles. Un único fallo en la autorización de una petición no filtra un archivo: puede exponer una porción arbitraria de un corpus y, en este caso, potencialmente el de una organización vecina. El aislamiento entre inquilinos es una de las promesas fundamentales del SaaS multiinquilino; una vía de elevación de privilegios que la atraviesa, aunque sea brevemente, es una preocupación de primer orden para cualquier entorno regulado.
La lección más amplia es arquitectónica. A medida que los asistentes se convierten en la interfaz por defecto hacia los datos corporativos, heredan y amplifican cada error de configuración y cada supuesto de confianza subyacente. Un sitio de SharePoint demasiado permisivo, hasta entonces un riesgo latente, se vuelve accesible en cuanto un copiloto lo hace aflorar en respuesta a una petición. Los equipos de seguridad deben tratar ahora a los asistentes de IA como aplicaciones de alto valor y altos privilegios, y modelarlos en consecuencia, incluyendo ejercicios de red team que prueben específicamente si una petición manipulada o un enlace gestionado puede cruzar una frontera entre inquilinos.
Defensas
La corrección del lado del servicio elimina esta vía concreta, pero la exposición que reveló es estructural y conviene endurecerla en todo caso.
- Restringir la identidad del asistente. Revise los permisos concedidos al principal de servicio de Copilot en Entra ID y elimine cualquier ámbito de Graph a escala de todo el inquilino que no necesite. Cuanto más estrecho sea el alcance de lectura del asistente, menor será el radio de impacto de un futuro desliz de autorización.
- Endurecer los datos subyacentes. Audite el uso compartido externo y los permisos de los sitios de SharePoint Online. Restrinja o desactive el uso compartido externo en los sitios con datos sensibles: un copiloto no puede filtrar lo que nunca tuvo derecho a indexar.
- Revisar la configuración de acceso entre inquilinos. En las identidades externas de Entra ID, examine las configuraciones entrantes y salientes y reduzca la confianza al mínimo que realmente requiera su colaboración B2B.
- Vigilar la actividad de Copilot como fuente de registros de primer nivel. En el portal de Microsoft 365 Defender, busque peticiones que devuelvan datos de fuentes inesperadas o accesos sin una justificación de negocio clara. Como las acciones se registran a nombre de la aplicación, céntrese en los patrones de recuperación anómalos y no solo en la atribución al usuario.
- Validar cada redirección y reautorizar en el momento de la recuperación. Para los equipos que construyen sus propios asistentes LLM: nunca deje que el modelo siga una redirección por confianza. Revalide el destino final y vuelva a comprobar la autorización en nombre del usuario en cada acceso a datos, no solo en la puerta de entrada.
- Modelar la amenaza del asistente, no solo del modelo. Añada «¿puede una petición o un enlace cruzar una frontera de inquilino o de privilegio?» a su plan de pruebas, y trate la capa de orquestación —no los pesos del LLM— como la principal superficie de ataque.
Estado
La vulnerabilidad fue divulgada y corregida por Microsoft a principios de julio de 2026. No se requiere ninguna acción del cliente para recibir la corrección, pero el endurecimiento de configuración anterior sigue siendo válido.
| Elemento | Detalle |
|---|---|
| Producto afectado | Microsoft 365 Copilot (orquestación en SharePoint Online, Exchange, Entra ID, Microsoft Graph) |
| Clase | Redirección abierta → elevación de privilegios entre inquilinos |
| Severidad del proveedor | Crítica |
| Requisito previo | Atacante autenticado con algún acceso existente al inquilino |
| Corrección | Aplicada del lado del servicio por Microsoft; sin parche del cliente |
| Referencia | CVE-2026-41106 (MSRC Security Update Guide) |
| Divulgación | ~2 de julio de 2026 |
Sources
- → https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-41106
- → https://windowsnews.ai/article/microsoft-flags-cve-2026-41106-copilot-privilege-escalation-could-cross-tenant-boundaries.433548
- → https://threat-modeling.com/vulnerability-intelligence-report-july-4-2026/
- → https://genai.owasp.org/llmrisk/llm01-prompt-injection/