A Password-Free Path to Root: Inside the macOS Screen Sharing Vulnerability Now Under Attack

Apple's built-in remote desktop feature just handed the security world a case study on how fast a quiet patch can become a public exploit — and now, an active attack. On August 14, 2026, the Netherlands' National Cyber Security Centre confirmed that attackers are actively exploiting CVE-2026-65400, a bug in macOS Screen Sharing that lets anyone on the network log into a Mac without a password, and land as root. This is the story of how that bug was found, fixed, reverse-engineered, and finally weaponized — all in the span of about three weeks.

The bug, in plain terms

Screen Sharing is macOS's built-in remote-desktop feature, built on the VNC protocol and listening on TCP port 5900 when enabled. It's the kind of thing IT admins switch on once — to manage a headless Mac mini in a server closet, say, or to fix a laptop in another building — and then never think about again.

CVE-2026-65400 breaks the one thing that feature depends on: authentication. Apple's own advisory describes it tersely — "an attacker on the network may be able to authenticate to Screen Sharing without valid credentials" — but the practical reality is starker. A remote attacker doesn't need a macOS account password. They don't need the legacy VNC password either. They just need to know a username, and usernames aren't secret; macOS prints them right on the login screen.

Once in, the attacker isn't limited to that one account. The daemon that handles Screen Sharing connections, screensharingd, runs as root. So a successful connection doesn't just impersonate a user — it hands over the whole machine, including files normally shielded by macOS's TCC privacy protections, via privileged helper processes that already have Full Disk Access.

Root cause: a wrong return value

The mechanism, once reverse-engineered, turned out to be almost embarrassingly simple. screensharingd authenticates native macOS connections using Secure Remote Password (SRP), a well-regarded protocol — the flaw isn't in SRP itself, but in how Apple's implementation handles message framing around it.

Specifically, there's a frame-length validation check in the authentication state machine. When it encounters an oversized frame, it bails out early — and by mistake, returns the leftover success code from a read operation that happened just before it. The code calling that function has no way to tell the difference between "this really succeeded" and "this failed but returned a stale success value." It reads the stale success, concludes the authentication step passed, and advances the state machine toward a logged-in session. The resulting connection also skips the cryptographic protections a real SRP handshake would normally establish, leaving it in the clear.

There's no memory corruption here, no ASLR to defeat, no race condition to win, no crash to trigger. It's pure logic. Send one or two packets in the right sequence, and an unpatched Mac lets you in — reliably, the first time and every time.

A tale of two bugs

What makes this story unusual is that Apple's emergency August 6 patch wasn't actually fixing the first pre-auth bug discovered in this code. It was fixing the second one.

A researcher going by @osxreverser had independently found a different pre-auth flaw in the same screensharingd source file — and never reported it to Apple. That bug was, if anything, more severe: it required no username at all. It, too, was a logic error — a single wrong return statement that let an oversized frame's failure path return the success code from an adjacent read.

Apple fixed that first bug quietly, seemingly by accident, as a side effect of an unrelated batch of Screen Sharing patches on July 27 — without apparently realizing (or at least without disclosing) what it had actually closed off. The July 27 advisory listed three "Screen Sharing Server" entries, none described as pre-authentication issues.

That didn't sit well with @osxreverser, who published a blog post on July 29 titled "It's a pre-auth, stupid!" — pointing out that the bug Apple had just silently killed was far more dangerous than anything in its advisory language, and releasing an obfuscated proof-of-concept that could download arbitrary files as root, without explaining the underlying mechanism.

That post appears to have sent other researchers back into the same code. Within days, independent researchers had reverse-engineered a full writeup of the mechanism. And in doing so, they — or Apple's own reporting pipeline — surfaced a second, independent pre-auth flaw sitting right next to the first one in the same file. That second bug is CVE-2026-65400, and it's the one Apple rushed out an out-of-band patch to fix on August 6.

Both bugs, notably, had been present since at least macOS 26.5.2 — sitting side by side, unexploited (as far as anyone has confirmed) until public disclosure kicked off the race to weaponize them.

Four hours from patch to working exploit

Apple almost never ships an out-of-band macOS update for a single vulnerability. When it did so on August 6 — fixing exactly one CVE, in one feature — that alone was a signal to researchers that something serious was being addressed quietly.

A security research team took the bait. They pulled the binaries for macOS 26.6 (pre-patch) and 26.6.1 (post-patch), diffed them, and had a working exploit for CVE-2026-65400 against a live, unpatched machine in about four hours. They then repeated the exercise against the other bug — diffing macOS 26.5.2 against 26.6 — and built a working exploit for that one too, on the same afternoon. Two independent pre-auth remote-root exploits for Apple's most-used desktop OS, reconstructed from patch diffs alone, in a single working session.

It's worth pausing on how routine this has become. Nearly everyone in this chain of discovery used AI tooling somewhere along the way: one related Screen Sharing bug (CVE-2026-43760, a separate post-auth flaw) was found using an automated workflow driven by GPT-5.5; the writeup of @osxreverser's original bug was produced with AI assistance; and the team that turned Apple's patch into working exploits in four hours did so largely by automating the diffing and analysis process. The researchers involved have explicitly framed this incident as evidence that the gap between "patched" and "weaponized" is collapsing industry-wide — a trend they'd flagged in earlier writeups this year.

From proof-of-concept to internet-wide exposure

Before any of this became an active attack, a researcher ran an internet scan and found roughly 40,000 Macs with Screen Sharing reachable directly from the public internet — almost half in the United States, the bulk on residential IP addresses, but with a meaningful long tail sitting on university networks, at companies, and on at least one host belonging to a well-known software vendor.

That's the exposure surface that makes CVE-2026-65400 dangerous beyond the theoretical. Screen Sharing isn't on by default. But it's exactly the kind of feature that gets switched on once during setup — a headless Mac mini tucked in a closet, a remote-management box for a lab, a hosted or cloud-provisioned Apple instance — and then left running, unaudited, for years.

Active exploitation confirmed

On August 14, the Dutch National Cyber Security Centre (NCSC) updated its advisory to report that it had received reports of active abuse "on multiple systems on which port 5900 was accessible from the Internet." In every case it examined, attackers had obtained root access and deployed a Monero cryptocurrency miner on the compromised machine.

NCSC hasn't disclosed the scope of the campaign, when it began, or whether activity extends beyond cryptomining. That caveat matters: opportunistic cryptomining is typically the visible, noisy outcome of a low-effort attacker taking the path of least resistance once they have root — not necessarily the full extent of what's happening. A bug this reliable, this easy to exploit, and this widely scanned-for is exactly the kind of vulnerability that tends to attract more capable actors once the initial gold rush settles down.

What actually mitigates this

Because the flaw lives in code that runs before any authentication check completes, the usual stopgaps don't work here. Removing approved Screen Sharing users, rotating account passwords, or disabling legacy VNC authentication all leave the vulnerable path intact — the attacker never has to pass through any of those checks in the first place.

The fixes that matter:

• Patch. Update to macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9 (all released August 6, 2026) immediately.
• If you can't patch yet, turn Screen Sharing off entirely — System Settings → General → Sharing → toggle off Screen Sharing.
• If you need it running, don't expose it to the internet. Put it behind a VPN or restrict access with a firewall rule; port 5900 should essentially never be open to the public internet.
• Audit your fleet. If you manage more than a handful of Macs, check how many have Screen Sharing enabled — researchers who did this for their own systems said the number surprised them.

The broader pattern

Beyond the specifics of this one bug, the timeline here is a useful data point in a trend security researchers have been flagging for a while: the compression of the window between a patch shipping and a working exploit existing in the wild. A silent one-line fix, buried in a routine update, was reverse-engineered into a functioning proof-of-concept by outside researchers within days — and an entirely separate, related bug in the same file was independently found along the way. Less than two weeks after the emergency patch shipped, someone was using the vulnerability to mine cryptocurrency on other people's Macs.

For anyone running Screen Sharing — or any remote-management service — on a Mac reachable from the internet, the lesson is blunt: patch fast, and don't expose what doesn't need to be exposed.