I guess the vulnerability should work as follows (I haven't tried it), you send an email with a very large attachment to a "hide my email" address, the server that receives it (private.icloud.com) forwards it to the email server registered in iCloud which, being the very large attachment, sends a response email (from the real address) with the rejected email message. It's the first thing I would try.
Yeah it’s a good guess. I was also thinking there might be some header leaks. Or possibly if you return server busy on the first attempt or something like this, some sort of edge case the developers overlooked.
Apple rewrites the From address of before forwarding so that replies go back through its SMTP servers. Those SMTP servers should rewrite the reply not to leak information.
I normally don't reply to emails sent to "Hide My Email" addresses I create, but I just did so to see what might get leaked and see one obvious issue with having a DMARC record.
I have a DMARC record setup on my personal domain (the one to which Hide My Email's get forwarded). e.g.:
So let's say I create "Hide My Email" address <hide_me@icloud.com>.
I send an email to <hide_me@icloud.com> from <rando@gmail.com>.
I receive this email at <actual@example.org> with a rewritten from <rando_at_gmail_com_XXXXXXXX_XXXXXXX@icloud.com>.
This is so that when I reply from <actual@example.org> the mail goes via the iCloud SMTP servers so that they can rewrite <actual@example.org> as <hide_me@icloud.com>
So far so good. Except the iCloud SMTP servers are inserting a diagnostic SMTP header:
So now <rando@gmail.com> minimally knows that <hide_me@icloud.com> is someone with an address <@example.org>.
Secondarily, I happen to use Fastmail and that's also disclosed by Hide My Email since it retains all received message headers. The iCloud forwarding servers should ideally drop all of the received message headers and start with a fresh envelope.
If I have Hide My Email forward to my <actual@icloud.com> address instead of my <actual@example.org> personal domain then this isn't an issue. Hide My Email just doesn't work well when forwarding to personal domains, at least if they aren't hosted with Apple.
I am starting to think all these "privacy" features merely exist as excuse for getting people to hand off their mails to Apple. Clearly the all do not deliver on the intended functionality, but the proxy/relay routing happens to some extent anyway. How convenient. If you were a company promising its users all the privacy, but secretly not giving a fuck beyond collecting user traffic and meta data, wouldn't you expect the state of things to look exactly like that? I mean, how could you explain this any other way, considering the size of Apple and the relative ease of developing such features reliably? Apple is hardly breaking ground here.
Fetching any email content is always worse than blocking it, because the typical threshold for spam is "is this inbox monitored". If that is true, then blast it with spam. And fetching anything ever proves that the inbox is monitored.
At least in Gmail, downloading content (e.g. images) is disabled by default for suspicious emails. There is no way for the sender to know if it’s monitored unless this is disabled by explicit user action.
My guess would be it has nothing to do with email itself. Maybe it's some iCloud API that accepts obfuscated emails but returns the original email in the response, or an ID which can be used to retrieve the iCloud email from another API endpoint. Could be as simple as an "add contact/friend" feature in some Apple product (like a mail client, or a file sharing service) that resolves the obfuscated email to the original iCloud account.
In the comment section of the 404media article Joseph Cox writes when asked whether it reveals the icloud address the email is forwarded to or the apple id [0]:
> It reveals the email linked to the Apple ID.
So I assume you are right that it has nothing to do with the email itself, but prob some other service that links the obfuscated email to the appleid of the user.
I think they are hinting at the ad hoc "use hidemyemail" feature within e.g. the mail client.
I don't know what I am doing, but from a quick test, the mail header is at least disclosing the internal recipient (mail@host.com) "translation address" (as mail_at_host_com_12345abc_12345abc@icloud.com) and an alias creation date. But the latter seems to be a unix timestamp related to the real address alias creation time and is identical between an hidemyemail mail and a normal one, so there may be already a possible information leak for correlation. Side note, it also seems like the sending hidemyemail server contains the unsuspicious name "junk_forwarder". Lol.
Disclosing an address as alias and particularly as throwaway alias (through the translation address and server) already seems kinda counterproductive to begin with, but I would bet you can use this information somehow to get the sender "translation address". Either by some API interaction, or by messing with the mail header scrubbing of the translation service somehow. A server named "junk_forwarder" may be a little more lenient about what to accept or not.
Edit: Can confirm the Reddit comment linked. You simply send an email to the HME address, reply from Apple mail client, and then the real mail address gets disclosed. Mind you not even hidden. It's shown as sending from the HME alias in mail, but I received the mail with the real address as sender......... Jesus fucking christ, Apple. Did you even test this a little?
...which makes it seem like perhaps the attack surface is limited to scenarios involving a Yahoo/Sonic address (assuming that Apple only sends X-Sonic-* headers when talking to those providers that want to see it), which might be a small percentage of users.
As someone who uses this feature I never send messages from a hide my email address as I only use it for random email signups. Am I still at risk of having my email exposed??? It’s also handy for using for free trials lol.
It’s hard for me to assess how real this risk is. Without details, we’re just extrapolating from circumstantial vibes.
What’s described sounds like it might be spooky. It might also be a magic trick to some degree… Mr. Cox’s PoC—“I gave a fresh Hide-My-Email alias to a guy who knows who I am, and he told me the email on my Apple ID”—is consistent with the claimed behavior but not exactly watertight.
It also sounds like it might be the sort of thing that’s either “just how the email ecosystem works” or mitigable by covert means. For example, if Apple can identify exploit attempts from its privileged vantage over its infrastructure, maybe that’s the basis for its relaxed impact assessment.
I’m reminded of Amazon’s risk assessment with respect to some Quick bug recently [0]: “yeah, it’s bad, but we checked and there are literally zero people other than you who’ve ever used that feature that way.”
Or maybe it’s the kind of thing that requires a structural sort of tradeoff to conclusively fix. I could imagine the exposure mechanism having something to do with their forthcoming move to segregate aliases to their own “private.icloud.com” domain.
(A move at which Mr. Cox swipes in the 404 Media article, too, of course, but hey—“impact journalism.”)
And then, since we have only vibes to go on, there’s the judgment reflected in the researcher’s email to Apple:
> “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
I can only hope that was a sardonic moment of frustration quoted out of context… Hide My Email is “sold” as a tiny tiny bonus feature of a much bigger iCloud+ product. But as-quoted, it’s giving a little bit of Chicken Little… I’m reminded of the time somebody demanded that a firm I’m familiar with halt all sales (and pay hush money) because of a CRITICAL SECURITY HOLE: you could access the contents of a password field by typing the password in the field, pressing F12 in the browser, and typing $(“#pw-input”).value …
If the flaw really is the sort of thing that required fundamental product changes to fully address—like this domain segregation thing—a year doesn’t seem wild at all to make that transition safely and at scale. Especially if they identified effective mitigations in the meantime.
> > “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
> I can only hope that was a sardonic moment of frustration quoted out of context
I didn't make my point clearly there, and I think it makes more sense in context, but it was a sincere suggestion that Apple could stop allowing new people to use Hide My Email. There are many other email aliasing services, so they wouldn't be depriving people of a unique offering. At the time, I wasn't aware that Hide My Email was only available as part of iCloud+. All I knew was that it wasn't free.
Makes sense to me! I'd gone off the 404 Media article originally linked. The way you put it in your blog timeline (now the link of record) makes perfect sense to me:
> We hope that Apple will take steps to limit the attack surface area even before the vulnerability is fixed. Disabling creation of new Hide My Email addresses could be helpful. It also seems responsible to notify all Hide My Email users of the risk.
Thank you for your work, and your persistence against our Sphinx-like overlords!
Thanks for everything y'all do with Easy Opt Outs. I've put a number of family members and acquaintances onto it. I'm glad this service exists at an actually affordable rate
I think "real email" address is underselling it, since that's commonly the apple-ID, which is the gateway to some people's whole digital existence. Not to mention the fact, you tend to use hidemyemail in particular for services you don't want any identity leaked to. The "real email" may contain your legal name already.
I use this feature often and I'm very disappointed. Depending on the exploit, I'm awaiting to join a class action lawsuit. I'm constantly humiliated by believing Big Tech's security promises and I've had enough. I suspect that this is yet another intentional backdoor. When these security systems fail, people like me experience violence.
I've been going back and forth with Apple about it for a year. We don't feel comfortable releasing the exploit details even though they're being slow. We think enough people rely on Hide My Email for personal safety that it would be irresponsible.
I guess the vulnerability should work as follows (I haven't tried it), you send an email with a very large attachment to a "hide my email" address, the server that receives it (private.icloud.com) forwards it to the email server registered in iCloud which, being the very large attachment, sends a response email (from the real address) with the rejected email message. It's the first thing I would try.
Yeah it’s a good guess. I was also thinking there might be some header leaks. Or possibly if you return server busy on the first attempt or something like this, some sort of edge case the developers overlooked.
Apple rewrites the From address of before forwarding so that replies go back through its SMTP servers. Those SMTP servers should rewrite the reply not to leak information.
I normally don't reply to emails sent to "Hide My Email" addresses I create, but I just did so to see what might get leaked and see one obvious issue with having a DMARC record.
I have a DMARC record setup on my personal domain (the one to which Hide My Email's get forwarded). e.g.:
So let's say I create "Hide My Email" address <hide_me@icloud.com>.
I send an email to <hide_me@icloud.com> from <rando@gmail.com>.
I receive this email at <actual@example.org> with a rewritten from <rando_at_gmail_com_XXXXXXXX_XXXXXXX@icloud.com>.
This is so that when I reply from <actual@example.org> the mail goes via the iCloud SMTP servers so that they can rewrite <actual@example.org> as <hide_me@icloud.com>
So far so good. Except the iCloud SMTP servers are inserting a diagnostic SMTP header:
So now <rando@gmail.com> minimally knows that <hide_me@icloud.com> is someone with an address <@example.org>.
Secondarily, I happen to use Fastmail and that's also disclosed by Hide My Email since it retains all received message headers. The iCloud forwarding servers should ideally drop all of the received message headers and start with a fresh envelope.
If I have Hide My Email forward to my <actual@icloud.com> address instead of my <actual@example.org> personal domain then this isn't an issue. Hide My Email just doesn't work well when forwarding to personal domains, at least if they aren't hosted with Apple.
That timeline was exactly my experience with Apple here - https://www.grepular.com/Apples_Protect_Mail_Activity_Doesnt...
They don't seem to know or care what is going on with their own email systems.
Has anyone seen Protect Mail Activity get re-enabled after you've disabled it? I wrote about that a few days ago: https://lapcatsoftware.com/articles/2026/6/6.html
I’m still mildly annoyed every email I send using Mail has my IP embedded in it
Source? I don't think this is true. Doesn't seem to be the case for me. Maybe your email provider attaches your IP address?
7 replies →
Why? Something real, or just nonspecific vibes?
I am starting to think all these "privacy" features merely exist as excuse for getting people to hand off their mails to Apple. Clearly the all do not deliver on the intended functionality, but the proxy/relay routing happens to some extent anyway. How convenient. If you were a company promising its users all the privacy, but secretly not giving a fuck beyond collecting user traffic and meta data, wouldn't you expect the state of things to look exactly like that? I mean, how could you explain this any other way, considering the size of Apple and the relative ease of developing such features reliably? Apple is hardly breaking ground here.
Fetching any email content is always worse than blocking it, because the typical threshold for spam is "is this inbox monitored". If that is true, then blast it with spam. And fetching anything ever proves that the inbox is monitored.
My impression as a Mutt user (which never downloads linked content) is that spammers don’t really care about whether an inbox is “monitored” or not.
At least in Gmail, downloading content (e.g. images) is disabled by default for suspicious emails. There is no way for the sender to know if it’s monitored unless this is disabled by explicit user action.
1 reply →
Is it based on mail undeliverable errors? Or attempts to login using IMAP or SMTP with it? Or is it exposed during the SMTP protocol?
My guess would be it has nothing to do with email itself. Maybe it's some iCloud API that accepts obfuscated emails but returns the original email in the response, or an ID which can be used to retrieve the iCloud email from another API endpoint. Could be as simple as an "add contact/friend" feature in some Apple product (like a mail client, or a file sharing service) that resolves the obfuscated email to the original iCloud account.
In the comment section of the 404media article Joseph Cox writes when asked whether it reveals the icloud address the email is forwarded to or the apple id [0]:
> It reveals the email linked to the Apple ID.
So I assume you are right that it has nothing to do with the email itself, but prob some other service that links the obfuscated email to the appleid of the user.
[0] https://www.404media.co/apple-hide-my-email-vulnerability-re...
I think they are hinting at the ad hoc "use hidemyemail" feature within e.g. the mail client.
I don't know what I am doing, but from a quick test, the mail header is at least disclosing the internal recipient (mail@host.com) "translation address" (as mail_at_host_com_12345abc_12345abc@icloud.com) and an alias creation date. But the latter seems to be a unix timestamp related to the real address alias creation time and is identical between an hidemyemail mail and a normal one, so there may be already a possible information leak for correlation. Side note, it also seems like the sending hidemyemail server contains the unsuspicious name "junk_forwarder". Lol.
Disclosing an address as alias and particularly as throwaway alias (through the translation address and server) already seems kinda counterproductive to begin with, but I would bet you can use this information somehow to get the sender "translation address". Either by some API interaction, or by messing with the mail header scrubbing of the translation service somehow. A server named "junk_forwarder" may be a little more lenient about what to accept or not.
Edit: Can confirm the Reddit comment linked. You simply send an email to the HME address, reply from Apple mail client, and then the real mail address gets disclosed. Mind you not even hidden. It's shown as sending from the HME alias in mail, but I received the mail with the real address as sender......... Jesus fucking christ, Apple. Did you even test this a little?
4 replies →
As someone who doesn't rely on this feature, I'd love to know now as well, but perhaps the etiquette in public would be to align ourselves with:
> we will not discuss or disclose the details of the exploits until they're fixed.
But if there's a public forum where the cat's already out of the bag, then game on. Perhaps this:
https://www.reddit.com/r/apple/comments/1ukilw1/apple_hide_m...
...which makes it seem like perhaps the attack surface is limited to scenarios involving a Yahoo/Sonic address (assuming that Apple only sends X-Sonic-* headers when talking to those providers that want to see it), which might be a small percentage of users.
I wonder if it is replies to delivery receipts that causes this problem
archive link: https://archive.vn/mCbBw
As someone who uses this feature I never send messages from a hide my email address as I only use it for random email signups. Am I still at risk of having my email exposed??? It’s also handy for using for free trials lol.
It’s hard for me to assess how real this risk is. Without details, we’re just extrapolating from circumstantial vibes.
What’s described sounds like it might be spooky. It might also be a magic trick to some degree… Mr. Cox’s PoC—“I gave a fresh Hide-My-Email alias to a guy who knows who I am, and he told me the email on my Apple ID”—is consistent with the claimed behavior but not exactly watertight.
It also sounds like it might be the sort of thing that’s either “just how the email ecosystem works” or mitigable by covert means. For example, if Apple can identify exploit attempts from its privileged vantage over its infrastructure, maybe that’s the basis for its relaxed impact assessment.
I’m reminded of Amazon’s risk assessment with respect to some Quick bug recently [0]: “yeah, it’s bad, but we checked and there are literally zero people other than you who’ve ever used that feature that way.”
Or maybe it’s the kind of thing that requires a structural sort of tradeoff to conclusively fix. I could imagine the exposure mechanism having something to do with their forthcoming move to segregate aliases to their own “private.icloud.com” domain.
(A move at which Mr. Cox swipes in the 404 Media article, too, of course, but hey—“impact journalism.”)
And then, since we have only vibes to go on, there’s the judgment reflected in the researcher’s email to Apple:
> “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
I can only hope that was a sardonic moment of frustration quoted out of context… Hide My Email is “sold” as a tiny tiny bonus feature of a much bigger iCloud+ product. But as-quoted, it’s giving a little bit of Chicken Little… I’m reminded of the time somebody demanded that a firm I’m familiar with halt all sales (and pay hush money) because of a CRITICAL SECURITY HOLE: you could access the contents of a password field by typing the password in the field, pressing F12 in the browser, and typing $(“#pw-input”).value …
If the flaw really is the sort of thing that required fundamental product changes to fully address—like this domain segregation thing—a year doesn’t seem wild at all to make that transition safely and at scale. Especially if they identified effective mitigations in the meantime.
Then again, maybe they really are negligent…
[0] https://www.theregister.com/columnists/2026/05/13/aws-patche...
> > “It seems that ending new sales of Hide My Email until the problem is fixed would be an effective way to limit the number of customers at risk. Is that an option?” Murphy wrote back.
> I can only hope that was a sardonic moment of frustration quoted out of context
I didn't make my point clearly there, and I think it makes more sense in context, but it was a sincere suggestion that Apple could stop allowing new people to use Hide My Email. There are many other email aliasing services, so they wouldn't be depriving people of a unique offering. At the time, I wasn't aware that Hide My Email was only available as part of iCloud+. All I knew was that it wasn't free.
Makes sense to me! I'd gone off the 404 Media article originally linked. The way you put it in your blog timeline (now the link of record) makes perfect sense to me:
> We hope that Apple will take steps to limit the attack surface area even before the vulnerability is fixed. Disabling creation of new Hide My Email addresses could be helpful. It also seems responsible to notify all Hide My Email users of the risk.
Thank you for your work, and your persistence against our Sphinx-like overlords!
We put up a timeline of the disclosure here: https://easyoptouts.com/guides/apple-hide-my-email-is-leakin...
Thanks for everything y'all do with Easy Opt Outs. I've put a number of family members and acquaintances onto it. I'm glad this service exists at an actually affordable rate
Thanks! We'll make that the main URL and put the submitted link in the toptext.
Can you comment on this: https://news.ycombinator.com/item?id=48752294 ?
To me it seems, at least in this instance there is not even an exploit needed and the feature apparently is just broken beyond belief.
I think "real email" address is underselling it, since that's commonly the apple-ID, which is the gateway to some people's whole digital existence. Not to mention the fact, you tend to use hidemyemail in particular for services you don't want any identity leaked to. The "real email" may contain your legal name already.
That's disappointing, both that the vulnerability exists in the first place, and that Apple takes over a year to not even fix it.
They're a struggling company and can't hire top talent.
Not as disappointing as the discover's decision to leave affected users ignorant and hence at risk.
Related:
Apple is about to make Hide My Email useless
https://news.ycombinator.com/item?id=48559935
Shameless plug
https://github.com/webmonch/hide-my-mail-cloudflare
The value of Hide My Email, SimpleLogin is that you can blend in with the crowd. If you use your own domain then the domain becomes the common link.
Why not just use cloudflare with catch all email routing?
"This is the one thing we didn't want to happen"
Ok, yet another reason I have a totally separate burner Gmail instead of complicating things like this.
I use this feature often and I'm very disappointed. Depending on the exploit, I'm awaiting to join a class action lawsuit. I'm constantly humiliated by believing Big Tech's security promises and I've had enough. I suspect that this is yet another intentional backdoor. When these security systems fail, people like me experience violence.
[dead]
[dead]
[flagged]
Sorry I'm not seeing how your comment is relevant to the orignal post, can you clarify?
The post is about a vulnerability in Apple under CEO Tim Cook, who did horrible things after Steve Jobs died — most importantly, changing the UI/UX.
I think you should formally write to Apple and give notice of 30 days to contact you or you will reveal it.
Send it to the USA media and regulator too
I've been going back and forth with Apple about it for a year. We don't feel comfortable releasing the exploit details even though they're being slow. We think enough people rely on Hide My Email for personal safety that it would be irresponsible.
> We think enough people rely on Hide My Email for personal safety that it would be irresponsible.
I am guessing you haven't tried that excuse on the users your witholding is leaving exposed.
5 replies →