Zero-Click Calendar invite vulnerability chain in macOS

Original Article ↗ Hacker News Discussion ↗

A recently disclosed zero-click vulnerability chain in macOS Calendar allowed attackers to send crafted iCloud calendar invites with attachments that could exfiltrate a user’s iCloud Photos without any interaction. Commenters note that Apple has patched the underlying bugs but still has not paid a bounty years after responsible disclosure, fueling criticism of Apple’s bug bounty program, its slow and opaque processes, and the incentives this creates for researchers to sell exploits elsewhere. The thread also probes weaknesses in macOS’s permission and quarantine model (TCC), the lack of controls around unsolicited calendar invites, and how these design choices expand the attack surface.

Bug bounty size and delays

  • Many expect at least a mid–high five- or six-figure bounty given Apple’s own “zero‑click sensitive data” range and reports of smaller flaws receiving ~$50k.
  • Strong frustration that, two years after report and fix, no bounty has been paid, despite the researcher being credited in a CVE.
  • Several commenters say long waits (year+ to fix, more to pay, even more to credit) are common and push people away from security research.

Apple’s bug bounty program and incentives

  • One side argues large vendors are strongly incentivized to pay bounties: the money is trivial, bad press is costly, and program staff are usually rewarded for paying, not denying.
  • Others counter with many public complaints about Apple’s program: understaffing, bureaucracy, shifting rules, and mismanagement that effectively disincentivize or delay payouts.
  • Debate over whether problems are due to incompetence vs. conscious cost-cutting or PR‑only motives; consensus that regardless of cause, Apple should fix the program.

Alternative exploit markets and ethics

  • Some claim selling to offensive actors (e.g., spyware vendors) would pay more and faster; others say that’s unlikely for macOS‑only exploits and ethically “cancerous.”
  • Distinction drawn between broad, “any bug” bounties and highly selective offensive buyers who only pay for practical, maintainable exploits on high‑value platforms (iOS > macOS).

Scope and user interaction

  • Clarified that this chain targets macOS via Calendar invites, not iPhone.
  • Some confusion over whether it’s truly zero‑click; at least one comment suggests attachment interaction might be required, others treat it as fully zero‑click per the write‑up. Marked as unclear in the thread.

Calendar invites, spam, and UX trade‑offs

  • Extended debate on whether anyone on the internet should be able to send calendar invites that auto‑appear.
  • Suggestions: whitelists, domain/contacts gating, or explicit confirmation flows vs. practicality for recruiters, vendors, booking systems, and cross‑org meetings.
  • Recognized that calendar invites are already a spam and phishing vector across ecosystems.

macOS security model (TCC, quarantine, /tmp, Photos)

  • Multiple comments note that TCC/quarantine handling is inconsistent and “full of holes,” with too many subsystems able to toggle flags.
  • One experiment shows Photos libraries in the default Pictures directory are protected by TCC, but a library moved to /tmp is not, which is seen as baffling if relocation is officially supported.
  • Some argue /tmp being historically world‑readable explains part of this, but others say the system should still protect user‑designated photo libraries regardless of location.
  • Mention of a separate write‑up on creating app folders without quarantine flags reinforces concern about systemic design issues.

Technical characterization of the bugs

  • Commenters highlight that step 1 (path traversal via FILENAME=../../../...) is itself a serious and surprisingly old‑fashioned bug.
  • The file overwrite/delete behavior inside the Calendar sandbox is called “bad engineering.”
  • Several people relish that this is a non–memory‑safety exploit, undercutting the idea that Rust/“safe” languages eliminate major classes of vulnerabilities.
  • Discussion touches on how to prevent such bugs: shared safe library functions, static analysis rules to forbid ad‑hoc path handling, and better internal reuse culture.

OS support duration and regulation

  • Some skepticism that Apple’s extended OS support windows meaningfully protect users, given patch delays and older versions left vulnerable.
  • Hopes expressed that EU rules (e.g., Cyber Resilience Act) will mandate longer and more consistent security support, though concerns that such regulation may be harder on small/open‑source projects than big vendors.