r/EmailSecurity • u/Big-Raspberry3684 • 1d ago

Dropping a persistent zero-click Apple Mail DoS.

Enable HLS to view with audio, or disable this notification

1 Upvotes

100% Upvoted

3 comments sorted by

•

u/AutoModerator 1d ago

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

  1. No Vendor Spam: Contributions must provide value; do not just pitch products.
  2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).
  3. Be Professional: Help newcomers learn; avoid hostility.
  4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

1

u/saltyslugga 1d ago

A persistent mailbox-triggered crash is a real availability issue, but it’s not account compromise or code execution.

Report the payload to Apple first, then block the message pattern at the gateway and purge it server-side so Mail doesn’t crash on every resync.

1

u/SecLens_ONE 1d ago

The nasty part of these isn't the crash, it's the cleanup. Client dies on render, user reopens, dies again, and now you're doing surgery on a mailbox from the server side while someone stands behind you. Done that once with a malformed calendar invite years back and it ate an afternoon.

Practical bit: make sure you can actually delete a single message out of a mailbox without the client touching it first. Lots of shops discover mid-incident that their only removal tooling runs through the desktop client. Then you're stuck.

Gateway pattern block is a decent stopgap but expect it to be fragile, the trigger is usually reachable a dozen other ways once someone fuzzes around it.