Skip to navigation

Threat reportVulnerabilityTL-2026-1628

Apple Hide My Email Flaw Exposed Real Email Addresses via Spam-Filter/Bounce Triggering

criticalPATCHED

A privacy flaw in Apple iCloud+ 'Hide My Email' allowed an attacker who already knew a target's masked alias to unmask the underlying real email address by sending a message engineered to be rejected as spam, which caused the real address to surface in mail transfer/bounce (NDR) logs even though the message never reached the inbox.

Key facts for Hide My Email spam-bounce unmasking

IdentifiersTL-2026-1628
Also known asHide My Email De-Anonymization Flaw, Hide My Email Bounce-Log Leak
SeverityCRITICAL
Exploitation statusExploited in the wild
Affected productsApple iCloud+ Hide My Email
Weaknesses (CWE)CWE-200
ToolsHide My Email
MITRE ATT&CK techniquesT1114 Email Collection, T1566 Phishing, T1566.001 Spearphishing Attachment, T1566.002 Spearphishing Link, T1585 Establish Accounts, T1585.002 Email Accounts, T1586 Compromise Accounts, T1586.002 Email Accounts, T1589 Gather Victim Identity Information, T1589.002 Email Addresses, T1591 Gather Victim Org Information, T1596 Search Open Technical Databases and 3 more in the attack flow
MotivationUNKNOWN
Target sectorsconsumer, technology
Target regionsGlobal
Detection rules9 (1 shown free)
Sources11 cited sources

Detection coverage for Hide My Email spam-bounce unmasking

As of 2026-07-22, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-1628 across Splunk SPL, Microsoft KQL and Sigma, covering 15 indicator(s) of compromise. The whole corpus is readable without an account. Every threat comes with one complete detection in Splunk SPL, Microsoft KQL and Sigma, free for everyone; a free account adds daily TL Creds to unlock the rest. Paid plans add a larger daily allowance, correlation and the MCP server. Threadlinqs MCP server · View plans.

Free detection: Bounce/NDR Log Contains Real Address Alongside Masked Alias Recipient

Detects mail-transport bounce/non-delivery-report (NDR) log entries that carry a secondary/real recipient address field alongside a masked alias-style recipient for the same rejected delivery attempt — the root-cause CWE-200 log-leak pattern reproduced in this threat's Hide-My-Email bounce-processing exploitation and corrected by Apple's 2026-07-03 server-side patch. Fires on the mail gateway/MTA at the moment the vulnerable bounce is generated, before any downstream correlation.

  • Languages: Splunk SPL, Microsoft KQL, Sigma
  • ATT&CK: T1589.002, T1598.001
  • Data sources: mail_transport_logs, mta_bounce_ndr_logs, email_gateway_logs
  • Severity: critical
  • Confidence: high

Splunk SPL

index=mail_transport sourcetype IN ("postfix:bounce","exim:reject","sendmail:bounce") ("550 5.7.1" OR "rejected as spam" OR "spam filtering")
| rex field=_raw "orig_rcpt=(?<orig_rcpt>[^\s]+)"
| rex field=_raw "(real_rcpt_leak|leaked_real_rcpt|secondary_recipient|X-Sim-Leaked-Real-Address)[:=]\s*(?<leaked_real_addr>[^\s;]+)"
| where isnotnull(leaked_real_addr) AND leaked_real_addr!="REDACTED" AND match(orig_rcpt, "^[a-z]+-[a-z]+[0-9]{2,4}@")
| eval alias_recipient=orig_rcpt
| stats count min(_time) as first_seen max(_time) as last_seen by mta_host, sender, alias_recipient, leaked_real_addr
| where count > 0
| table first_seen, last_seen, mta_host, sender, alias_recipient, leaked_real_addr, count
| sort -last_seen

Microsoft KQL

let SuspiciousBounceLeak = EmailEvents
| where Timestamp > ago(24h)
| where DeliveryAction == "Bounced" or DeliveryReason has_any ("550 5.7.1", "RejectedAsSpam", "rejected as spam")
| where RecipientEmailAddress matches regex @"^[a-z]+-[a-z]+[0-9]{2,4}@"
| extend LeakedRealAddress = extractjson("$.leaked_real_rcpt", AdditionalFields)
| where isnotempty(LeakedRealAddress) and LeakedRealAddress != "REDACTED"
| project Timestamp, NetworkMessageId, SenderFromAddress, RecipientEmailAddress, LeakedRealAddress, DeliveryReason;
SuspiciousBounceLeak
| summarize FirstSeen=min(Timestamp), LastSeen=max(Timestamp), LeakCount=count() by SenderFromAddress, RecipientEmailAddress, LeakedRealAddress
| order by LastSeen desc

Sigma

title: Mail Bounce/NDR Log Contains Unexpected Secondary Recipient Address
id: 6e2b6a2e-8f3d-4c2a-9b1a-b6a1e9c4d001
status: experimental
description: Detects a mail-transfer bounce/NDR log entry for an alias-style recipient that also exposes a real/underlying recipient address, reproducing the Apple Hide My Email CWE-200 de-anonymization flaw (patched 2026-07-03).
references:
    - https://www.404media.co/apple-fixes-hide-my-email-vulnerability-after-404-media-coverage/
    - https://thehackernews.com/2026/07/apple-fixes-hide-my-email-bug-that.html
author: AII-Detector — ThreadLinqs Intelligence
date: 2026-07-22
tags:
    - attack.reconnaissance
    - attack.t1589.002
    - attack.t1598.001
    - cve.2026.hide-my-email
cwe: CWE-200
logsource:
    category: application
    product: mail
detection:
    selection_bounce:
        message|contains:
            - '550 5.7.1'
            - 'rejected as spam'
    selection_leak:
        additional_recipient_field|exists: true
    selection_alias:
        recipient|re: '^[a-z]+-[a-z]+[0-9]{2,4}@.*'
    condition: all of selection_*
falsepositives:
    - Legitimate secondary-recipient headers used for internal routing or shared-mailbox delivery
    - Mail hosts that intentionally log a distribution-list expansion address alongside an alias
level: high

Known false positives:

  • Legitimate internal mail-routing configurations that intentionally log a secondary/expansion recipient alongside an alias for shared-mailbox or distribution-list delivery

Tuning notes: Scope the alias-recipient regex to the organization's actual masked-alias domain/naming convention (e.g. the two-word+number @icloud-alias pattern) rather than the generic pattern shown, and whitelist known internal expansion-header mail flows to reduce false positives before enabling auto-alerting.

8 more detection rules (Splunk SPL, Microsoft KQL, Sigma) · unlock with TL Creds. Sign up free to unlock the detection rules or query them with the Threadlinqs MCP server (Purple)
  • Exchange Online / M365 Defender: Bounce Event Exposes Real Recipient Behind Masked Alias · unlock with TL Creds
  • Sentinel: Repeated High-Spam-Score Probes Against Registered Alias Mailboxes · unlock with TL Creds
  • Sentinel: Compromised/Newly-Established Account Exfiltrating Alias-to-Real-Address Mappings to External Correlation Services · unlock with TL Creds
  • Mail Bounce/NDR Log Contains Unexpected Secondary Address Pattern · unlock with TL Creds
  • High-Volume Spam-Triggering Probes to Known Alias-Style Recipients · unlock with TL Creds
  • Spearphishing-Service Alias Abuse Followed by Real-Address Correlation Lookup · unlock with TL Creds
  • Burst of Spam-Triggering Probe Messages Targeting Alias-Style Recipients · unlock with TL Creds
  • Post-Leak Correlation: Newly-Exposed Real Address Queried Against People-Search Sources · unlock with TL Creds

Indicators of compromise for Hide My Email spam-bounce unmasking

As of 2026-07-22, Threadlinqs Intelligence tracks 15 indicators of compromise for TL-2026-1628.

15 indicators of compromise · unlock with TL Creds. Compare plans

How Hide My Email spam-bounce unmasking works

Independent researchers Tyler Murphy and Ben Weiner of EasyOptOuts privately reported the issue to Apple on June 13, 2025; Apple claimed fixes in March 2026 and again in mid-2026 that did not actually resolve the flaw, and only shipped a working patch on July 3, 2026 after 404 Media prepared to publish.

Hide My Email is a paid Apple iCloud+ feature that generates randomized alias addresses (typically two words plus a number at an @icloud.com-style domain) so users can sign up for services or receive correspondence without exposing their real email address. Researchers Tyler Murphy and Ben Weiner (co-founders of EasyOptOuts) discovered that Apple's mail-handling infrastructure leaked the underlying real address associated with a Hide My Email alias whenever a message sent to that alias was rejected by spam filtering and generated a bounce/non-delivery report. The real address appeared in mail transfer logs and bounce-processing artifacts maintained by email providers/hosts (including third-party mail hosting providers outside Apple's own infrastructure), regardless of whether the triggering message was malicious or a legitimate message that simply tripped spam heuristics. The affected messages typically never reached the victim's inbox or spam folder, so victims had no way to review whether they had been targeted. In limited volunteer testing, the researchers reported that 100% of tested Hide My Email addresses were successfully unmasked. The attack requires the attacker to already know the target's masked alias address, which limits (but does not eliminate) the practical attack surface, since Hide My Email aliases are routinely shared with third-party services, marketers, and correspondents, and an exposed real address can subsequently be correlated with personal details via free, publicly accessible people-search sites. Murphy reported the flaw to Apple on June 13, 2025, including replication instructions. Apple acknowledged the report in July 2025 and said it was investigating. In March 2026 Apple told Murphy the issue had been fixed; testing showed it had not. In May 2026 Apple stated the issue remained under investigation and a fix was expected 'in the coming weeks.' By late June 2026 the researchers remained unconvinced a real fix was forthcoming and brought the issue to 404 Media journalist Joseph Cox, who prepared coverage without publishing exploitation details in order to avoid enabling abuse. Apple deployed what both the company and the researchers describe as a working fix on July 3, 2026. 404 Media and other outlets published public disclosure of the flaw's existence (without exploit specifics) between July 17-22, 2026. Because the underlying mechanism relied on server-side mail transfer/log behavior rather than a client-side bug, any Hide My Email alias created and used before roughly July 7, 2026 may have already had its real address exposed and captured in third-party mail logs outside Apple's control, meaning the July 3 patch does not retroactively remediate addresses already leaked. Apple separately faces a class-action lawsuit alleging false advertising, fraud, and breach of contract tied to deceptive marketing of Hide My Email's privacy guarantees while the flaw went unfixed for over a year after private disclosure; some coverage characterized the suit as an early, largely evidence-free filing. No CVE or CVSS score has been assigned to this issue by any tracked authority as of publication; severity here is scored on real-world consumer-privacy impact given the reported 100% real-world de-anonymization success rate and the year-plus remediation delay including two false vendor 'fixed' claims, not on a CVSS/KEV/PoC criterion.

MITRE ATT&CK techniques by tactic:

Collection

T1114 Email Collection

Initial Access

T1566 Phishing; T1566.001 Spearphishing Attachment; T1566.002 Spearphishing Link

Resource Development

T1585 Establish Accounts; T1585.002 Email Accounts; T1586 Compromise Accounts; T1586.002 Email Accounts

Reconnaissance

T1589 Gather Victim Identity Information; T1589.002 Email Addresses; T1591 Gather Victim Org Information; T1596 Search Open Technical Databases; T1596.005 Scan Databases; T1598 Phishing for Information; T1598.001 Spearphishing Service

Remediation for Hide My Email spam-bounce unmasking

Patches

  • Apple deployed a server-side fix to iCloud+ Hide My Email mail-handling/bounce-processing infrastructure on 2026-07-03

Immediate actions

  • Treat any Hide My Email alias created or actively used before July 7, 2026 as potentially unmasked and rotate/retire it
  • Delete and regenerate Hide My Email aliases that have received spam or bounce-triggering messages
  • Use a distinct Hide My Email alias per service/correspondent to limit blast radius of any single alias unmasking
  • Monitor real underlying email accounts for unsolicited contact that would indicate a leaked alias-to-address mapping
  • Search people-search / data-broker sites for the real address behind any long-used alias to gauge whether correlation has already occurred

Workarounds

  • Until confirming rotation, avoid submitting a Hide My Email alias to any correspondent/service not fully trusted, since a rejected message from that party could unmask the real address
  • Rely on primary inbox spam filtering rather than the Hide My Email alias itself as the privacy boundary for untrusted senders

Longer-term hardening

  • Apple should audit and scrub historical mail transfer/bounce logs across its own and downstream third-party mail infrastructure for real-address exposure tied to Hide My Email aliases
  • Implement alias-to-real-address unlinking at the bounce/NDR generation layer so rejected mail never surfaces the underlying recipient address
  • Independent verification of vendor 'fixed' claims before closing privacy vulnerability reports, given Apple's two prior false remediation claims (March 2026, May/June 2026)
  • Users relying on email-masking/alias services generally should assume masked addresses can be correlated to real addresses via mail-infrastructure side channels and should not treat alias features as a sole privacy control for sensitive correspondence

Affected and fixed versions

  • Apple — iCloud+ Hide My Email
    Vulnerable versions: all Hide My Email aliases created/active before 2026-07-03 patch
    Fixed in: mail-handling/bounce-processing infrastructure patched 2026-07-03

Timeline of Hide My Email spam-bounce unmasking

  • locked-ioc-9 (locked-ioc-10) privately reports the locked-ioc-8 real-address exposure flaw to locked-ioc-15, including replication instructions.
  • locked-ioc-15 acknowledges the report and states the issue is under investigation.
  • locked-ioc-15 tells Murphy the issue has been fixed; the flaw remains exploitable, contrary to locked-ioc-15's claim.
  • locked-ioc-15 states the issue remains under investigation and that a fix is expected 'in the coming weeks.'
  • locked-ioc-15 again states it is investigating/addressing the issue; researchers remain unconvinced a real fix is forthcoming and escalate to locked-ioc-13 journalist locked-ioc-12.
  • locked-ioc-15 deploys a working server-side fix to the locked-ioc-8 mail-handling/bounce-processing infrastructure.
  • AppleInsider publishes coverage confirming the unmasking flaw exists but withholding exploitation steps.
  • locked-ioc-13 publishes full public disclosure confirming the patch and detailing the flaw's discovery and remediation timeline; other outlets (MacRumors, TheHackerNews, Neowin, iClarified, iDropNews, Digital Trends) republish coverage.
  • Cyber Security News publishes coverage of locked-ioc-15's fix, the source article for this threat record.

Sources cited for Hide My Email spam-bounce unmasking

Previous and next in vulnerability

Drafted by the Threadlinqs research pipeline from 11 sources; published ; last updated —.

Threadlinqs Intelligence — Real-Time Threat Detection Platform

[ 0 threats ] [ 0 det ] [ CRIT: 0 ] [ HIGH: 0 ]
// threat_feed
$ sort --newest
Showing all threats

Live intelligence console

Threat level

Latest Threats