macOS Screen Sharing CVE-2026-65400: No Password Required for Root

An attacker who can reach TCP port 5900 on an unpatched Mac does not need a username, a password, or a stolen credential. Two packets, sent in the right order, are enough. The Screen Sharing daemon misreads a corrupted status flag as a valid login and waves the connection through into a full, unauthenticated session.

That is CVE-2026-65400, a pre-authentication flaw in macOS Screen Sharing that Apple patched on August 6 and CISA added to the Known Exploited Vulnerabilities catalog on August 18, with a remediation deadline of August 21. CISA also rescored the bug from 7.1 to 9.8 once evidence of active exploitation came in.

The affected machines are Macs running Screen Sharing, Apple's built-in remote-desktop service, VNC-compatible on TCP 5900, reachable from the open internet. That is a narrower population than every Mac in the building, but it is larger than most IT teams assume. Security researcher @osxreverser's Shodan scan turned up roughly 40,000 exposed Screen Sharing hosts, almost half of them in the United States, spanning residential connections, university networks, and company servers. If your organization runs a Mac mini or Mac Studio as a build agent, a file server, or a remotely managed kiosk, and Screen Sharing reaches it through a port forward rather than a VPN, this CVE is yours to fix tonight. If every Mac in your fleet only reaches Screen Sharing over an internal network or a VPN tunnel, patch on the normal cycle; the urgency here belongs to internet-facing hosts specifically.

What's actually broken

Screen Sharing authenticates over Secure Remote Password (SRP), a protocol designed so a client can prove it knows a password without ever transmitting the password itself. The screensharingd daemon's frame-length validator carries a bug: fed a specific malformed input, it returns a stale success status instead of failing the exchange. The session is treated as authenticated even though no valid proof was ever supplied, and it proceeds without the cryptographic protection SRP exists to provide. Apple's advisory, crediting researcher Alfredo Pesoli for the report, describes the fix as "improved state management" in that validation path.

The blast radius runs past a login bypass. The forged session inherits access to SSFileCopySender, a helper process that carries Apple's kTCCServiceSystemPolicyAllFiles entitlement, full disk access that skips every TCC permission prompt. From there an attacker drops a LaunchDaemon or edits a shell startup file and gets code execution at the next reboot or login, with no exploit chain beyond the original two packets. A related bug, CVE-2026-43760, lets an already-authenticated legacy-VNC user perform the same root-level file read and write; Apple shipped both fixes in the same update.

What's already happening on exposed hosts

NCSC-NL reported active abuse against internet-exposed Macs, and Microsoft's own telemetry independently confirmed exploitation on a limited number of devices, including successful root-account network sign-ins. On the machines examined, the payload was XMRig 6.26.0, a Monero mining binary, dropped into a hidden ~/.config/sysmond path, ad-hoc signed, and disguised under the name com.apple.airportd. A KeepAlive LaunchDaemon kept it running across reboots.

Two details matter for triage. The compromise reaches root, so a cryptominer is the payload an attacker chose to monetize the access, not the ceiling of what that access allows. And the standard account-hardening moves, removing Screen Sharing user accounts, disabling legacy VNC password auth, rotating that password, do nothing against this bug. It succeeds before any of those checks run.

Find your exposure and confirm the patch

Three checks, in order: is anything reachable, is it patched, and did anything already land.

# 1. Is Screen Sharing reachable from outside your network right now?
nmap -Pn -p 5900 --open <your-external-ip-or-CIDR>

# 2. Confirm the patched build on every Mac that answers
for host in $(cat exposed_hosts.txt); do
  ssh "$host" 'sw_vers -productVersion'
done
# Patched: Tahoe 26.6.1 / Sequoia 15.7.9 / Sonoma 14.8.9.
# Anything older on a host that answered step 1 was exposed.

# 3. Hunt for the observed implant on any host reachable before you patched
ps aux | grep -iE 'sysmond|airportd' | grep -v grep
ls -la ~/.config/sysmond 2>/dev/null
launchctl list | grep -i keepalive

If you cannot patch tonight

• Disable Screen Sharing in System Settings > General > Sharing, or run sudo launchctl unload /System/Library/LaunchDaemons/com.apple.screensharing.plist, on every host you cannot immediately update.
• Pull Screen Sharing off any router port forward and require a VPN or managed Apple Remote Desktop session instead.
• The Endpoint Security event ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH is worth its own detection rule: a session authenticated as root, or one showing plain SRP instead of RSA-SRP as the auth type, has no business appearing in a legitimate login.

Turn off Screen Sharing on anything you cannot confirm patched tonight

Removing local accounts, rotating passwords, and disabling legacy authentication are the reflexive first moves for most authentication bugs, and none of them touch this one. The only controls that work are patching the build or taking the service off the network until you can. If you manage a Mac fleet with any Screen Sharing exposed to the internet, treat tonight's check as the priority: confirm what is reachable, confirm the build number, and assume any host that answered both checks before today needs a process hunt, not just a version bump.