Apple's Hide My Email took a year to patch — what that says about privacy-feature bugs

Apple’s Hide My Email — the feature that generates a random forwarding alias so you never hand out your real address — had a bug that did the opposite of its entire purpose: it could expose the real address behind the alias. According to the researchers who found it, Tyler Murphy and Ben Weiner of EasyOptOuts, they reported it to Apple in mid-2025. A working fix didn’t ship until July 3, 2026 — and Apple had told them it was already fixed, twice, before that.

That gap is the story worth reading if you build anything that makes a privacy promise: address masking, alias forwarding, anonymized relays, tokenized contact info. Not because Apple is uniquely careless, but because the failure mode is common and mechanical, and it’s worth checking whether your own system has the same shape.

How the leak actually worked

The bug lived in an unglamorous, very ordinary part of email infrastructure: bounce handling. When a message sent to a Hide My Email alias got rejected — because the alias was invalid, the recipient’s mailbox was full, or the receiving server applied a spam filter — the bounce (a non-delivery report, or NDR) sometimes carried the real address behind the alias, not just the alias itself. That NDR then sat in whatever mail server or logging system generated the rejection, outside Apple’s control, as The Hacker News reported.

That’s a much older failure category than Hide My Email itself. Bounce and non-delivery reports have leaked more information than intended since long before alias-forwarding privacy features existed — email’s bounce mechanics were designed for delivery diagnostics, not for keeping a masked identity masked. Bolting a privacy guarantee onto infrastructure that wasn’t built to preserve one is exactly the kind of seam that produces bugs like this. The specific flaw was new; the shape of the flaw — a legacy transport behavior undermining a newer promise built on top of it — is not.

Why the timeline matters more than the bug

For anyone triaging vulnerability reports, there’s a specific trap here: a bug that only fires on an edge case (a bounce, not every send) and requires an unusual condition to observe tends to get scored as low-severity and low-priority, even when its blast radius — every user of the feature, silently — is enormous. Severity scoring that weighs “how often does this trigger” over “what does it break when it does” will systematically under-prioritize exactly the bugs that undermine a stated guarantee. If a feature’s entire value proposition is “we hide X,” any path — however rare — that reveals X deserves a severity bump most vulnerability-scoring rubrics won’t give it by default.

Apple is also now facing a class-action lawsuit over the feature, with the complaint arguing customers paid for a privacy guarantee — directly through iCloud+ or indirectly through Apple’s broader privacy positioning — that wasn’t actually delivered. Whether or not the suit succeeds, it illustrates the asymmetry in how a privacy feature’s trust cost works: the feature is marketed on an absolute claim (“your real address stays hidden”), so any exception to that claim, however narrow or rare, reads to users and regulators as a broken promise rather than a normal bug. Features that promise something quantitative (“faster,” “cheaper”) tolerate partial failure gracefully; features that promise something binary (“hidden,” “encrypted,” “isolated”) don’t have that luxury — a single documented exception undermines the entire claim, not just the affected fraction of usage.

What a masking or relay feature has to guarantee, structurally

If you’re building an address-masking, alias-forwarding, or contact-relay feature — a temporary email alias, a reply-forwarding address, a masked contact link — the Hide My Email case is a useful checklist of what “done” actually requires:

• Every failure path, not just the happy path, must preserve the mask. Bounces, rejections, out-of-office replies, and error messages are exactly where a masked identity tends to leak, because they’re generated by systems outside your direct control and rarely get the same scrutiny as normal delivery.
• Downstream logs are part of your threat surface. If a masked identity ever touches a header, envelope field, or error payload that a third-party mail server will log, you’ve extended your privacy boundary to include systems you don’t own and can’t audit.
• “Fixed” needs a regression test that covers the failure path, not just the common case. Apple’s claimed March fix apparently didn’t hold up under the researchers’ retesting — a sign the original patch addressed a symptom rather than the underlying bounce-handling path.
• A remediation SLA should scale with blast radius, not just reported frequency. A rare-to-trigger bug in a feature everyone relies on for the same guarantee isn’t a low-severity bug; it’s a low-frequency one, and those are different axes.

None of this is exotic advice, and that’s the point — it’s the kind of checklist that gets skipped under normal roadmap pressure precisely because the bug in question is hard to reproduce and doesn’t show up in a dashboard. Any team exposing a masking, aliasing, or forwarding feature through a public API should hold it to the same standard: audit what your failure paths reveal, not just what your success paths promise.

The same failure path, one layer over in cold email

Bounce handling specifically isn’t a hypothetical for a cold-email platform — it’s a daily, high-volume event, which is exactly the kind of “unglamorous, ordinary” path the Hide My Email bug lived in. Norbelys treats a bounce as a consequence to act on, not a log line to file away: a hard bounce enrolls that address out of every future send automatically, so the failure path — the one nobody’s watching closely, the one Apple’s bug hid in for over a year — is the same path that’s doing suppression work here, not silently leaking or silently doing nothing. And the credential side of the same lesson applies too: mailbox passwords and OAuth refresh tokens are encrypted at rest and never returned over the API, so a bounce, a log, or a failed request downstream of a send has no live credential sitting in it to expose in the first place. Neither guarantee is exotic engineering — they’re the same “audit every failure path, not just the happy one” discipline this bug is a reminder to actually apply. It’s also a reasonable question to ask of any vendor sitting in your own outreach stack, Norbelys included: what does the bounce path actually do, and does a credential ever come back out of it.