Apple Fixes Hide My Email Vulnerability After 404 Media Exposure
Apple Fixes Hide My Email Vulnerability After 404 Media Coverage
Apple finally patched a critical flaw in its Hide My Email feature that exposed users' real addresses, but only after 404 Media highlighted the issue. Despite knowing about the bug for over a year, the company delayed fixing it until public pressure mounted. This negligence has already sparked a class action lawsuit, leaving many to wonder if their private data was already leaked through spam logs before the July patch.
We don't think the risk to Hide My Email users has been eliminated. Because non-malicious emails could bounce, revealing your hidden email address, and because mail transfer logs are often retained, we'd assume that any hidden email address linked to a Hide My Email address created before July 7, 2026, may have been exposed and could still be in third-party logs.
- satvikpendem
But Apple did not yet walk back that they wanted a single dedicated domain for private emails, privacy.icloud.com, such that it'd be easy for any host to block them.
- argee
I have a question I wasn’t sure how to ask HN that is tangentially related to this. I’m the developer of an app where people can add other users to their workspaces, via email. The way this currently works is that your email gets added to the workspace and then when you log in with that email, you get access.
Now, this of course fails with “hide my email”. What’s the appropriate/standard way to handle this? Should I be using urls with invite codes instead of associating the email itself with access? I’m a little hesitant to do that since the code would have to persist in session and the business logic would have to occur on the login portal, since the mobile/desktop apps don’t share web cookies. Is deep linking the answer?
- js2
> Now Apple says it has been fixed, we can add that, in simple terms, it required sending a target Hide My Email user a message that got rejected as spam.
Frustratingly vague. I was unable to reproduce when the original article was posted. I did not test exhaustively, but I was able to get HME to reject messages in various ways (mostly by sending oversize messages) and none disclosed my real address because they were rejected before any rewriting to the final address occurred. And in looking at messages that were delivered, I didn't see any additional SMTP servers in the path that would reject the message.
The most I was able to leak was a DMARC header showing my real domain, but even that only occurred when I replied to an HME email from my real (non-icloud.com) domain. When I updated HME to use my icloud.com address, even that leak went away (but it did make it clear that HME was not sanitizing message headers).
Maybe if you have HME setup to forward to a non-icloud.com domain and that domain's SMTP servers rejected the message as spam, I can see how this could occur. But if forwarding to an icloud.com address, no way this should've been able to happen in the first place.
I wish they'd included a sample message including full headers to see the vulnerability in action. Where in the delivery path was the bounce being generated?
I want more details.