Saltar al contenido principal
Abstract secure email routing dashboard with misdirected messages and domain controls

Los dominios no-reply exponen una brecha silenciosa en el correo

WIRED informa de que investigadores que compraron dominios como noreply.net y deleteduser.com recibieron correos automatizados sensibles, lo que revela un riesgo persistente en la gestión de direcciones.

Publicado

09 ago 2026

Tiempo de Lectura

3 min de lectura

Compartir este artículo:

Contenido

Qué ocurrió

WIRED informó el 8 de agosto de 2026 de que los investigadores de seguridad Cory Solovewicz y Mike Sheward compraron dominios como noreply.net, noreply.us y deleteduser.com y los configuraron para recibir correo. En lugar de captar solo spam, esos dominios empezaron a recibir mensajes automatizados de empresas y organizaciones que aparentemente trataban las direcciones de marcador de posición o de usuarios eliminados como si no pudieran pertenecer a nadie.

Según WIRED, uno de los dominios de Solovewicz había registrado 401.796 mensajes desde diciembre de 2024. Los ejemplos descritos por el medio incluían pedidos personales, mensajes de creación de cuentas, información relacionada con reparaciones, informes de lesiones y credenciales de plataformas de prueba. Lo importante no es que se haya descubierto una nueva cadena de explotación. Es que sistemas empresariales corrientes seguían enviando información real a direcciones que se asumían inocuas.

Por qué importa

Es un recordatorio de que las direcciones de correo solo son límites de seguridad cuando la propiedad y el enrutamiento están verificados. Una cadena que parece un sumidero, como un marcador no-reply o deleted-user, puede seguir siendo una dirección entregable si el dominio está registrado y configurado para aceptar correo.

OWASP documenta una clase de riesgo relacionada con dominios y cuentas caducados: si un dominio o buzón cambia de manos, el correo entrante puede exponer información personal, mensajes de restablecimiento de contraseña y pistas sobre servicios conectados a antiguos usuarios. Ese contexto encaja directamente con el caso descrito por WIRED. El fallo no se limita a una marca ni a un proveedor de correo; puede aparecer allí donde las aplicaciones conservan direcciones obsoletas, reescriben cuentas eliminadas como marcadores genéricos o envían mensajes transaccionales antes de validar el destinatario.

La autenticación del correo no resuelve por completo este problema. M3AAWG explica que SPF, DKIM y DMARC ayudan a los sistemas receptores a evaluar si un mensaje está autorizado por el dominio remitente, pero no prueban que la dirección de destino sea segura o intencionada. Dicho de otro modo, un correo perfectamente autenticado puede entregarse igualmente al dominio equivocado.

Qué deberían revisar los equipos

Los equipos de desarrollo y seguridad deberían auditar los flujos de correo automatizado que gestionan eliminación de cuentas, usuarios de prueba, empleados desactivados, marcadores de CRM y convenciones no-reply. Los sistemas no deberían transformar usuarios reales en direcciones bajo dominios públicos salvo que la organización controle y supervise esos dominios.

Los flujos de restablecimiento de contraseña y recuperación de cuentas merecen una revisión especial. OWASP recomienda que los tokens de recuperación sean aleatorios, suficientemente largos, almacenados de forma segura, de un solo uso y con caducidad. Esos controles reducen el daño si un correo queda expuesto, pero no eliminan la necesidad de verificar que el mensaje de recuperación llega al destinatario correcto.

Para direcciones que deban ser claramente no enrutables en ejemplos, pruebas o marcadores internos, los equipos deberían usar convenciones reservadas en lugar de dominios reales que cualquiera pueda comprar. RFC 2606 reserva nombres como .invalid, .test, .example y .localhost para casos en los que debe evitarse el conflicto con DNS real.

La conclusión práctica

La historia trata menos sobre el estilo de comunicación no-reply y más sobre higiene de datos. Si una aplicación puede enviar facturas, credenciales, notas de casos o mensajes de recuperación a una dirección que nadie posee internamente, el sistema está tomando una decisión real de privacidad y seguridad basada en una suposición sin comprobar.

El siguiente paso útil es aburrido pero valioso: inventariar plantillas de correo, gestión de rebotes, flujos de eliminación e integraciones SaaS de terceros. Hay que localizar cada punto donde el sistema sustituye, almacena o reutiliza una dirección de marcador y confirmar que cada destino está verificado, es propiedad interna o es intencionadamente no entregable.

Etiquetas:

#email security #cybersecurity #privacy #developer tools #identity

9

vistas

0

compartidos

0

me gusta

Artículos Relacionados