{"id":70553,"date":"2026-07-22T00:22:16","date_gmt":"2026-07-21T22:22:16","guid":{"rendered":"https:\/\/www.apfelpatient.de\/?p=70553"},"modified":"2026-07-22T00:25:11","modified_gmt":"2026-07-21T22:25:11","slug":"hide-email-address-apple-closes-loophole","status":"publish","type":"post","link":"https:\/\/www.apfelpatient.de\/en\/news\/e-mail-adresse-verbergen-apple-schliesst-luecke","title":{"rendered":"Hide email address: Apple closes the security gap"},"content":{"rendered":"

For months, the real address behind Apple's alias feature could be exposed \u2013 now Apple has declared the leak closed. The patch was released on July 3rd, but the issue isn't completely resolved. Those using iCloud+ should keep one point in mind.<\/strong><\/p>\n\n\n\n

Apple's iCloud+ feature \"Hide My Email\" is designed to prevent the exact opposite of what a recently discovered bug made possible: instead of protecting the real address, a security vulnerability allowed the actual address to be revealed behind an alias<\/a>. After more than a year and several failed attempts, Apple has now officially declared the problem fixed.<\/p>\n\n\n\n

What the gap revealed<\/h2>\n\n\n\n

The function generates random disposable addresses - two words, a sequence of numbers, and the icloud.com domain - that forward incoming messages to the actual mailbox. This very mapping could be uncovered under certain conditions: The real address appeared in mail logs, for example, when a message was rejected or marked as spam. Only the alias level was affected - passwords and the Apple account itself were not exposed.<\/p>\n\n\n\n

It's impossible to quantify how often genuine email addresses were actually leaked. Since the leak could be triggered by an automatically rejected email, such messages often never even reached the inbox \u2013 so checking the spam folder is no way to determine if you've been affected.<\/p>\n\n\n\n

A fix with a long history<\/h2>\n\n\n\n

The vulnerability was first reported in June 2025 by Tyler Murphy, co-founder of the EasyOptOuts service. Apple acknowledged receipt of the report and declared the problem resolved in March 2026 \u2013 but further testing revealed it could still be exploited. Another attempt to fix it at the end of June also failed. It wasn't until the magazine 404 Media publicly revealed the still-open vulnerability in early July that things started moving: On July 3rd, Apple released the patch, which the company now describes<\/a> as a complete fix.<\/p>\n\n\n\n

The technical details were only released now because the vulnerability can no longer be exploited. However, a degree of skepticism remains warranted \u2013 after all, Apple had previously declared the vulnerability closed, even though it wasn't.<\/p>\n\n\n\n

What iCloud+ users should know now<\/h2>\n\n\n\n

The fix is implemented server-side and therefore takes effect automatically \u2013 no update is necessary for iCloud+ and Apple One customers in Germany, Austria, and Switzerland. However, there is a catch: addresses created before July 7, 2026, may already be logged by third-party providers and still stored there. The patch prevents new leaks but does not reverse previous ones.<\/p>\n\n\n\n

For particularly sensitive logins, you can create new alias addresses to start cleanly separated from past ones. Those who want to generally secure their iCloud data more strongly can also activate the strongest encryption level for iCloud<\/a>.<\/p>\n\n\n\n

Apple's privacy promise is under scrutiny<\/h2>\n\n\n\n

A class-action lawsuit is also underway: Anthony Alvarez filed it on July 15 in the U.S. District Court for the Northern District of California, accusing Apple of misleading advertising, fraud, and breach of contract. He is seeking damages, a refund of subscription fees, and a court order. So far, no actual attack exploiting the vulnerability has been proven. A feature that markets advertising as privacy protection loses its value as soon as the hidden address can be traced \u2013 therefore, it will likely be closely watched whether the fix holds this time. (Image: Apple)<\/p>\n\n\n\n