Hide My Email is the iCloud+ feature that generates a disposable, random address so users can hand it to a website or a mailing list without ever revealing the real inbox behind it, the entire value of the feature is that the two addresses stay unlinkable. Researchers Tyler Murphy and Ben Weiner of EasyOptOuts found that the link was never as clean as advertised: sending a message to a Hide My Email alias that gets rejected as spam causes the recipient’s real address to appear in the mail server logs generated during that bounce. In testing, the technique revealed the real address behind an alias 100 percent of the time. They reported it to Apple in mid-2025. Apple told them it was fixed in March 2026. It was not. Apple told them it was fixed again on June 30. It was not. A working patch finally shipped on July 3, and Apple told 404 Media the vulnerability was fully resolved. AppleInsider reproduced the exact same leak on July 17, two weeks later.
A privacy feature that failed the one test that matters
The pattern here is more instructive than the bug itself. Hide My Email is not a minor setting, it is a feature Apple markets specifically as a privacy control, sold to users who are explicitly trying to keep a real address out of some other company’s database. A privacy feature that leaks the thing it exists to hide, for over a year, through three separate fixed announcements, says something uncomfortable about how thoroughly vendor claims get re-tested before they are trusted. Apple’s current guidance is that aliases are only reliably safe for mail processed after July 7, meaning mail transfer logs generated before that date, sitting on servers that already processed bounced messages, may still contain real addresses tied to aliases their owners believed were anonymous.
The bug class is the useful part, not the vendor
Bounce handling, error logging, and mail transfer logs are exactly the kind of infrastructure that gets built once, works, and never gets revisited from a privacy angle again. This class of bug, a real identifier leaking into a log or header path that was never designed to hold personal data, is common in systems well beyond email aliasing: support ticket systems, webhook retries, API error responses, and background job logs all tend to carry more identifying detail than anyone intended once something fails. For any organisation handling EU personal data under GDPR, a failure path that exposes an identifier the primary system was built to protect is a data minimisation problem regardless of whether the vendor is Apple or your own backend. The lesson from Hide My Email is not “avoid iCloud+”, it is “test what happens when your own privacy-preserving system fails, not just when it succeeds.”
If you want a privacy engineering review of how your own systems handle bounces, retries, and error logging, or a data minimisation audit to confirm personal identifiers are not leaking into places your GDPR documentation says they cannot go, contact Excello Digital. We help European organisations verify that privacy controls hold up under failure, not just under normal operation.