Reports
ALTA[CONFIGURACIÓN]#3930102

CORS mal configurado en admin.myndr.net: cualquier subdominio *.myndr.net podía leer el panel con credenciales

El panel de administración de Myndr aceptaba cualquier origen *.myndr.net (e incluso orígenes http://) con Access-Control-Allow-Credentials: true, lo que permitía leer respuestas autenticadas y nonces CSRF desde otro subdominio.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

El servidor de admin.myndr.net copiaba en la cabecera Access-Control-Allow-Origin el valor de la cabecera Origin de la petición cuando se trataba de un subdominio *.myndr.net, y lo acompañaba de Access-Control-Allow-Credentials: true. Con esa combinación, el navegador permite que JavaScript alojado en cualquier subdominio de Myndr haga peticiones al panel con las cookies de la víctima y lea las respuestas.

El investigador shubham71 lo reportó al programa de Myndr el 10 de agosto de 2026 como control de acceso inadecuado (CORS mal configurado), con una puntuación CVSS 3.1 de 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). El reporte se marcó como resuelto y se divulgó el 10 de septiembre de 2026.

Endpoints señalados como afectados:

https://admin.myndr.net/
https://admin.myndr.net/auth/login-admin
https://admin.myndr.net/auth/login-admin-new-password
https://admin.myndr.net/cp/postcode
https://dashboard.myndr.net/

Además, el servidor también aceptaba orígenes en HTTP plano, como http://admin.myndr.net.

Pasos de reproducción

Para demostrar el fallo de configuración no hace falta estar autenticado.

  1. Envía una petición al panel indicando como origen un subdominio inventado de Myndr:
GET / HTTP/1.1
Host: admin.myndr.net
Origin: https://evil.myndr.net
  1. Comprueba que la respuesta refleja ese origen y permite credenciales:
HTTP/2 302
access-control-allow-origin: https://evil.myndr.net
access-control-allow-methods: GET, POST, OPTIONS, DELETE, PUT
access-control-allow-credentials: true
access-control-allow-headers: User-Agent,Keep-Alive,Content-Type
vary: Origin
location: /auth/login-admin
  1. Desde una página servida en cualquier subdominio *.myndr.net, lanza una petición con credenciales al formulario de login del panel y extrae el nonce CSRF del HTML:
fetch("https://admin.myndr.net/auth/login-admin", {credentials: "include"})
  .then(r => r.text())
  .then(html => {
    const nonce = html.match(/name="nonce" value="([^"]+)"/)[1];
    // Attacker now has the CSRF nonce
  });

La respuesta contiene el nonce en claro:

<input type="hidden" name="nonce" value="[REDACTADO]" />
  1. Repite la petición del paso 1 con un origen en HTTP plano:
GET / HTTP/1.1
Host: admin.myndr.net
Origin: http://admin.myndr.net

El servidor también lo acepta con credenciales:

access-control-allow-origin: http://admin.myndr.net
access-control-allow-credentials: true

Cadena de explotación descrita

El investigador plantea el ataque completo así:

  1. El atacante consigue alojar contenido en algún subdominio de Myndr (mediante un XSS, un subdomain takeover o un despliegue comprometido).
  2. Esa página hace peticiones cross-origin a admin.myndr.net con las cookies de la víctima.
  3. Lee los nonces CSRF del formulario.
  4. Con ellos lanza un CSRF para cambiar la contraseña del administrador o crear una cuenta de administrador nueva.

Impacto

Quien controle contenido en cualquier subdominio *.myndr.net podía leer respuestas autenticadas del panel de administración, entre ellas:

  • Los nonces CSRF de los formularios de login y de cambio de contraseña.
  • La funcionalidad y los datos del panel de administración.
  • Tokens de sesión, en caso de que aparezcan en las respuestas.

Encadenado con CSRF, según el investigador, esto permite tomar por completo una cuenta de administrador. El requisito es poder alojar contenido en algún subdominio de Myndr; el reporte señala que hay más de 20 subdominios activos que podrían servir de punto de entrada (por ejemplo, un XSS en test.myndr.net o meta.myndr.net). El investigador añade que aceptar orígenes HTTP abre la puerta a interceptar cookies de sesión en conexiones sin cifrar.

Remediación

El reporte figura como resuelto, pero no detalla qué cambió Myndr. Las medidas que propuso el investigador fueron:

  • Dejar de reflejar cualquier origen *.myndr.net.
  • Permitir solo una lista cerrada de orígenes de confianza (por ejemplo, https://admin.myndr.net y https://dashboard.myndr.net).
  • No reflejar nunca orígenes arbitrarios de subdominios junto con Access-Control-Allow-Credentials: true.
  • Eliminar por completo la aceptación de orígenes HTTP y admitir solo HTTPS.
  • Usar tokens CSRF ligados a la sesión que no se puedan leer desde otro origen.