Free iCloud Account Vulnerability Allows Email Spoofing

Key Takeaways

• Two email spoofing vulnerabilities were discovered in Apple’s iCloud mail infrastructure.
• These flaws could allow an attacker with a free iCloud account to send emails appearing to originate from any @icloud.com address.
• The spoofed emails could bypass critical authentication checks like SPF, DKIM, and DMARC.
• Apple has fully patched both issues after a responsible disclosure process.

Critical iCloud Vulnerabilities Allowed Email Spoofing and Authentication Bypass

A significant security finding by researcher Timo Longin, in collaboration with the SEC Consult Vulnerability Lab, has revealed two critical email spoofing vulnerabilities within Apple’s iCloud mail system. These flaws could have enabled an attacker utilizing a free iCloud account to dispatch emails that appeared to originate from any @icloud.com address, including high-profile identities such as [email protected] or [email protected].

Crucially, the meticulously crafted messages were capable of evading detection by standard email authentication protocols like SPF, DKIM, and DMARC. These protocols are fundamental controls employed by mail services to verify the legitimacy of a sender’s identity. Apple has since addressed both vulnerabilities following a comprehensive and extended responsible disclosure timeline.

The Nuance of Email Authentication

This research underscores a vital point: the efficacy of email authentication mechanisms is inherently tied to the robustness of the systems responsible for processing and preparing emails before they exit a provider’s network. The core of the problem here was not a compromised iCloud account or a weakness in the recipient’s email system. Instead, it stemmed from different components within Apple’s outbound SMTP processing pipeline interpreting the same message data in inconsistent ways.

The Simple Mail Transfer Protocol (SMTP), which forms the backbone of internet email communication, distinguishes between an ‘envelope sender’ (known as MAIL FROM or Return-Path) and the ‘From:’ header, which is visible to users in their mail clients. Typically, iCloud enforces strict checks to ensure that an authenticated account only uses its authorized sender addresses. Any attempt to directly set the visible sender to an unassociated iCloud identity would normally result in an error from Apple’s service.

Exploiting Inconsistent Parsing

Longin discovered methods to manipulate iCloud’s internal parsers, causing them to interpret a single email message differently at various stages. One of the identified flaws leveraged the insertion of unusual carriage-return characters within the ‘From:’ header. Apple’s initial parser, during the user validation phase, did not recognize this manipulated field as a standard sender header. However, a subsequent parser would clean up the message prior to delivery, transforming it into a seemingly valid sender header for the receiving mail server.

The technical report published by SEC Consult details the severe implications: an authenticated iCloud user could send an email that appeared to originate from an entirely different iCloud address. SEC Consult confirmed that these spoofed messages arrived at recipient systems with valid iCloud authentication results, bypassing the expected sender checks.

The second vulnerability exploited inconsistencies in how iCloud’s parsers applied SMTP dot-stuffing rules, a long-standing component of the protocol designed to handle lines beginning with periods. A discrepancy in how the first and subsequent iCloud parsers applied these rules created another parsing gap. This allowed a malicious ‘From:’ header to successfully navigate iCloud’s internal checks and appear altered upon relay, further enabling impersonation.

Bypassing SPF, DKIM, and DMARC

Perhaps the most alarming aspect of these vulnerabilities was the ability of the spoofed messages to pass SPF, DKIM, and DMARC verification. SPF confirmed that the email originated from Apple’s legitimate mail infrastructure. DKIM passed because iCloud applied its cryptographic signature after the message processing stage where the ‘From:’ header was manipulated. DMARC then passed because the visible sender domain remained ‘icloud.com’, aligning with Apple’s signed message.

This is critical because users and automated mail gateways often rely on these “pass” results as strong indicators of an email’s trustworthiness. While DMARC alignment typically links the visible sender domain with SPF or DKIM validation, this iCloud case demonstrated how a parsing flaw on the trusted provider’s side could undermine this crucial protective measure.

Disclosure and Remediation

SEC Consult initially reported the carriage-return issue to Apple on May 21, 2024. Although Apple modified its handling of the original proof-of-concept, the researchers subsequently discovered a second bypass method. The final patches for both vulnerabilities were confirmed in December 2025, with the comprehensive technical report released on October 1, 2026. Apple acknowledged Longin’s findings with a $15,000 Apple Security Bounty.

These findings resonate with earlier research into “SMTP smuggling,” where inconsistent protocol handling across services facilitated email spoofing. The case also highlights a broader issue tracked by CERT/CC: the potential for ambiguous ‘From:’ header parsing to allow authenticated SMTP users to impersonate other identities and circumvent established sender checks.

What You Should Do

• While SPF, DKIM, and DMARC are crucial, never implicitly trust an email solely based on their “pass” status.
• Security teams should perform thorough reviews of full message headers for suspicious inconsistencies, particularly between the visible ‘From:’ address and the ‘Return-Path’.
• Users should exercise extreme caution when encountering unexpected requests for credentials, payment information, or urgent actions, regardless of the apparent sender.
• Implement robust user awareness training to educate employees on the risks of sophisticated email spoofing and phishing attacks.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.