If you used Apple’s Hide My Email to keep a store, newsletter, or unfamiliar website away from your real inbox identity, the alias may not have done its one job. Apple has patched a flaw that could reveal the personal address behind an alias when an incoming message was rejected as spam, but researchers warn that earlier disclosures may remain in third-party mail logs. The practical response is not panic or abandoning the feature. It is replacing old aliases where the separation still matters.
The flaw was reported to Apple in June 2025, according to 404 Media’s follow-up. Apple told the publication that a patch deployed on July 3, 2026, fully resolved the problem. Tyler Murphy, the EasyOptOuts co-founder who found the issue, and fellow co-founder Ben Weiner set a more cautious dividing line: they said an alias created before July 7, 2026, may have exposed its linked address and that the disclosure could remain in outside logs.
How an email alias exposed the address behind it
Hide My Email is an iCloud+ feature that creates random addresses in place of a user’s personal one. Messages sent to an alias forward to an iCloud Mail address or another address associated with the user’s Apple Account. Replies still appear to come from the alias. Apple says users can create as many aliases as needed, label them, and deactivate or delete them when they are no longer useful, according to the company’s support documentation.
That arrangement is useful because each service can receive a distinct address without learning the personal address behind it. The vulnerability broke that separation through the mail system’s response to rejected messages. Murphy and Weiner told 404 Media that “the leak was triggered simply by an email being automatically rejected as spam, even if it was a legitimate message.” The rejected message did not need to reach the user’s inbox, so reviewing the spam folder cannot show whether the address was exposed.
The original 404 Media report withheld the technical exploitation details while the problem remained unpatched. The publication said it verified the vulnerability against one of its own hidden addresses. That distinction matters: the reporting established that the leak worked, while avoiding instructions that could have turned an unresolved privacy flaw into a recipe.
A patch cannot erase an earlier disclosure
Apple’s patch closes the reported path, but it cannot remove an address from systems that may have recorded it before the fix. Murphy put the remaining uncertainty plainly in the follow-up: “The bug that caused Apple’s Hide My Email to leak hidden email addresses to senders has been fixed. However, we don’t think the risk to Hide My Email users has been eliminated.”
The researchers did not claim to know how many people were affected. Murphy said, “We don’t know the full scope of the issue, but in our limited tests with volunteers, 100% of Hide My Email addresses were exploitable.” That is a result from a limited volunteer test, not a measurement of every account. It supports treating the issue as real without turning it into an unsupported estimate of total exposure.
The timing also deserves care. Apple said its fix went live on July 3, while Murphy and Weiner warned about aliases created before July 7. For readers deciding what to replace, the researchers’ later cutoff is the safer operational boundary because it does not ask users to guess when the patch reached every relevant system. This is a recommendation based on their warning, not a claim that every older alias was actually exploited.
What users can do now
Start with the aliases where anonymity has the highest value: accounts tied to your identity, services you do not trust, mailing lists that may share data, and sign-ups created specifically to separate one activity from another. If an alias predates July 7, create a replacement and update the account using it. Keep the personal inbox address behind that alias unchanged unless you have evidence it was exposed somewhere harmful. The reporting establishes a possible disclosure path, not proof that every alias was targeted.
Once the relevant account accepts the new alias, deactivate the old one. Apple’s iCloud.com instructions say mail sent to a deactivated address is returned to the sender. An inactive address can be reactivated if it turns out that a service still depends on it. Apple also permits permanent deletion, but only after deactivation, and warns that a deleted alias cannot be restored.
Do not rely on the inbox as an audit trail. Because the triggering mail could be rejected before delivery, the researchers said it might not appear in the spam folder. A careful replacement process is therefore more useful than hunting for a message that may never have arrived. Keep a record of which account used each alias, change the most sensitive ones first, and deactivate an old address only after confirming the replacement works.
What This Means
Hide My Email still provides a useful layer between a personal inbox and the sites that demand an address. The incident shows the limit of that layer: privacy can fail not only where an alias is generated, but also in the mail infrastructure that forwards, rejects, and reports delivery failures.
It also changes how aliases should be treated. A random address is not a permanent shield. It is a replaceable identifier. Apple’s controls already support that model through labels, deactivation, reactivation, and deletion. Using those controls selectively is more proportionate than changing a primary email account with no evidence of misuse.
The Bottom Line
Apple says the Hide My Email flaw is fixed, but aliases created before July 7 may have disclosed the real addresses behind them. Replace older aliases where privacy matters most, verify the new address works, then deactivate the old one rather than assuming the patch erased any earlier exposure.