Deleteduser.com: un dominio de USD 15 destapó PII de 30 empresas

El 17 de abril de 2026, el ingeniero de seguridad Mike Sheward publicó en Medium un caso que ilustra con precisión uno de los anti-patrones de privacidad más extendidos de la industria del software: deleteduser.com, un dominio que compró por apenas USD 15, empezó a recibir datos personales reales en menos de una hora. En 24 horas, treinta organizaciones de sectores distintos — cadenas de gimnasios, plataformas hoteleras, HR SaaS, apps de delivery, una eléctrica e incluso dos empresas de ciberseguridad — habían enviado PII a un buzón que ellas asumían inerte. El caso deleteduser.com no es una curiosidad técnica: es la demostración práctica de cómo una línea mal pensada de SQL puede transformar una solicitud GDPR en una fuga de datos con implicaciones legales de seis y siete cifras.

Qué pasó: el dominio de USD 15 que se volvió imán de PII

Sheward, Head of Security en Xeal y ex-CISO de Amperity, registró deleteduser.com con la sospecha de que muchas aplicaciones estaban usando ese nombre de dominio como placeholder al procesar borrados de cuentas. Configuró un catch-all MX — probablemente con Cloudflare Email Routing o ImprovMX — y esperó. El primer correo llegó en menos de 60 minutos. En las 24 horas siguientes recibió mensajes de treinta organizaciones distintas.

Lo que llegaba al buzón no era spam ni bounces automáticos: eran datos personales reales, identificables y en algunos casos sensibles. Entre el contenido enumerado por Sheward aparecen:

• Nombres completos de huéspedes de hotel, con número de habitación y fechas de check-in y check-out.- Órdenes de compra y confirmaciones de envío con direcciones de remitente y destinatario.- Solicitudes de reincorporación a gimnasios con el nombre completo del ex-miembro.- Tokens de password-reset válidos que, en teoría, permitirían hijackear cuentas de terceros si las apps no invalidaban el email tras el borrado.- Boletines internos y reportes con datos de empleados de plataformas HR.

El patrón es transversal a los rubros. No es un fallo aislado de una empresa: es un anti-patrón de diseño que se replica silenciosamente desde hace años en todo tipo de stacks.

El anti-patrón técnico: por qué las apps mandan correos al vacío

La raíz del problema es mundana. Cuando un usuario ejercita su derecho al olvido — Artículo 17 del GDPR en Europa, Artículo 22 de la LFPDPPP en México, la LPDP vigente en El Salvador desde mayo de 2025 — muchas aplicaciones no pueden simplemente ejecutar un DELETE FROM users. Hay integridad referencial: órdenes que apuntan al usuario, facturas, logs de auditoría, reportes de BI que asumen que cada fila de users sigue existiendo. Hay constraints UNIQUE sobre el campo email.

La "solución" que aparece en centenares de code reviews es esta:

-- ANTI-PATRÓN: no hagas esto
UPDATE users
SET email = CONCAT('deleted_', id, '@deleteduser.com'),
    name = 'Deleted User',
    deleted_at = NOW()
WHERE id = ?;

El desarrollador asume dos cosas, ambas falsas: primero, que el dominio deleteduser.com no existe y nadie lo va a comprar; segundo, que el pipeline de notificaciones va a saber que el usuario está borrado y no le va a mandar más correos. En la práctica, ninguna de las dos se cumple: alguien compra el dominio por USD 15, y los pipelines de reportes, billing, password-reset y webhooks siguen emitiendo mensajes como si nada, porque consultan la tabla users sin interpretar correctamente el flag deleted_at.

⚠️ Ojo: los dominios reservados por RFC 2606 son example.com, example.net, example.org, y los TLD .test, .example, .invalid y .localhost. Cualquier otro dominio "inventado" (deleteduser.com, userdeleted.com, anonymous.com, noreply.com) puede ser registrado por un tercero. Si lo usas como placeholder, estás creando un canal de exfiltración.

Cómo se propaga la fuga después del "borrado"

Para entender por qué 30 empresas cayeron en el mismo error en 24 horas, ayuda ver el flujo del ataque de manera gráfica:

sequenceDiagram
    participant U as Usuario
    participant A as App
    participant DB as Base de datos
    participant P as Pipeline notificaciones
    participant D as deleteduser.com
    U->>A: Solicita borrar cuenta (GDPR Art. 17)
    A->>DB: UPDATE email = [e-mail]
    Note over A,P: El pipeline sigue leyendo users.email
    P->>D: Envia reporte semanal con PII
    P->>D: Envia password-reset token
    P->>D: Envia confirmacion de pedido
    D-->>U: Sheward recibe todo en su catch-all

La propiedad más peligrosa del ataque es que no deja huella en el sistema origen. No hay logs de error, no hay bounces, no hay alertas. Un pipeline sano tendría bounces cercanos al 100 % si el dominio no existiera; cuando alguien lo registra y activa catch-all, los bounces caen a 0 — y ningún SRE nota la diferencia, porque en métricas operativas el silencio se interpreta como éxito.
Un catch-all en un dominio de USD 15 basta para recibir correos corporativos completos.

Contexto e historia: no es la primera vez

El caso deleteduser.com se inscribe en una clase de vulnerabilidades conocida como domain resurrection attacks o dangling mail, y tiene antecedentes públicos contundentes:

• Inti De Ceukelaire (Bélgica, 2024) — El investigador belga compró 107 dominios gubernamentales expirados a EUR 8 cada uno. Con ellos obtuvo acceso a password-resets de 80 cuentas Dropbox, 142 Google Drive, 57 Microsoft/OneDrive/SharePoint y 848 correos corporativos pertenecientes a policía, hospitales y servicios sociales. Su paper When Privacy Expires demostró que la expiración de dominio es, en la práctica, una modalidad silenciosa de account takeover.- watchTowr Labs (Reino Unido, enero de 2025) — La firma tomó control de más de 4 000 backdoors activos gastando USD 20 por dominio. Los C2 (command-and-control) servers de esos backdoors apuntaban a dominios cuyos registros habían expirado; cualquiera podía comprarlos y heredar el control.- PyPI (agosto de 2025) — El repositorio oficial de paquetes Python desverificó preventivamente 1 800 correos cuyos dominios habían expirado, después de al menos un hijack confirmado en 2022 en el que un atacante publicó versiones maliciosas de un paquete legítimo tras registrar el dominio del mantenedor.- SubdoMailing (2024) — Más de 8 000 dominios legítimos con registros DNS colgantes fueron secuestrados para enviar fraude publicitario masivo.

En todos los casos el patrón estructural es el mismo: un sistema que confía en un dominio que dejó de estar bajo control de la organización, y un atacante que compra esa confianza por el precio de un almuerzo.

Datos y cifras del incidente

La aritmética del caso deleteduser.com es brutalmente simple y, por eso mismo, didáctica:

• Costo del atacante: USD 15 en registro de dominio, más unos minutos configurando un catch-all gratuito en Cloudflare Email Routing o ImprovMX.- Tiempo hasta el primer correo con PII: menos de una hora.- Organizaciones identificadas en 24 horas: 30, en rubros que incluyen gimnasios, hotelería, HR SaaS, delivery, energía, monitoreo de uptime y dos firmas de ciberseguridad.- Tipos de PII recibidos: nombres, direcciones, fechas de estadía, órdenes de compra, envíos, solicitudes de reincorporación y tokens de password-reset.- Divulgación: Sheward notificó a cada organización identificada y a las autoridades relevantes antes de publicar el caso.

Comparado con los precedentes, la eficiencia del ataque es notable: De Ceukelaire necesitó 107 dominios y EUR 856 para llegar a algo equivalente; Sheward lo logró con uno solo.

Impacto legal: GDPR, México y El Salvador

La consecuencia regulatoria es seria porque el acto de enviar PII a un dominio externo constituye, por definición, una transferencia de datos a un tercero no autorizado. Bajo el GDPR, esto activa varios artículos:

• Artículo 32 (seguridad del tratamiento) — obligación de implementar medidas técnicas y organizativas apropiadas. Un placeholder en un dominio registrable no califica como tal.- Artículo 33 (notificación a la autoridad) — la organización tiene 72 horas para reportar la brecha a su DPA nacional.- Artículo 34 (notificación al titular) — si el riesgo es alto, hay que avisar directamente a las personas afectadas.- Multas: hasta EUR 20 millones o el 4 % de la facturación global anual, lo que sea mayor.

En México, la nueva LFPDPPP vigente desde 2025 establece multas de hasta USD 1.81 millones, duplicables cuando hay datos sensibles de por medio — exactamente el tipo de información (tokens, datos de huéspedes) que Sheward recibió. En El Salvador, la LPDP en vigor desde mayo de 2025 sigue una estructura similar con sanciones escalonadas y obligación de notificación a la autoridad y al titular.

📌 Nota: el hecho de que el placeholder haya sido elegido por un desarrollador junior tres años antes no mitiga la responsabilidad del data controller. Para las autoridades, el pipeline que envía PII a un dominio ajeno es una falla de Artículo 32, independientemente de la intención original.
El derecho al olvido mal implementado se convierte en canal de exfiltración.

Qué sigue: cómo arreglar el anti-patrón

La remediación técnica no es compleja, pero requiere disciplina en varios frentes. Las prácticas recomendadas, alineadas con lo que sugieren Sheward y los casos previos, son:

• Usar dominios reservados por RFC 2606 — si necesitas un placeholder sintáctico, deleted_{id}@example.invalid es el canónico. El TLD .invalid está garantizado por IETF para no resolver nunca.- Mejor aún: NULL y bandera de borrado — si el esquema tiene un UNIQUE en email, se puede cambiar a un índice UNIQUE parcial (WHERE deleted_at IS NULL) en PostgreSQL o a una columna virtual en MySQL 8. Así no necesitas inventar correos.- Cortar el pipeline de notificaciones en la misma transacción — el UPDATE de borrado debe desregistrar al usuario en todos los sistemas downstream (Mailchimp, Customer.io, webhooks internos) en la misma unidad atómica, no en un job asíncrono "cuando se pueda".- Monitorear bounce rate como canario — si tu sistema emite correos a ex-usuarios, el bounce rate contra el dominio placeholder debe ser 100 %. Cualquier caída súbita a 0 es la señal de que alguien registró el dominio.- Auditar placeholders en código — un grep -r "@deleteduser\|@anonymous\|@removed\|@noreply" sobre todo el codebase suele encontrar, en promedio, entre 5 y 15 hits en apps medianas.- Encriptar el campo email de usuarios borrados en lugar de sobrescribirlo — algunas legislaciones aceptan la encriptación con llave inaccesible como forma válida de anonimización.

💡 Tip: si heredaste una base de datos con miles de filas @deleteduser.com o similares, ejecuta una migración antes de que alguien descubra que el dominio aún está disponible. Reemplaza todos los placeholders por deleted_{id}@{id}.invalid o por NULL en la misma transacción.

El caso deleteduser.com probablemente acelere una categoría de auditoría que hoy casi no existe: auditoría de placeholders sintéticos en datos de usuario. No hay frameworks estándar, no hay linters dedicados, no hay páginas en OWASP específicamente sobre el tema. La próxima iteración del OWASP Top 10 de privacidad, o las guías del ENISA en 2026, muy probablemente lo incluyan.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Es ilegal comprar un dominio como deleteduser.com?

No. Registrar un dominio disponible es una operación comercial legítima. Lo que sí puede ser ilegal — según jurisdicción — es usar los datos recibidos en el catch-all con fines distintos a la investigación responsable. Sheward actuó bajo divulgación coordinada, lo que en la mayoría de marcos regulatorios se considera investigación de seguridad legítima.

¿Mi aplicación puede estar haciendo esto sin que yo lo sepa?

Muy probablemente sí, si alguna vez implementaste "right to be forgotten" con un UPDATE al campo email. Ejecuta SELECT COUNT(*) FROM users WHERE email LIKE '%@deleted%' OR email LIKE '%@removed%' OR email LIKE '%@anonymous%' para tener una idea del tamaño del problema en tu base de datos.

¿example.com sí funciona como placeholder seguro?

Sí. example.com, example.net, example.org, y los TLD .example, .test, .invalid y .localhost están reservados por RFC 2606 y RFC 6761. Nunca van a tener registros MX funcionales en producción, por lo que los correos siempre fallarán de manera segura.

¿Qué pasa con los tokens de password-reset que recibió Sheward?

Si una aplicación enviaba tokens a una dirección bajo deleteduser.com, significa que el usuario "borrado" mantenía alguna ruta de recuperación activa. En los casos donde el token no había expirado, Sheward tuvo — teóricamente — la capacidad de tomar control de esas cuentas. Divulgó en lugar de explotar, pero un atacante con otros valores éticos habría escalado.

¿El GDPR aplica si mi empresa está en Latinoamérica?

Aplica si procesas datos de residentes europeos, independientemente de dónde esté tu empresa. Además, la LFPDPPP mexicana (2025) y la LPDP salvadoreña (mayo de 2025) contienen obligaciones muy similares al Artículo 32 del GDPR, incluyendo la exigencia de medidas técnicas adecuadas y notificación de brechas.

¿Cuánto tardaría auditar mi codebase para detectar este anti-patrón?

Para una app mediana (100k-500k líneas), un grep por los placeholders comunes más una revisión de las migraciones de soft delete suele llevar entre 2 y 6 horas. La remediación puede ser más larga si el placeholder está disperso en varios servicios del stack.

Referencias

• Mike Sheward — deleteduser.com: A $15 PII Magnet — El relato original del investigador que compró el dominio y documentó las 30 organizaciones enviando PII.- RFC 2606 — Reserved Top Level DNS Names — El estándar IETF que lista los dominios y TLD reservados para ejemplos, pruebas y uso interno.- watchTowr Labs — Publicaciones de la firma sobre domain resurrection attacks, incluyendo el takeover de 4 000 backdoors en 2025.- GDPR Art. 32 — Security of processing — Texto completo del artículo que obliga a implementar medidas técnicas y organizativas adecuadas.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.