macOS Screen Sharing pre-auth root (CVE-2026-65400): the forgotten 5900 forward on your homelab Mac

TL;DR

CVE-2026-65400 is a pre-authentication flaw in macOS Screen Sharing that lets an attacker on the network take over a Mac as root without any credentials, and it is under confirmed active exploitation.^[9][11] Apple shipped the fix on August 6, 2026 (Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9), and CISA rescored the CVE from 7.1 to 9.8 on August 14 after the exploitation picture firmed up.^[1][5][13]

What happened

This started on a box most of us run: a Mac mini that has been up for a year, Screen Sharing left on for the occasional remote fix, and a port forward for TCP/5900 on the router that nobody remembers adding. Screen Sharing is macOS's built-in VNC-based remote desktop, and it is the piece of the OS we enable for maintenance and then stop thinking about. That habit is exactly the exposure this CVE turns into root.

The vulnerability sits in screensharingd, the daemon that answers Screen Sharing connections on TCP port 5900. The daemon runs as root.^[17][7] Apple's own advisory language is cautious, in the usual vendor way. Each of the three security-content pages describes the item identically: "An attacker on the network may be able to authenticate to Screen Sharing without valid credentials," with the fix described as "An authentication issue was addressed with improved state management."^[1][2][3] The "may" is standard Apple phrasing; the actual chain has been independently reverse-engineered, and Hard2bit, the CTIPilot write-up, and Huntress all converge on a state-management defect in the authentication path.^[11][17][6]

Pre-authentication is the word that matters. No username, no password, no legacy VNC credential. Anything that runs after an attacker authenticates is simply out of reach of the bug. And because screensharingd runs as root, the exploit lands at the top of the privilege stack on arrival.

Where the flaw is, and where the reporting splits

Resecurity classifies it as a critical pre-authentication vulnerability in Apple's proprietary RFB/VNC protocol variant over TCP/5900, which authenticates with SRP (Secure Remote Password).^[7] Huntress describes it as a pre-authentication bug in the daemon's authentication mechanism.^[6]

This is the part where I want to be precise about what is settled and what is not, because the coverage blurs it. Huntress and the community Zeek detection package both say the daemon's frame-length validator erroneously returns a stale success status, so the connection is treated as authenticated, and then the session continues without any cryptographic protection in cleartext.^[6][12] The Zeek package states it at the packet level: a client frame whose SRP length field has the high bit set bypasses SRP entirely (no key exchange, no cipher, no session crypto), and parsing then resumes at the wrong offset, corrupting the length-prefixed desktop_name with non-printable bytes.^[12]

A separate researcher, Calif, disputes that attribution. Calif assigns the stale-return behavior to an earlier, uncredited bug and describes CVE-2026-65400 instead as a state-machine desynchronization, withholding details until more machines have updated.^[17] The CTIPilot entry that records both positions is explicit that it does not adjudicate between them.^[17] So the packet-level mechanism is still contested in the public record.

What is not contested is the vendor-confirmed part: Apple describes it as an authentication state-management issue, and both published accounts agree on the effect. A session established through the bug carries no valid credentials and no session crypto, and it ends at root. That is the ground truth this advisory stands on.

Two pre-auth bugs, one CVE

Worth knowing before you read further: there were two independent pre-authentication flaws in screensharingd during the same disclosure window, and only one got a CVE.^[17][7] The July bug (fixed in the July 27 macOS updates, no CVE assigned) is the one fG! wrote up publicly, and the two are routinely conflated in the coverage.^[17][10] This advisory is about the one that has a CVE number, but the practical advice is identical for both: patch, and stop forwarding the port.

Timeline: July 27 to August 18

The disclosure window was short. fG!'s write-up landed on July 29, and Apple's fix was out by August 6, the same day the NVD entry went live. The read-only proof-of-concept from fG!'s post was picked up almost immediately; Huntress documents that a researcher reversed it, rooted the auth bypass in the SRP frame-length validator, and built a read/write plus RCE variant over the first two days of August.^[10][6] By the time NCSC-NL confirmed active abuse on August 12, the tooling to exploit this had been public for about two weeks. The rescore and the KEV listing then followed within a week.

On the score: the NVD rescore to 9.8 replaced a vector that assumed an attacker needed some privileges with one requiring none (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).^[4][14] Two precision notes. The 9.8 is a "Secondary" (CISA) metric in NVD, not NIST's own primary assessment. And I verified the 7.1 to 9.8 transition through archived NVD snapshots, because the live change-history table is JavaScript-gated and did not render for a plain fetch. The August 7 snapshot shows 7.1 HIGH with the old PR:L vector; the August 19 snapshot shows 9.8 CRITICAL.^[4]

Exploitation in the wild

The primary statement is from the Dutch national centre. NCSC-NL (advisory NCSC-2026-0280, revised August 12) confirmed active abuse on multiple systems where port 5900 was reachable from the internet, and in every one of those cases the attacker obtained root and dropped a Monero cryptocurrency miner.^[9] BleepingComputer quotes the English advisory text directly: "In all these cases, root had been accessed on the affected system, and a Monero crypto miner had been placed."^[13] Hard2bit paraphrases the same finding: every case reported to the Dutch centre so far has ended the same way, root access followed by a Monero miner.^[11]

Microsoft Security Intelligence observed a more complete post-exploitation sequence, reported via Tanium Guardian and CyberSecurityNews on August 18. After gaining root through Screen Sharing, the attackers transferred an SSH public key and scripts to the device, established SSH persistence, cleared logs and command history, modified the Packet Filter settings, and deployed the XMRig 6.26.0 cryptocurrency miner as a customized binary placed at a hidden .config/sysmond path, masquerading as com.apple.airportd and persisted through a KeepAlive LaunchDaemon so it survives reboot.^[14][15]

Two caveats on scale. MS TI qualifies its own findings as a "limited number of macOS devices," which is not a total count of compromised hosts.^[14] And in August an underground forum post surfaced offering a downloadable list claiming around 24,000 internet-accessible hosts with TCP/5900 exposed. Resecurity correctly flags that as an unverified threat-actor claim, and an open 5900 is not a vulnerable Mac.^[7] For reference, an independent researcher estimated around 40,000 open Screen Sharing instances on the public internet, as reported by Ars Technica.^[16] Exposed is not the same as exploited, and the real compromise count is not publicly confirmed beyond the NCSC-NL and MS TI statements.

Why this is a homelab problem

Because the Mac mini and the Mac Studio are the default always-on servers for a lot of homelabs. They run Home Assistant, a CI runner, a render node, an automation host, a self-hosted app. They are on 24/7. And Screen Sharing tends to be turned on once, for a remote maintenance session, and never turned back off, because nobody remembers to.

The port forward is the piece that turns a forgotten setting into root. Every incident NCSC-NL reported involved a Mac where the router left TCP/5900 reachable from the internet. The router did the exposing; the Mac just did what it was configured to do and answered on 5900.^[9]

The part that will frustrate you: the classic VNC hardening does not help. Huntress is explicit that removing allowed user accounts, disabling legacy VNC password authentication, or rotating the VNC password have no effect, because the bug fires before any of those checks come into play.^[6] There are exactly two controls that work: install the update (Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9), or disable Screen Sharing entirely. Everything else is posture, not protection.

Lab-note: are you exposed?

Run these on every Mac in the lab, in this order.

1. What build are you on?

sw_vers
# ProductVersion: 26.6.0   -> vulnerable (needs 26.6.1)
# ProductVersion: 15.7.8   -> vulnerable (needs 15.7.9)
# ProductVersion: 14.8.8   -> vulnerable (needs 14.8.9)

Patched lines: Tahoe at 26.6.1 or later, Sequoia at 15.7.9 or later, Sonoma at 14.8.9 or later. Anything below your line's fixed build is in the vulnerable window.^[1][2][3] If you are on an older, unsupported macOS release, there is no patch for it in this set; upgrade the OS or disable Screen Sharing.

2. Is 5900 actually listening?

lsof -iTCP:5900 -sTCP:LISTEN
# a screensharingd / root line = Screen Sharing is on and listening

Screen Sharing off means the service is not listening, and the bug has nothing to reach. This is the fastest honest signal on whether the attack surface exists at all on the box.

3. Is it reachable from outside?

The only test that answers the real question is from outside your network. Use a phone on cellular or a VPS:

# From a host OUTSIDE your network. Replace with your public IP/hostname.
nc -vz -w5 <your-public-ip> 5900
# succeeded = the forward is live and you are in the exposed set
# refused / timeout = not internet-reachable (good)

If that connection succeeds, you are the exact exposure the NCSC-NL incidents describe: a Mac with 5900 reachable from the internet. That is the precondition in every confirmed case.^[9]

If you were exposed: treat it as compromised until proven otherwise

If a Mac was internet-exposed and unpatched for any window, the correct starting assumption is that it was hit, and you work backward from there. The documented post-exploitation kit (MS TI via Tanium/SecPod) is specific enough to check for.^[14][15]

# Foreign SSH key dropped for persistence (the MS TI kit starts here)
sudo cat /root/.ssh/authorized_keys

# Logins to the root account. On macOS the root user is disabled by
# default, so any activity here is a strong signal on its own.
last | grep -E 'root|console'
lastroot

# The observed kit modified Packet Filter settings. Look for an
# unexpected rule, especially one that blocks 5900 from everyone
# except loopback (the actor closing the door behind themselves).
sudo pfctl -sr

# XMRig process, renamed to sound like an Apple daemon
ps aux | grep -iE 'xmrig|sysmond|airportd' | grep -v grep

# The documented miner binary, at its hidden path, by hash
find / -path '*/.config/sysmond' -type f 2>/dev/null
# SHA-256 of the observed customized XMRig 6.26.0 (MS TI):
# 84006055916e267f7c2f9324f1848563e589e4526a296d4e9e9ce8e2112d357c

# Persistence: an unexplained LaunchDaemon
sudo ls -la /Library/LaunchDaemons/
sudo cat /Library/LaunchDaemons/com.xmr.miner.plist 2>/dev/null

On the endpoint side, the strongest discriminator is the Endpoint Security attach event. Apple ships an ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH event (Huntress states it was introduced in macOS 13.0, which is their claim rather than Apple's documented minimum).^[6][18] A legitimate native Screen Sharing session shows authentication_type: RSA-SRP. A session established through the bug shows authentication_type: SRP with no crypto applied, and session_username of root or null.^[6] If you have EDR or an eslogger capture, that combination is your smoking gun. On the network side, the Zeek package flags the desync by a desktop_name coming back with non-printable bytes, and in the test host every one of those malformed sessions coincided with a successful external authentication.^[12]

If you find any of these on an exposed Mac: it is compromised. Rebuild from a known-good image, do not attempt in-place cleanup of a box where root code ran and the logs may have been cleared. Rotate every credential that passed through the machine: SSH keys, passwords, tokens, cloud and API credentials. If you never had the port exposed, the exposure is not there and the response is the update plus a credential hygiene pass for what the machine touched.

Prevention, as a policy

Four rules, in order of how much they matter.

1. Never port-forward TCP/5900 through the router. If it is on your firewall, delete the rule now, patched or not.
2. Disable Screen Sharing when you are not actively using it. System Settings, General, Sharing. It is on by choice, and it should be off by default.
3. Use a self-hosted mesh for remote access instead. WireGuard, Tailscale, or a VPN endpoint puts the session inside a tunnel you control, and 5900 never meets the public internet.
4. Keep the Mac on a supported, patched build. Unsupported releases do not get the fix, so a legacy macOS box in the lab is either an OS upgrade or a disabled service.

Related

One related item, kept separate so it does not muddy the main thread: CVE-2026-43760, a post-authentication bug in the same Screen Sharing file-copy helpers, described as a confused-context / confused-deputy issue. It requires a legacy VNC password to reach, which makes it a different class from the pre-auth, credential-free 65400, and it was patched in the same July wave.^[6] If you are already hardening Screen Sharing for this CVE, 43760 is the second reason to turn the service off rather than just password it.

What not to do

Do not present the packet-level mechanism as settled. The stale-success SRP frame-length account (Huntress/Zeek) and the state-machine desync account (Calif) are both published and neither has adjudicated the other. Cite the vendor-confirmed "improved state management" as the ground truth, and attribute the mechanism to its source.^[6][12][17]

Do not cite /tmp or ~/Downloads as confirmed in-the-wild miner paths. Resecurity's table lists those as observed per NCSC-NL/BleepingComputer, but neither source actually states a file path. The documented ITW location is the hidden .config/sysmond path with the com.apple.airportd masquerade, traced to Microsoft Security Intelligence via Tanium and SecPod. Use those, and attribute them.^[14][15]

Do not conflate the two 7.1 scores. NCSC-NL's advisory carries its own independent 7.1 HIGH rating, and the NVD carried a 7.1 before the rescore. They are different scores from different assessors that happen to share a number. The current operative score is 9.8.^[9][13]

Sources

[1] https://support.apple.com/en-us/148170 — Apple: About the security content of macOS Tahoe 26.6.1

[2] https://support.apple.com/en-us/148171 — Apple: About the security content of macOS Sequoia 15.7.9

[3] https://support.apple.com/en-us/148172 — Apple: About the security content of macOS Sonoma 14.8.9

[4] https://nvd.nist.gov/vuln/detail/CVE-2026-65400 — NVD: CVE-2026-65400 (CVSS 9.8 CRITICAL, CISA Secondary metric, CWE-287; 7.1→9.8 transition verified via archived snapshots)

[5] https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CISA Known Exploited Vulnerabilities catalog (entry added 2026-08-18, due 2026-08-21, BOD 26-04; rescore 7.1→9.8)

[6] https://www.huntress.com/blog/macos-screen-sharing-rce-patched — Huntress: pre-auth RCE in Screen Sharing (PoC, SSFileCopySender entitlements, ES attach-event detection, hardening-ineffective finding)

[7] https://www.resecurity.com/blog/article/cve-2026-65400-macos-screen-sharing-authentication-bypass-under-active-exploitation — Resecurity: CVE-2026-65400 under active exploitation (state-machine framing, ~24k unverified exposure claim, two pre-auth flaws)

[8] https://www.cisa.gov/news-events/alerts/2026/08/18/cisa-adds-four-known-exploited-vulnerabilities-catalog — CISA alert: Adds four KEV entries (2026-08-18)

[9] https://advisories.ncsc.nl/2026/ncsc-2026-0280.html — NCSC-NL Advisory NCSC-2026-0280 (active abuse, root + Monero miner, port 5900 reachable from the internet)

[10] https://reverse.put.as/2026/07/29/its-a-pre-auth-stupid — fG! (Pedro Vilaça): "It's a pre-auth, stupid!" (2026-07-29, read-only PoC navi_the_clown)

[11] https://hard2bit.com/en/blog/macos-screen-sharing-cve-2026-65400-root-without-credentials — Hard2bit: root without a password on macOS (NCSC-NL "every case" reporting, hardening-ineffective finding)

[12] https://github.com/initconf/zeek-screensharing-rce — initconf/zeek-screensharing-rce: Zeek detection package (SRP frame-length mechanism, desktop_name desync indicator)

[13] https://www.bleepingcomputer.com/news/security/hackers-exploit-macos-screen-sharing-flaw-to-deploy-monero-miner — BleepingComputer: hackers exploit macOS Screen Sharing flaw to deploy Monero miner (NCSC-NL English-text quote)

[14] https://www.tanium.com/blog/guardian-critical-macos-screen-sharing-authentication-bypass-cve-2026-65400 — Tanium Guardian: Microsoft SI observations (SSH persistence, log clearing, pf changes, XMRig 6.26.0 as com.apple.airportd), CISA rescore to 9.8 on August 14

[15] https://www.secpod.com/learn/security-research/no-password-needed-mac-os-screen-sharing-flaw-cve-2026-65400-used-to-deploy-monero-miners — SecPod: IoC table (XMRig 6.26.0, .config/sysmond, com.apple.airportd, KeepAlive LaunchDaemon)

[16] https://arstechnica.com/security/2026/08/vulnerability-giving-attackers-full-control-of-macs-is-under-active-exploitation — Ars Technica: active-exploitation coverage (~40,000 open Screen Sharing instances estimate)

[17] https://ctipilot.ch/entries/2026-08-08/cve-2026-65400-macos-screen-sharing-auth-state-bypass — CTIPilot entry (2026-08-08, updated 2026-08-16): two pre-auth bugs, Calif's disputed attribution, screensharingd runs as root. Note: AI-generated aggregator with no human review; key facts cross-checked against the underlying sources.

[18] https://developer.apple.com/documentation/endpointsecurity/es_event_type_notify_screensharing_attach — Apple Developer: ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH (event exists; no minimum version listed in the fetched docc data)