Principales resultados
- Al probar 104 aplicaciones, Semperis encontró 9 (o aproximadamente el 9%) que eran vulnerables al abuso de nOAuth.
- Como ya se ha revelado el abuso, la capacidad de realizar nOAuth es de baja complejidad.
- El abuso de nOAuth explota las vulnerabilidades entre inquilinos y puede conducir a la exfiltración de datos de aplicaciones SaaS, persistencia y movimiento lateral.
- Los clientes de aplicaciones vulnerables tienen dificultades para detectar estos abusos y les resulta imposible defenderse de ellos.
- Los investigadores de Semperis califican esta vulnerabilidad como potencialmente SEVERA debido a la escasa complejidad del ataque y a la dificultad de su detección y defensa.
La vulnerabilidad nOAuth expone un fallo crítico de autenticación en aplicaciones vulnerables de software como servicio (SaaS). Con sólo acceder a un inquilino Entra -una barrera baja- y a la dirección de correo electrónico del usuario objetivo, un atacante puede hacerse con la cuenta de ese usuario en la aplicación vulnerable. A partir de ahí, el atacante puede acceder a todos los datos a los que el objetivo tiene acceso dentro de esa aplicación.
En diciembre de 2024 informamos rápidamente de nuestros hallazgos a los proveedores de aplicaciones y al Centro de Respuesta de Seguridad de Microsoft (MSRC); el MSRC acusó recibo del informe y abrió el caso 93209. En marzo de 2025, notificamos al MSRC nuestra intención de revelarlo. El MSRC cerró el caso en abril de 2025. Durante mayo y junio de 2025, seguimos poniéndonos en contacto con los proveedores de aplicaciones que eran vulnerables y compartimos los detalles con el MSRC. En junio de 2025, recibimos respuesta del MSRC reiterando que los proveedores debían seguir las recomendaciones, y que los que no lo hicieran podrían ser eliminados de Entra App Gallery.
Detectar un ataque que abuse de nOAuth es difícil o imposible. No hay opciones de remediación o mitigación disponibles para los clientes, aparte de pedir a los vendedores de aplicaciones actualizaciones para hacer que las aplicaciones sean invulnerables al abuso de nOAuth. Debido a la simplicidad de este abuso, la complejidad de la detección y la existencia de aplicaciones activamente vulnerables, Semperis considera que esta vulnerabilidad es un riesgo grave para los clientes de Entra ID.
Este artículo detalla la exploración de nOAuth por parte del equipo de investigación de seguridad de Semperis, centrada en las aplicaciones de Microsoft Entra App Gallery. Descubrimos nueve aplicaciones vulnerables, incluidas las que podrían contener información de identificación personal (PII).
¿Qué es nOAuth?
El 20 de junio de 2023, Omer Cohen, de Descope, publicó la divulgación "nOAuth: How Microsoft OAuth Misconfiguration Can Lead to Full Account Takeover". El problema fundamental que conduce a nOAuth es el uso por parte de los desarrolladores de aplicaciones de antipatrones relativos a la implementación de OpenID Connect (OIDC). Estos anti-patrones incluyen el uso de atributos mutables, como una dirección de correo electrónico, para los identificadores de usuario. Dado que Entra ID permite a los usuarios tener una dirección de correo electrónico no verificada, el uso de este atributo permite la suplantación de identidad del usuario a través de los límites del arrendatario. En la revelación de Descope, describen que el ataque se sitúa en una "zona gris" en Entra ID, debido a la dependencia de los desarrolladores que siguen anti-patrones. Aunque estamos de acuerdo con esto, deja a los clientes mutuos de Microsoft y el proveedor de aplicaciones SaaS (ISV) vulnerables a este abuso.
En respuesta al descubrimiento de Cohen, MSRC publicó un artículo sobre los riesgos de nOAuth: "Riesgo potencial de escalada de privilegios en aplicaciones Azure AD". Como parte de la declaración de impacto en el cliente de Microsoft, este artículo afirmaba:
Microsoft ha identificado varias aplicaciones multiarrendamiento con usuarios que utilizan una dirección de correo electrónico con un propietario de dominio no verificado. Aunque las direcciones de correo electrónico no verificadas no suponen un riesgo para las aplicaciones que no utilizan reclamaciones de correo electrónico con fines de autorización, se ha notificado a los propietarios de estas aplicaciones y se les ha proporcionado orientación sobre cómo modificar sus aplicaciones, si procede. Si no ha recibido una notificación, su aplicación no ha consumido reclamaciones de correo electrónico con propietarios de dominios no verificados. Para proteger a los clientes y las aplicaciones que pueden ser vulnerables a la escalada de privilegios, Microsoft ha implementado mitigaciones para omitir las reclamaciones de token de propietarios de dominio no verificados para la mayoría de las aplicaciones.
Declaración de impacto en el cliente de Microsoft
Microsoft también publicó orientaciones específicas sobre cómo dejar de utilizar las reclamaciones por correo electrónico. En el momento de redactar este artículo, la guía ya no está disponible en el sitio web de Microsoft, aunque puede encontrar una versión archivada en otro lugar.
¿Cómo funciona el abuso de nOAuth?
El abuso de nOAuth requiere tres componentes:
- Posibilidad de establecer una dirección de correo electrónico no verificada en Entra ID.
- Un registro de App que permite la solicitud de correo electrónico no verificado
- Vulnerabilidad de una aplicación a esta combinación
Veamos un ejemplo de este tipo de abuso.
Configuración de una dirección de correo electrónico no verificada en Entra ID
Entra ID y los servicios de Microsoft 365 incluyen un inquilino predeterminado con un nombre de dominio onmicrosoft .com, como contoso.onmicrosoft.com. A medida que las organizaciones configuran sus despliegues e incorporan sus propios nombres de dominio para los servicios, el proceso de verificación utiliza un registro TXT o MX para verificar la propiedad del dominio. Una vez verificado, el nombre de dominio se marca como tal en Entra ID(Figura 1).
Para soportar la funcionalidad de usuario invitado en Entra ID, sin embargo, el sufijo de dominio del atributo de correo electrónico no necesita ser un dominio verificado. Por lo tanto, cualquier usuario en cualquier inquilino Entra puede tener cualquier dirección de correo electrónico en el atributo de correo.
Por ejemplo, la Figura 2 muestra un usuario, Adele Vance, cuyo atributo mail tiene el mismo valor que el atributo userPrincipalName.
Podemos ejecutar un simple PATCH para cambiar este atributo de correo(Figura 3).
Otro GET muestra que Adele tiene ahora una dirección de correo electrónico para un dominio que no está verificado dentro de este inquilino(Figura 4).
Verificar un cambio de dirección de correo electrónico
Si queremos validar la dirección de correo electrónico no verificada como un reclamo en un token de ID, podemos configurar un registro de aplicación en Entra ID con un Redirect URI de https://jwt.ms y pasarle el token de ID.
Para los registros de aplicaciones creados después de junio de 2023, por defecto Entra ID no emite la declaración de correo electrónico no verificado. Para modificar la configuración para permitir esto, podemos usar un simple PATCH en el authenticationBehavior para el registro de la aplicación, estableciendo removeUnverifiedEmailClaim en false (Figura 5). Este proceso está documentado por Microsoft en el artículo "Manage application authenticationBehaviors".
Una vez configurado el registro de nuestra aplicación, podemos utilizarlo para replicar el comportamiento de una aplicación vulnerable y ver el token de identificación(Figura 6).
Si este token de identificación es consumido por una aplicación que utiliza la declaración de correo electrónico como identificador único, la aplicación no sabrá que el usuario no es, de hecho, el usuario legítimo.
Mitigar el abuso de nOAuth
Como se ha señalado, la mitigación del abuso de nOAuth requiere en última instancia que el desarrollador implemente adecuadamente la autenticación para garantizar un identificador único e inmutable.
Pam Dingle, Directora de Estándares de Identidad de Microsoft, publicó un artículo poco después de la divulgación de nOAuth sobre los antipatrones de los desarrolladores. Merece la pena leerlo: "El antipatrón del falso identificador".
Como Pam destaca en el artículo, según la especificación OpenID Connect, en la sección 5.7, una combinación de las declaraciones de emisor(issuer) y sujeto(sub) es la única forma en que una aplicación(SP) puede garantizar un identificador de usuario único y estable.
En Entra ID, el emisor(issuer) se emite como un Issuer URI que incluye el tenant ID, que es globalmente único(Figura 7).
El asunto(sub) es un identificador por pares que es único para cada usuario para cada ID de aplicación(Figura 8). Igualmente importante es el hecho de que sub es un valor inmutable en Entra ID. Entra ID no permite ningún tipo de transformación o modificación de la reivindicación objeto, lo que garantiza su unicidad.
Los detalles sobre las reivindicaciones dentro de un token de identificación emitido por Entra ID se pueden encontrar aquí: "ID token claims reference".
Cambios de Microsoft para mitigar el abuso de nOAuth
Dentro de Entra ID, Microsoft hizo cambios para que cualquier registro de aplicación creado después de junio de 2023 no emita, por defecto, una reclamación de correo electrónico si la dirección de correo electrónico no está verificada. Por supuesto, miles y miles de aplicaciones SaaS han existido desde antes de junio de 2023, y muchos desarrolladores todavía quieren y necesitan consumir la dirección de correo electrónico; muchas aplicaciones SaaS quieren enviar correo electrónico a los usuarios finales, y el consumo a través de una reclamación es la forma más fácil de obtener esa información.
Para ayudar a los desarrolladores, Microsoft también introdujo la declaración opcional xms_edov, que un desarrollador puede utilizar para determinar si una dirección de correo electrónico está verificada. Al escribir este artículo, sin embargo, la declaración xms_edov parece estar en un estado de incertidumbre, lo que hace que uno se pregunte si está siendo obsoleta. Aunque los documentos de Microsoft indican que la declaración es opcional, ya no está disponible en la interfaz de usuario para establecer declaraciones opcionales. La configuración de xms_edov como declaración opcional a través de Graph API funciona, pero aparece un mensaje que indica que no es una declaración opcional válida(Figura 9).
En acción, un dev podría utilizar esta información para decidir si la dirección de correo electrónico de un usuario está verificada en el tenant(Figura 10).
La nueva investigación de Semperis sobre el abuso de nOAuth
El enfoque Descope
En la investigación publicada por Descope, la atención se centra en las aplicaciones SaaS que tienen soporte para múltiples proveedores de identidad, como Google y Microsoft, Facebook, etc.(Figura 11).
Por motivos de usabilidad, las aplicaciones SaaS suelen tener una lógica de fusión de cuentas. Por ejemplo, si me registro en Medium con una cuenta de Facebook y más tarde lo hago con mi cuenta de Google, las dos fuentes de autenticación me llevan en última instancia a la misma cuenta de Medium.
El problema que exploró Descope era que, dado que cualquier cuenta de usuario en Entra ID podía llevar el reclamo del correo electrónico, los desarrolladores que fusionaban basándose en el correo electrónico podían, sin saberlo, dejar entrar a un atacante en la cuenta de un usuario objetivo.
Más allá de algunas de las capacidades que Microsoft ha implementado, Descope recomendó que las aplicaciones SaaS que admiten la funcionalidad de fusión de cuentas interrumpan el flujo la primera vez que se intente iniciar sesión con una fuente de cuenta diferente, utilizando una función para validar la propiedad del correo electrónico. Estamos de acuerdo con este consejo. Esta función puede adoptar la forma de un enlace mágico de correo electrónico, en el que el usuario recibe un mensaje pidiéndole que verifique la titularidad antes de que se realice la fusión.
En nuestra propia investigación, vimos que se trataba de una práctica de seguridad común entre las aplicaciones que demostraron ser invulnerables al abuso de nOAuth.
Investigación Semperis
A finales del otoño de 2024, como parte de una investigación exploratoria, estuvimos revisando la investigación realizada por Descope y decidimos probarla con algunas aplicaciones SaaS. Esto coincidió con la idea de explorar la Entra App Gallery de Microsoft. La Entra App Gallery es un portal dentro de Entra ID que gestiona Microsoft y que permite a terceros proveedores de SaaS presentar aplicaciones que se integran con Entra ID(Figura 12).
En nuestra investigación, examinamos las 1.017 integraciones de OIDC disponibles en ese momento y encontramos 104 aplicaciones que permitían el auto-registro en la aplicación. Dado que el mercado de SaaS es muy competitivo, los proveedores tienden a permitir niveles gratuitos o pruebas de sus aplicaciones con poca fricción, lo que permite utilizar y probar la aplicación sin necesidad de pasar por ningún canal de ventas. Nos centramos en estas aplicaciones no sólo porque ofrecían una barrera baja para la investigación de seguridad, sino también para mantenernos dentro de los límites de las pruebas éticas.
En cada aplicación que probamos, utilizamos un tenant "víctima" que gestionamos para configurar una cuenta de nuestra propiedad dentro de la plataforma. A continuación, utilizamos un tenant diferente, el tenant "atacante", para intentar abusar de nOAuth contra nuestra propia víctima. De esta forma, nos asegurábamos de que nuestras pruebas afectaban únicamente a cuentas bajo nuestro control y sólo accedíamos a muestras de datos de prueba creadas por nosotros.
Nuestra investigación difiere de la de Descope en que estábamos interesados en encontrar aplicaciones que permitieran el abuso de Entra ID cross-tenant nOAuth. Esencialmente, el cliente objetivo (víctima) es un cliente de Microsoft con un inquilino Entra ID, y el atacante utiliza un inquilino Entra ID diferente para realizar el abuso. El siguiente diagrama de Descope es válido en cuanto al flujo de ataque en nuestra investigación(Figura 13).
Sin embargo, con nuestro enfoque, la aplicación SaaS sólo necesita soportar Entra ID para la autenticación. Aunque casi todas las aplicaciones SaaS que probamos admitían una cuenta de usuario local, descubrimos que algunas aplicaciones también admitían múltiples proveedores de identidad, como Google y Entra ID, mientras que otras sólo admitían Entra ID.
Además, teorizamos que si una aplicación sólo admitía Entra ID para la autenticación, era poco probable que el desarrollador implementara la lógica de fusión de cuentas y verificación de correo electrónico que Descope señaló, ya que el desarrollador probablemente no esperaba un escenario de colisión de cuentas.
Aplicaciones vulnerables
En las pruebas de 104 aplicaciones, encontramos 9 que eran vulnerables al abuso de nOAuth; esto se traduce en una vulnerabilidad en aproximadamente el 9% de las aplicaciones probadas. Como 104 es sólo una gota en el cubo de las aplicaciones SaaS que hay por ahí que están integradas con Entra ID, puede extrapolar estos números contra las decenas de miles de aplicaciones SaaS disponibles.
De las aplicaciones que encontramos vulnerables, observamos algunas observaciones interesantes en relación con el tamaño, la escala y el tipo de aplicación. Encontramos una plataforma de sistema de gestión de recursos humanos (HRMS) que, en la práctica, probablemente estaría llena de PII. Del mismo modo, encontramos aplicaciones que se integraban de nuevo en Microsoft 365 para tareas como el correo y el acceso al calendario. Como estas integraciones utilizaban un conjunto diferente de combinaciones de tokens de acceso y actualización, un atacante que abusara con éxito de nOAuth podría no solo obtener acceso a los datos de la aplicación SaaS, sino también, potencialmente, pivotar en los recursos de Microsoft 365.
Por desgracia, las pruebas a escala llevan mucho tiempo. Además de configurar el inquilino Entra para realizar el abuso, necesitábamos un conjunto de ojos humanos en la interfaz de la aplicación SaaS para determinar si el atacante era capaz de acceder a la cuenta de la víctima. Aunque la mayoría de las aplicaciones que eran invulnerables a este abuso generalmente presentaban un nuevo flujo de entrada a la aplicación, algunas simplemente nos dejaban caer en la pantalla principal de la aplicación, requiriéndonos examinar la información de la cuenta o intentar manipular los datos dentro de la aplicación para determinar si el atacante estaba en la misma cuenta que la víctima.
Contacto con las partes interesadas
Como resultado de esta investigación, abrimos un caso con MSRC. También intentamos determinar las partes interesadas en cada ISV que tenía una aplicación vulnerable. Tras ponernos en contacto con estas partes interesadas, siguiendo el principio de Semperis de ser una Fuerza del Bien, nos ofrecimos a ayudarles a resolver la vulnerabilidad de su aplicación; algunos vendedores aceptaron nuestra oferta. En estos casos, ayudamos a los vendedores a entender el problema y realizamos pruebas adicionales de abuso de nOAuth contra su aplicación hasta que se resolvió el problema.
Defensa del cliente: falta de opciones
En última instancia, la única defensa que tiene un cliente contra el abuso de nOAuth es 1) instar al proveedor a solucionar el problema o 2) abandonar la aplicación SaaS.
Dado que el ataque se produce fuera del ámbito de la víctima, los mecanismos de defensa tradicionales no pueden proporcionar protección. Estos incluyen:
- Autenticación multifactor (MFA) y refuerzo de la autenticación en Entra ID
- Acceso condicional
- Soluciones Zero Trust Network Access (ZTNA) y Ciberseguridad para cualquier empresa (CASB)
- Detección y respuesta de puntos finales (EDR)
- Detección y respuesta ampliadas (XDR)
nOAuth detección de abusos
Aunque las soluciones (SaaS Security Posture Management (SSPM)) pueden proporcionar cierta información sobre las aplicaciones SaaS, por lo general se centran en la configuración y la postura de seguridad que se expone a los clientes de la plataforma y no es probable que indiquen el abuso de nOAuth. Existen problemas similares con las plataformas empresariales de navegadores seguros y los complementos de navegadores, que pueden ayudar a detectar otras puertas traseras en las aplicaciones SaaS, pero es poco probable que revelen este tipo de ataque.
Por desgracia, esto deja pocas opciones a los clientes:
- Correlación de registros de autenticación SaaS con Entra ID dentro de una plataforma SIEM
- Preguntar a sus proveedores sobre nOAuth
- Realización por sí mismos de pruebas de abuso de nOAuth
Desde la perspectiva de Entra ID, hemos examinado los principales servicios de las aplicaciones multi-tenant y no hemos encontrado atributos expuestos a un cliente que indiquen que la aplicación consume reclamaciones de correo electrónico no verificadas. Incluso si tales atributos existieran, no habría forma de indicar para qué utiliza la aplicación esta reclamación.
Correlación de registros de autenticación
Para utilizar la correlación de registros para detectar el abuso de nOAuth, necesitaría consumir sus registros de autenticación de Entra ID en una solución de información de seguridad y gestión de eventos (SIEM), como Microsoft Sentinel. También necesitaría consumir los registros de autenticación de su aplicación SaaS y luego correlacionar los dos registros dentro del SIEM. Tendría que buscar eventos de autenticación en la plataforma SaaS con un evento de autenticación faltante en Entra ID(Figura 14).
Por supuesto, los resultados de poner en práctica esta teoría variarán ampliamente. Aunque el sujeto(sub) es el identificador clave en la aplicación SaaS, este valor no se captura en los registros de inicio de sesión de Entra ID cuando se autentica. Por lo tanto, la aplicación SaaS también necesitaría contener atributos como UPN o dirección de correo electrónico dentro de sus registros para la correlación. Del mismo modo, los registros de autenticación del proveedor de SaaS deben estar disponibles de forma que puedan ser consumidos por un SIEM. Otros factores, como el desfase temporal y la precisión, pueden complicar la detección de abusos de nOAuth mediante la correlación de registros.
Pruebas de nOAuth y responsabilidad del proveedor
La única otra opción de un cliente sería probar las aplicaciones SaaS que consumen para detectar el abuso de nOAuth. Antes de hacerlo, pueden ponerse en contacto con el proveedor de la aplicación para preguntarle si conoce nOAuth y si ha realizado pruebas contra el abuso de nOAuth.
Algunos puntos a tener en cuenta:
- Certificaciones como SOC II no han investigado este abuso. Encontramos aplicaciones vulnerables cuyos proveedores tenían certificaciones SOC II y de otro tipo en sus sitios web.
- Pregunte específicamente al proveedor si ha realizado pruebas contra esta vulnerabilidad. Encontramos proveedores que creían haber resuelto el problema, pero aún así pudimos abusar de nOAuth en sus aplicaciones.
Si el proveedor no puede responder definitivamente a esta pregunta, el cliente puede realizar esta prueba con cualquier aplicación que le interese. Al igual que los investigadores de seguridad, los clientes deben asegurarse de que están realizando las pruebas dentro de unos límites éticos: realizando las pruebas con sus propias cuentas de usuario y comprendiendo los requisitos contractuales que puedan tener con el proveedor.
Defensa de los desarrolladores de software contra nOAuth
Los desarrolladores que consumen la declaración de correo electrónico deben verificar que no la están utilizando para la identificación de usuarios. Si es así, deben seguir los pasos documentados por Microsoft para seguir las especificaciones OIC, utilizando emisor y asunto.
Los desarrolladores también pueden examinar los registros de sus aplicaciones para determinar si están recibiendo la declaración de correo electrónico no verificado. Sin embargo, corresponde al desarrollador examinar su código para determinar cómo se utiliza la declaración de correo electrónico.
También existen soluciones alternativas para recibir los datos de atributos de correo electrónico que no provengan de una declaración en el token de ID. OIDC especifica un punto final UserInfo, que se implementa dentro de Entra ID. Este endpoint puede ser utilizado para recibir información sobre el usuario autenticado. Al llamar al punto final UserInfo, la aplicación puede obtener la dirección de correo electrónico del usuario después de la autenticación, incluso si esa dirección no es verificada. Este paso asegura que el reclamo de correo electrónico no sea usado como el identificador único del usuario.
En este ejemplo, podemos llamar al punto final UserInfo sobre Adele Vance, que tiene una dirección de correo electrónico no verificada(Figura 15). El asunto, que es el identificador único, coincidirá con el del token ID.
Los desarrolladores que hayan actualizado su código para resolver la vulnerabilidad nOAuth deben probar su aplicación después de la corrección para asegurarse de que no es vulnerable al abuso de nOAuth. En nuestro trabajo de corrección con proveedores, la corrección inicial no siempre resolvía la vulnerabilidad.
Al comunicarnos nuestros hallazgos, el MSRC reiteró que los desarrolladores deben seguir las recomendaciones y nos remitió al artículo que publicó a partir de la divulgación en 2023. Dado que existen necesidades legítimas para que las aplicaciones obtengan la dirección de correo electrónico de un usuario, no hay forma de determinar si una aplicación está utilizando correctamente el atributo sin probar cada aplicación. Como hemos observado en nuestras propias pruebas, se trata de un proceso que lleva mucho tiempo.
MSRC también dijo que se ha comunicado con los proveedores de aplicaciones, y que aquellos que no hayan arreglado sus aplicaciones están sujetos a ser eliminados de la Entra App Gallery.
Divulgación y calendario
Sorprendidos al comprobar que nOAuth funcionaba de forma abusiva, especialmente en aplicaciones publicadas en la Entra Gallery, abrimos un caso con el MSRC (al que asignamos el número de caso 93209).
También instamos al Grupo de Productos de Identidad de Microsoft a ser más agresivo en la protección de los clientes, teniendo en cuenta la dificultad de la detección de abusos de nOAuth. Sugerimos advertir a los clientes de los principales servicios de que la aplicación permite reclamaciones de correo electrónico no verificadas, aunque, como hemos señalado, no sería un identificador absoluto de ser vulnerable a nOAuth.
También indicamos las nueve aplicaciones vulnerables que encontramos, por si el MSRC estaba en contacto con esos proveedores.
- 3 de diciembre de 2024: Caso creado con MSRC
- 3 de diciembre de 2024: Caso reconocido por el MSRC
- 4 de diciembre de 2024: Proporcionamos detalles adicionales del caso a MSRC
- 17 de diciembre de 2024: Actualizamos el caso con MSRC, señalando que trabajamos con un proveedor para resolver una de las aplicaciones vulnerables
- 17 de marzo de 2025: Preguntamos al MSRC sobre el estado del caso; no recibimos respuesta.
- 18 de marzo de 2025: Notificamos al MSRC en el portal la intención de divulgar en sesión en Troopers 2025 (si es seleccionado)
- 19 de marzo de 2025: Notificamos al MSRC por correo electrónico la intención de divulgar en sesión en Troopers (si se seleccionaba) y pedimos orientación sobre la divulgación, ya que la vulnerabilidad original ya se había divulgado; no se recibió respuesta.
- 18 de abril de 2025: El caso fue cerrado por el MSRC, indicando que "se informó de una solución para el problema que usted presentó" sin más información.
- Abril - mayo de 2025: Probamos y encontramos proveedores de aplicaciones que eran vulnerables a nOAuth; notificamos a los proveedores de nuevo y nos pusimos en contacto con MSRC con nuestros hallazgos.
- Junio de 2025: El MSRC proporcionó detalles sobre las aplicaciones vulnerables a nOAuth en la galería de aplicaciones Entra.
- 26 de junio de 2025: Divulgación pública
