Apple has told 404 Media that it fixed the Hide My Email vulnerability that could expose the real address behind an iCloud+ alias, saying a server-side patch deployed on 3 July 2026 fully resolved the issue. The claim, reported on 21 July, came more than a year after researcher Tyler Murphy of EasyOptOuts first disclosed the flaw to Apple in June 2025, and three weeks after 404 Media made it public. We covered the flaw in detail when it surfaced on 3 July. The same day as Apple’s fix claim, AppleInsider reported that it had reproduced the behaviour on 17 July, two weeks after Apple’s claimed repair date. Testing by 404 Media on 21 July, however, could no longer reproduce the flaw, and Murphy and EasyOptOuts co-founder Ben Weiner now say the bug has been fixed. What remains contested is the timeline: why the flaw was still reproducible two weeks after Apple’s claimed repair date, and whether the patch rolled out in stages. That matters well beyond consumer security, because the leak mechanism runs straight through email infrastructure.
How the flaw worked
With the patch claimed, the mechanism has now been disclosed, and it is strikingly low-tech. When a message sent to a Hide My Email alias was automatically rejected as spam by the receiving infrastructure, the bounce exposed the user’s real underlying address to the sender, in mail logs, rather than the alias. No compromise of the account was needed. A legitimate message rejected in error would do it. As we reported at the time, Apple had known about the issue for over a year, and had told the researcher in March 2026 that it was fixed when it was not.
That history is why the AppleInsider reproduction carries weight. Apple has already claimed one fix for this flaw that did not hold. AppleInsider says its 17 July test showed a sender in possession of a specific alias could still reveal the real address behind it, and that it has asked Apple for comment. The most recent testing suggests the fix now holds. What Apple has not explained is why the flaw remained reproducible on 17 July, when deployment actually completed, or whether 3 July marked the start of a rollout rather than the end of one. AppleInsider has asked; Apple has not answered. The honest description is that the leak appears closed, and the fix date remains disputed. This is the second time Apple has attached a date to a fix for this flaw that did not survive testing.
The residual exposure does not depend on the dispute
Even taking Apple’s patch date at face value, the researchers behind the disclosure warn that the risk does not end there. Mail transfer logs are routinely retained by third parties, and any real address exposed in a rejected delivery before the fix may still sit in those logs today. EasyOptOuts recommends treating any Hide My Email alias created before 7 July 2026 as potentially exposed, and notes that affected users cannot check for themselves, because the triggering messages never reached their inboxes. A proposed class action filed in California last week seeks recovery of iCloud+ subscription costs over the feature’s privacy claims.
The scope has limits worth stating plainly. An attacker needed to already hold a specific alias, there is no public evidence of coordinated exploitation, and the flaw exposed no passwords and granted no account access. What it broke was the one promise the product exists to keep.
Why ESPs and senders should care
The leak vector was bounce handling, which makes this an email-infrastructure story wearing a consumer-privacy headline. It is worth walking through the mechanics, because they determine exactly where the exposure landed. Hide My Email is a forwarding service. Mail to the alias is accepted by Apple, then relayed onward to the user’s real mailbox provider. When that downstream provider rejected the forwarded message as spam, a delivery status notification travelled back towards the original sender, and the bug was that the notification revealed the real destination address rather than only the alias. Nothing exotic happened. Standard DSNs under RFC 3464 are designed to report the failed recipient, and commonly include the remote server’s rejection transcript. The privacy failure was that Apple did not rewrite them before passing them back.
Follow the DSN one step further and the ESP implication becomes concrete. For commercial mail, the envelope return path is almost never the brand’s own inbox. It is a bounce address on the ESP’s infrastructure, because that is how automated bounce processing works. So during the vulnerable window, which runs at least from mid-2025 to early July 2026, notifications for forwarded-then-rejected messages flowed into ESP bounce pipelines, and those pipelines routinely retain raw bounce messages or parsed diagnostic content for troubleshooting. The consequence is that bounce archives from the window may hold documents pairing an iCloud alias with the real address behind it. That pairing is precisely the cross-reference Hide My Email exists to prevent. It arrived passively, through no fault of the sender, but it is personal data in storage all the same.
That suggests three specific checks rather than general unease. First, retention: establish whether stored bounce and NDR data covering the window falls inside retention policies and the privacy commitments made to subscribers. Second, parser behaviour: confirm that bounce parsers key on the envelope and the structured DSN fields, and do not extract addresses from diagnostic text. A parser that harvests addresses from bounce bodies could have written a recipient’s real address into suppression lists or subscriber records without anyone deciding to collect it. Third, and simplest: no leaked address should ever be mailed or matched against. No consent attaches to it, and acting on it converts a passive exposure into an active one.
The honest caveat is that the exposure is conditional. It required a forwarded message to be rejected as spam downstream during the window, and many programmes will find nothing when they look. But the check is cheap and the question is concrete, which is more than most privacy incidents offer. For fraud and identity teams, the wider lesson stands regardless: alias services are load-bearing infrastructure for privacy-sensitive accounts, and the mapping between alias and real identity can leak through ordinary rejection paths. Suppression and bounce processing sit inside the privacy perimeter, not outside it.
Note: 404 Media reports it can no longer reproduce the flaw, and researchers Tyler Murphy and Ben Weiner of EasyOptOuts say the bug has been fixed. Apple has not explained why the flaw remained reproducible on 17 July, two weeks after its claimed fix date. The residual exposure described is unchanged.
More details: 404 Media on Apple’s fix claim, AppleInsider’s 17 July reproduction, and the researchers’ statement via MacRumors.
