An email could display someone else’s icloud.com address and still pass the checks normally used to authenticate mail. In a technical report published on October 1, SEC Consult researcher Timo Longin explained how two flaws in iCloud’s message processing made that contradiction possible. Apple’s deployed fixes were confirmed on December 9, 2025: the news is the newly released research, not a warning that these bypasses remain open. [1]
The distinction matters when an unexpected message asks you to trust its sender. A successful authentication result is useful evidence about mail delivery; it is not permission to follow the message’s instructions. This case shows how the provider could approve one representation of an email, then send another.
The obvious forgery failed; changing the interpretation worked
iCloud normally rejected a message whose visible From address did not belong to the signed-in sender. Simply replacing that address with another iCloud identity was therefore insufficient. Longin’s research instead targeted the processing stages between submission and delivery.
In the first method, unusual carriage-return characters made a proposed sender line look different to two parsers—the components that read the message structure. The initial check used the legitimate account address. Later normalization turned the other line into a recognizable From header. The researcher then used the same disagreement to move the legitimate sender header into the message body, leaving the substituted identity visible to the recipient.
The diagram shows the important boundary: sender authorization and delivery did not interpret the same bytes in the same way. Two visible sender headers would often be rejected by the receiving service; changing where the header section ended avoided that obstacle in the demonstrated method. The result was impersonation without needing access to the impersonated person’s mailbox.
Why SPF, DKIM and DMARC did not expose the switch
SPF checks whether a sending server is authorized for the envelope-sender domain. DKIM verifies a domain’s signature over specified message content. DMARC checks alignment between the visible sender domain and an authenticated SPF or DKIM domain. These are domain-level checks, not a universal guarantee that the person or mailbox shown in the sender line authorized the message. CERT/CC’s separate advisory on ambiguous From interpretation explains why discrepancies among providers and clients can undermine that identity assumption. [2]
In the iCloud demonstration, signing happened after the second parser had processed the message. DKIM could therefore validate the delivered version—even though the earlier sender-permission check had seen a different structure. SPF and DMARC also passed. The flaw sat before the signature, rather than in a broken signature check.
The authentication panel is a research result, not a report of a victim’s stolen account. It illustrates a narrower point: authentic infrastructure and a valid signature can coexist with a forged mailbox identity when the sending pipeline authorizes the wrong representation.
A second method survived the first repair
After the original method stopped working, Longin found another discrepancy involving SMTP’s treatment of leading dots, known as dot-stuffing. One stage did not interpret those dots like the next stage did. Removing a leading dot could reveal a sender header that the earlier permission check had not recognized. A related parsing difference again moved the legitimate sender line out of the headers.
The disclosure timeline records repeated retesting of partial fixes before SEC Consult confirmed remediation in December 2025. That history is the practical engineering lesson: checking a sender before message transformations is insufficient if those transformations can change which address later components recognize. No active phishing campaign, victim total or account theft is established by these proof-of-concept results.
What an unexpected iCloud email actually tells you
Receiving a message that claims your own or a familiar address does not, by itself, prove that the corresponding account was accessed. Sender spoofing and account compromise are different questions. Our phishing-versus-spoofing guide explains that distinction; confirmed unauthorized sign-ins belong on the separate Apple Account recovery path.
For an unexpected payment, password or verification request, open the relevant app or a known website independently instead of using the message’s link or telephone number. Apple’s own guidance says never to share passwords or verification codes and to forward suspicious Apple-looking email to reportphishing [at] apple [dot] com. [3]
Mail administrators should preserve the original message and examine the visible From, envelope sender and authentication results together. A mismatch is a reason to investigate, not an automatic verdict: legitimate forwarding and other mail arrangements can also create differences. The published iCloud fixes require no special reader-side workaround described in this report.
The lasting takeaway is specific: authentication checks remain valuable, but they cannot substitute for verifying an unusual request through a channel you already trust.
References
- Timo Longin / SEC Consult Vulnerability Lab. “From: [email protected] — Spoofing Arbitrary Apple iCloud Identities.” October 1, 2026. Research and disclosure timeline.
- CERT/CC. “Authenticated SMTP users may spoof other identities due to ambiguous From header interpretation.” Vulnerability Note VU#517845, accessed October 3, 2026. Sender-interpretation advisory.
- Apple Support. “Recognize and avoid social engineering schemes including phishing messages, phony support calls, and other scams.” Accessed October 3, 2026. Official reporting and account-safety guidance.
