El ataque podía superar los principales mecanismos de autenticación de correo y expuso, además, una llamativa historia de correcciones incompletas que se extendió durante más de un año.
Un correo llega a la bandeja de entrada. El remitente parece ser tim.cook@icloud.com. SPF pasa. DKIM pasa. DMARC también.
Todo parece indicar que el mensaje salió legítimamente de la infraestructura de Apple.
Pero no.
Investigadores de SEC Consult demostraron que era posible utilizar los propios servidores de iCloud para enviar correos aparentando provenir de cualquier dirección @icloud.com, incluso cuentas que no pertenecían al atacante. El problema no estaba en romper DKIM ni en falsificar desde afuera los servidores de Apple: estaba en cómo distintas partes de la propia infraestructura interpretaban un mismo mensaje.
La investigación, publicada el 1 de octubre de 2026 por Timo Longin, documenta dos vulnerabilidades de email spoofing basadas en discrepancias de parsing dentro de la infraestructura SMTP de iCloud.
Cuando dos servidores entienden cosas diferentes
El ataque parte de una idea conocida en seguridad: si dos componentes interpretan los mismos datos de manera diferente, el espacio entre ambas interpretaciones puede convertirse en una vulnerabilidad.
Es el mismo principio detrás de técnicas como HTTP Request Smuggling y, en el mundo del correo electrónico, SMTP Smuggling.
Normalmente, Apple no permite autenticarse en iCloud con una cuenta y luego enviar un mensaje declarando otra dirección @icloud.com como remitente. Si alguien autenticado como usuario@icloud.com intenta enviar directamente como admin@icloud.com, el servidor rechaza el mensaje.
El problema descubierto por SEC Consult estaba en lo que ocurría después.
Los investigadores encontraron diferencias en la forma en que distintas etapas de la infraestructura de iCloud procesaban el encabezado From:. Manipulando caracteres de retorno de carro (CR), podían conseguir que un componente validara como legítima la dirección del atacante mientras otro terminara interpretando como remitente una dirección diferente.
En otras palabras:
Apple verificaba una identidad, pero terminaba enviando otra.
El correo podía parecer completamente legítimo
El detalle que vuelve especialmente interesante al ataque es que no se trataba del típico spoofing donde DMARC termina delatando la falsificación.
Los mensajes manipulados podían superar SPF, DKIM y DMARC.
SPF comprueba, simplificando, si el servidor que envió el correo está autorizado por el dominio. En este caso el mensaje realmente estaba saliendo de infraestructura de Apple.
DKIM agrega una firma criptográfica al correo. Pero la firma se generaba después de que el mensaje hubiera atravesado el procesamiento vulnerable, por lo que Apple terminaba firmando criptográficamente el mensaje ya manipulado.
Y DMARC utiliza, entre otras cosas, los resultados y la alineación de SPF y DKIM.
El resultado era especialmente convincente: el receptor podía observar un mensaje proveniente de infraestructura legítima de iCloud, firmado por Apple y con las verificaciones de autenticación aprobadas. SEC Consult mostró como prueba de concepto un correo aparentemente enviado desde tim.cook@icloud.com.
Apple corrigió el problema. Pero apareció otro camino
La historia no terminó con el primer reporte.
SEC Consult informó inicialmente la vulnerabilidad a Apple el 21 de mayo de 2024. Meses después, los investigadores comprobaron que el método original ya no funcionaba y Apple dio el reporte por remediado en noviembre de ese año. La compañía otorgó además una recompensa de 15.000 dólares a través de su programa de bug bounty.
Pero en diciembre los investigadores encontraron otra forma de explotar discrepancias similares.
Esta vez utilizaron el funcionamiento de dot-stuffing, un mecanismo histórico de SMTP que agrega y elimina puntos al comienzo de determinadas líneas durante la transmisión de mensajes.
Otra vez, dos componentes interpretaban el mensaje de manera diferente.
Y otra vez era posible terminar enviando correo como una dirección @icloud.com arbitraria.
Una corrección bastante peculiar
La cronología publicada por SEC Consult contiene uno de los episodios más llamativos de toda la investigación.
El 11 de diciembre de 2024, los investigadores comprobaron que una de las correcciones implementadas no solucionaba realmente el problema de parsing: simplemente bloqueaba la cadena utilizada en la prueba de concepto.
Concretamente, según SEC Consult, se había colocado en una lista negra la palabra “admin”.
El resultado era que el PoC utilizado originalmente dejaba de funcionar, pero otras direcciones seguían siendo falsificables. Los investigadores respondieron enviando una nueva prueba utilizando security@icloud.com.
La vulnerabilidad continuó atravesando distintas rondas de correcciones y bypasses durante 2025. En junio de ese año, SEC Consult volvió a confirmar que el ataque todavía podía reproducirse.
Recién en noviembre Apple desplegó nuevos cambios y, en diciembre de 2025, los investigadores confirmaron que los métodos conocidos habían quedado finalmente mitigados. La investigación técnica completa se hizo pública casi un año después, el 1 de octubre de 2026.
El problema no era SPF, DKIM ni DMARC
El caso deja una enseñanza técnica importante porque sería fácil concluir que SPF, DKIM y DMARC “fallaron”.
No fue exactamente eso.
Los mecanismos hicieron lo que debían hacer sobre la información que recibieron.
El correo realmente provenía de infraestructura autorizada de Apple. Y Apple realmente había firmado el mensaje.
La vulnerabilidad estaba antes: en el sistema que decidió qué identidad estaba autorizada a enviar ese correo.
Es una distinción importante.
Los controles criptográficos pueden garantizar que determinado sistema produjo o autorizó determinada información. Pero si ese sistema fue engañado antes de realizar la firma, la criptografía puede terminar certificando algo incorrecto con absoluta legitimidad matemática.
La identidad del remitente sigue siendo una capa frágil
SEC Consult señala además que todavía podían quedar rastros útiles para detectar estos mensajes. Por ejemplo, el Return-Path y algunos encabezados de autenticación podían revelar la cuenta de iCloud utilizada realmente por el atacante, permitiendo construir heurísticas adicionales de detección.
Pero eso no elimina el problema de fondo.
El correo electrónico arrastra décadas de compatibilidad, extensiones y comportamientos implementados de maneras ligeramente diferentes. Y cada diferencia de interpretación entre componentes crea una posible superficie para ataques de smuggling.
Este caso lo demuestra de una manera particularmente clara: no hizo falta quebrar una firma criptográfica ni comprometer las claves de Apple.
Alcanzó con conseguir que dos partes de su infraestructura no estuvieran de acuerdo sobre qué decía exactamente el mismo correo.
Y durante un tiempo, esa pequeña diferencia fue suficiente para que cualquiera pudiera parecer Tim Cook.