Apple’s Servers Signed a Forged iCloud Address. My Header Analyzer Called It Good.
A now-fixed iCloud bug let a logged-in user send as any @icloud.com address with SPF, DKIM and DMARC all passing. I pasted the researchers’ headers into my own tool to see what a pass can and can’t tell you.
On 1 October, SEC Consult published a write-up by Timo Longin with a title that says most of it: “From: anyone@icloud.com”. He found two ways to send mail through Apple’s own iCloud servers with somebody else’s iCloud address in the From line. The messages arrived at Gmail with SPF, DKIM and DMARC all passing. One of his test messages came from tim.cook@icloud.com.
Before anything else: this is fixed. The researchers confirmed Apple’s fix on 9 December 2025, after reporting the first bug in May 2024, and they only published once it was done. It also needed a logged-in iCloud account, the sender’s own, so it was never a way for a stranger with no account to send as Apple users.
I build notspoofed.com, a set of free email authentication tools, and a lot of what I’ve written about email authentication comes down to one sentence: a DMARC pass tells you the domain’s own servers sent the message. This is the cleanest real case I’ve seen of what that sentence leaves out.
What the researchers did
When you send through iCloud, you log in to Apple’s submission server and hand it a message. Apple checks that the From address in that message is one of yours. Try to put someone else’s address there and iCloud refuses with “From address is not one of your addresses”. That check is Apple’s own. SMTP doesn’t require it; each provider decides whether to enforce it.
Longin’s finding was that the message passed through two parsers inside iCloud, and they didn’t read it the same way. He calls them parser 1 and parser 2. Parser 1 did the From check. Parser 2, which the researchers think is based on Postfix, prepared the message for sending.
The first trick used bare carriage-return characters, a CR without the line feed that should follow it. He wrote two From headers. One had CR characters around the colon, so parser 1 didn’t treat it as a From header at all, and it checked the second one, his real address. Parser 2 then turned each bare CR into a proper line break. That cleaned up the fake header and pushed his real From line down into the body of the message, where nothing reads it as a header. The message left Apple with one From header, the forged one.
After Apple’s first round of changes, the researchers’ timeline says, the fix “merely blacklists the POC substring “admin”” in the From header, the word from his first proof of concept. A day after reporting that, they sent Apple a new working message from security@icloud.com. The second method, which Longin calls dot-peeling, abused the rule for lines that start with a full stop. Parser 2 followed that rule from the SMTP standard and parser 1 didn’t, which opened the same gap a different way.
Apple paid a $15,000 bounty in November 2024. The whole disclosure took about a year and a half.
Why DKIM passed
DKIM is a cryptographic signature over the message. You might expect a heavily rewritten message to break it. It didn’t, and the post explains why in one line: “DKIM signatures are created after parser 2 processed the message.”
Apple’s servers signed the message after the forgery had already happened. The signature was perfectly valid. It covered the forged From header because that was the From header by the time Apple signed. SPF passed because the message really did leave from Apple’s servers. DMARC passed because both of those results were for icloud.com, and the From address was at icloud.com too.
Every check did its job. None of them were built to answer the question that mattered here, which was whether this iCloud user was allowed to use that iCloud address.
I pasted their headers into my own analyzer
notspoofed.com has a header analyzer. You paste the raw headers from a message you received, and it shows the delivery path and explains why DMARC passed or failed. It runs entirely in the browser.
Get Josepollman’s stories in your inbox
Join Medium for free to get updates from this writer.
SEC Consult’s post prints the trace headers from one of their test messages as text: the Authentication-Results lines Gmail added, the Return-Path and the Received line. The From line only appears in their screenshots, so I added one myself, with the address from their proof of concept, plus a To and Subject line. Then I pressed Analyze.
The verdict was “GOOD, DMARC passed”. The explanation underneath: “The receiving server accepted this message as genuinely from icloud.com, authenticated by both SPF and DKIM.” The alignment table showed SPF and DKIM both passing for icloud.com, both “aligned (strict)” with the From domain.
That verdict is accurate as far as it goes. The message really was authenticated as icloud.com. But higher up in what I pasted, above the Received line, is this:
Return-Path: <attacker@icloud.com>The envelope sender, which in this test was the researchers’ own account, was attacker@icloud.com. The From line said tim.cook@icloud.com. My tool showed both addresses on the page and said nothing about the difference. It compares domains, because DMARC compares domains, and it didn’t compare the parts before the @.
What a pass actually certifies
DMARC was designed to stop people forging your domain from somewhere else. It does that well. At a domain like icloud.com, where every user shares the same domain, a pass can only mean “Apple’s servers sent this”. Which Apple user wrote that From line is a question for Apple’s own submission check, and nothing downstream can re-check it.
That isn’t a flaw in DMARC. It was never meant to answer that question. But the word “pass” is easy to read as more than it is: the email passed authentication, so it must be from who it says. For a shared domain, the honest reading is narrower. The provider vouched for the domain. You are trusting the provider’s own rules for everything after that.
The one trace that was left
The researchers point to the mismatch themselves. Mail from iCloud normally has the same address in the envelope and the From line, so a filter that knew that “could” flag it. They also add: “as it is, this is a legitimate and authenticated email.”
Could my analyzer flag it? It could compare the Return-Path with the From address. The hard part is not raising false alarms. Mismatches are normal for mailing lists, for newsletters sent through a delivery service, and for forwarded mail, where the envelope sender is often a bounce-handling address nobody reads. A warning on every mismatch would fire on a lot of ordinary marketing mail. A narrow check, only for big consumer mailbox domains where one person normally sends as themselves, would be quieter. I haven’t built it, and I’d want to test it on real mail before showing it to anyone.
What I’d take from it
If you approve payments or account changes partly because a message “passed authentication”, keep this case in mind. Every check passed on a forged address, at a major mail provider. Apple fixed this bug, but the gap between checking a domain and checking a person is built into how DMARC works. Sender identity at a shared mail domain rests on that provider’s own rules.
So a pass is where checking starts, not where it ends. For anything that moves money or changes access, confirm through a channel you already had, such as a phone number from your own records, not one from the message.
And if you read raw headers, look at the Return-Path next to the From line. In this case it was the only line that showed which account sent the message.
The header analyzer I used is free on notspoofed.com, needs no account, and runs in your browser.
Source: Timo Longin, “From: anyone@icloud.com”, SEC Consult blog, 1 October 2026, including its disclosure timeline. Read on 19 October 2026. Jose Pollman builds notspoofed.com.
