On 1 October 2026, SEC Consult published the technical account of two flaws its researcher Timo Longin found in Apple's iCloud mail infrastructure. With a free iCloud account, an attacker could send mail that appeared to come from any address at icloud.com — and the message passed SPF, DKIM and DMARC on the way out.

Apple paid a 15,000 dollar bounty. The first report went in on 21 May 2024. The last fix landed in December 2025.

Two parsers, one message

Both bugs are the same species: two pieces of the same pipeline reading one message and disagreeing about what it says.

The first involves carriage-return characters placed inside the From header. The parser that validated the message did not see the manipulated field as a normal sender header, so it had nothing to check. A parser further down the line tidied the message before delivery and turned it into a perfectly valid sender header — the one the recipient's client then displayed.

The second abuses SMTP dot-stuffing, the decades-old rule for handling lines that begin with a period, which exists so that a line of message text cannot be mistaken for the end of the message. Different parsers in Apple's pipeline applied that rule differently, and the same trick worked again: a From header invisible at the check, present at delivery.

This is the same failure that put FortiMail on CISA's exploited list this week — a validator and an executor that disagree about where a field ends. There it was a null byte and a file path. Here it is a carriage return and a sender name.

The checks were not bypassed

The part worth sitting with is that none of the three authentication checks failed, and none of them was tricked. They all answered their question correctly.

SPF asks whether the sending server is permitted to send for that domain. It was. The mail really did leave Apple's infrastructure.

DKIM asks whether the message carries a valid cryptographic signature from the domain. It did. Apple applies its signature after the stage where the header was mangled, so Apple signed the forged version itself.

DMARC asks whether the visible sender aligns with what was authenticated. It did. The From line said icloud.com, the signature said icloud.com, and they matched.

Three controls, all green, on a message whose sender was a lie. This is not a failure of the standards. It is what the standards actually promise, read precisely: they attest that a domain's infrastructure sent and signed a message. They say nothing about whether the sender line is true. That gap is harmless as long as a provider's own pipeline cannot be made to disagree with itself — which is the whole assumption these two bugs removed.

Why an icloud.com sender is worth more than a lookalike domain

Most spoofing in the wild uses a domain the attacker controls, dressed to look like someone else's. Those get caught: by reputation, by domain age, by the warning banners mail gateways add to external senders, and by anyone who reads the address closely.

A message genuinely sent and signed by icloud.com has none of those tells. It is not a lookalike. The domain is old, the reputation is Apple's, the signature is real, and every automated check endorses it. A recipient doing exactly what security training tells them — check the sender, look for the authentication indicator — would have been led to the wrong conclusion by doing the right thing.

That is the practical value here, and it is why the bounty is not surprising.

The fix took nineteen months

The disclosure timeline is the other story. Reported 21 May 2024. Apple changed how it handled the original proof of concept, which closed that specific demonstration. Longin then found a second way through the same inconsistency, and the complete fix did not land until December 2025.

That pattern — the first patch addresses the proof of concept rather than the class of bug, and the researcher comes back — is the ordinary outcome when a flaw is a disagreement between components rather than a mistake in one of them. There is no single line to correct. Making the pipeline agree with itself means changing how several stages read the same bytes, which is a larger change than anyone wants to ship against one report.

What to do

  • Stop treating an authentication pass as a sender verification. SPF, DKIM and DMARC tell you a domain's infrastructure handled the message. They do not tell you the person named in the From line wrote it.
  • Keep the controls that do not depend on the headers. Payment and access changes requested by email need confirmation on another channel, and no amount of green authentication substitutes for that.
  • If you build mail handling, normalise once. The bug class here is two stages parsing the same message differently, so the defence is deciding what a message says at one point and carrying that decision forward.
  • Give researchers the second look. Both of these existed because the first fix addressed the demonstration rather than the inconsistency behind it.

What is not established

  • Whether either flaw was ever used against anyone. Neither Apple nor SEC Consult says so, and mail spoofed this way would be very hard to identify after the fact.
  • What Apple changed internally, beyond that the original proof of concept stopped working and the complete fix arrived in December 2025.
  • Whether the same inconsistency exists in other large mail providers. The technique is general; only Apple's implementation was tested here.
  • Why the complete fix took nineteen months from first report.