HLD Shield · Emergency briefing · 22 August 2026Active exploitationPatch today

macOS Screen Sharing: CVE-2026-65400 gives root without a password

A critical authentication bypass in the macOS Screen Sharing service lets an unauthenticated remote attacker take root control of a Mac. Attackers are scanning the internet for systems listening on TCP port 5900 and deploying crypto-miners on the ones they reach. If you run Macs, patch today, switch Screen Sharing off where it is not needed, and confirm port 5900 is blocked at your perimeter.

Apple · macOS · Screen SharingCVE-2026-65400 · Auth bypassTCP 5900 · Internet-exposedRoot access · Crypto-mining

Executive summary

CVE-2026-65400 is a critical authentication bypass in the macOS Screen Sharing service. An unauthenticated remote attacker who can reach the service over the network can obtain root access to the machine without supplying a password and without any action by the person using it.

The defect is a state-machine handling error in the Secure Remote Password (SRP) protocol exchange. SRP is a password-authenticated key agreement scheme: the client proves it knows the password without sending it, and the server is meant to accept the session only after that proof verifies. In the affected builds the service advances to a connected state along a path where verification has not actually succeeded, so an invalid connection is treated as a verified one. The cryptography is not broken — the sequencing around it is, which is why exploitation needs no credential guessing and no brute force.

Exploitation is active. Threat actors are sweeping the internet for hosts listening on TCP port 5900, the default Screen Sharing / VNC port, and using the bypass to install cryptocurrency mining payloads on the Macs they reach. Mining is simply the payload that has been observed; the access obtained is unrestricted root and supports any follow-on objective.

HLD assesses this as an emergency-response event for any organisation with Macs, and specifically for those running Mac build agents, lab machines, media workstations, or cloud-hosted Macs where Screen Sharing is enabled and remote access is reachable from outside the corporate network.

What the vulnerability allows

The attacker needs network reachability to the Screen Sharing service and nothing else. No valid account, no stolen credential, no phishing, no user click. Successful exploitation gives:

  • Root-level control of the Mac, equivalent to sitting in front of it as an administrator
  • Interactive access to the desktop session, including anything visible on screen and any unlocked application
  • Read access to files, SSH private keys, cloud CLI credentials, and tokens stored on disk
  • The ability to install persistent LaunchDaemons and LaunchAgents that survive reboot
  • The ability to create accounts, add SSH authorized_keys, and disable local security tooling
  • A launch point for lateral movement into whatever internal networks and services that Mac can reach

The practical consequence for defenders: patching a Mac that was internet-exposed while unpatched closes the door but proves nothing about whether someone already walked through it. Exposure during the exploitation window warrants a compromise assessment, not just an update.

Affected and fixed versions

macOS releaseAffectedFixed inRisk status
macOS TahoeAll builds prior to 26.6.126.6.1Critical
macOS SequoiaAll builds prior to 15.7.915.7.9Critical
macOS SonomaAll builds prior to 14.8.914.8.9Critical
Earlier macOS branchesVentura and older, outside Apple security supportNo patch expectedCritical

Macs on macOS branches that no longer receive Apple security updates have no patch path for this issue. Those devices should have Screen Sharing disabled, be kept off any internet-reachable path, and be scheduled for upgrade or replacement.

Immediate actions, do these today

01

Patch every Mac now — treat this as an emergency change

Update to macOS 26.6.1 (Tahoe), 15.7.9 (Sequoia), or 14.8.9 (Sonoma) or later. On managed fleets, push the update through MDM today rather than waiting for the next maintenance window; on unmanaged devices, open System Settings → General → Software Update and install everything offered, then reboot. Devices on macOS branches no longer receiving security updates cannot be fixed by patching and must be isolated or upgraded.

02

Turn Screen Sharing off wherever it is not actively required

System Settings → General → Sharing → toggle off Screen Sharing, and also confirm Remote Management is off unless your MDM or support tooling genuinely depends on it. Screen Sharing is enabled far more often than it is used — on developer laptops, lab machines, build agents, and Mac minis running as CI runners it is frequently left on from a one-off support session years earlier.

03

Block TCP 5900 inbound at the perimeter and confirm it is blocked

Ensure no firewall rule, port-forward, UPnP mapping, or cloud security group permits inbound 5900 from the internet. Remote access to Macs should traverse a VPN or an identity-aware proxy, never a directly exposed VNC port. Pay particular attention to home and small-office routers where UPnP may have opened the port automatically, and to Macs hosted with cloud Mac providers.

04

Hunt for compromise on any Mac that was exposed while unpatched

Do not assume patching is sufficient for a device that was reachable on 5900. Look for unexpected root-owned processes and sustained CPU load consistent with mining, new or modified LaunchDaemons and LaunchAgents, unfamiliar admin accounts, new SSH authorized_keys entries, and outbound connections to mining pools. Review screensharingd and authentication logs for successful sessions you cannot attribute to a named person.

05

Rotate credentials that lived on any confirmed-compromised host

Root access means everything on the device is exposed: SSH keys, cloud CLI tokens, signing certificates, browser sessions, and anything unlocked in the login keychain. For a confirmed compromise, rebuild the machine from a known-good image rather than cleaning in place, and rotate every secret that was present on it.

06

Communicate to staff using personal Macs for work

BYOD and contractor Macs are the hardest part of this exposure and the least visible to IT. Send a short, plain-language instruction to update macOS and check the Sharing settings, and give people a channel to report a Mac they suspect was exposed without fear of blame.

Verify exposure and disable Screen Sharing

Run these on Macs you are responsible for. The graphical equivalent of the disable steps is System Settings → General → Sharing, where both Screen Sharing and Remote Management should be switched off unless a named business process depends on them.

Check which macOS build a Mac is running

sw_vers

Compare ProductVersion against the fixed builds above: 26.6.1, 15.7.9, or 14.8.9.

List and install available Apple updates

softwareupdate --list
sudo softwareupdate --install --all --restart

The machine reboots when the install completes, so run this outside active work.

Check whether anything is listening on port 5900 locally

sudo lsof -nP -iTCP:5900 -sTCP:LISTEN

Any output means the Screen Sharing service is running and accepting connections.

Check whether the Screen Sharing service is loaded

sudo launchctl print system/com.apple.screensharing

A "could not find service" response means it is not running. Anything else means it is.

Disable Screen Sharing from the command line

sudo launchctl disable system/com.apple.screensharing
sudo launchctl bootout system/com.apple.screensharing

Equivalent to switching it off in System Settings → General → Sharing, and scriptable across a fleet.

Disable legacy Remote Management (ARD) as well

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate -stop

Remote Management is a separate service from Screen Sharing and is frequently left enabled independently.

Confirm the port is not reachable from outside your network

nc -vz YOUR.PUBLIC.IP.ADDRESS 5900

Run this from a network outside your own — a mobile hotspot works. Only ever test an address your organisation controls. "Connection refused" or a timeout is the result you want; "succeeded" means you are exposed right now.

Scope note: only scan or probe addresses your organisation owns or is authorised to test. Port-scanning third-party infrastructure without permission is unlawful in most jurisdictions, including Australia.

Incident timeline

Prior to 20 August 2026

Apple ships security updates for macOS Tahoe, Sequoia, and Sonoma correcting a state-handling defect in the Screen Sharing service authentication path. The fix lands in macOS 26.6.1, 15.7.9, and 14.8.9.

20 August 2026

Public reporting identifies the flaw as an authentication bypass in the Secure Remote Password (SRP) exchange used by Screen Sharing, tracked as CVE-2026-65400. Technical writeups describe an incorrect state transition that lets the service treat an unverified session as authenticated.

20–21 August 2026

Internet-wide scanning of TCP port 5900 climbs sharply. Security vendors including Bitdefender and Malwarebytes report in-the-wild exploitation of internet-exposed Macs, with attackers obtaining root and deploying cryptocurrency mining payloads.

21 August 2026

Ars Technica reports the vulnerability as under active exploitation, giving attackers full control of affected Macs. Vendor guidance converges on three actions: patch, disable Screen Sharing, block port 5900 at the network edge.

22 August 2026 (today)

HLD Shield issues this emergency briefing. Exploitation is ongoing and requires no credentials and no user interaction. Any Mac reachable from the internet on TCP 5900 and running an unpatched build should be treated as potentially compromised, not merely at risk.

Where to look first

  • Mac build agents and CI runners — commonly headless, commonly reachable, rarely patched on a schedule.
  • Cloud-hosted and colocated Macs — these sit on public IPs by default and are the highest-probability exposure in most environments.
  • Lab, test, and demo Macs outside MDM enrolment — invisible to your patch reporting and often forgotten entirely.
  • Home-office Macs behind consumer routers — UPnP or an old port-forward may be exposing 5900 without anyone realising.
  • Macs used for remote support of executives or field staff — Screen Sharing was enabled deliberately and never turned off.
  • Personal Macs accessing corporate mail, code, or customer data — outside your control, still inside your risk.

Severity assessment

CVECVE-2026-65400
SeverityCritical
AuthenticationNone required
User interactionNone required
ImpactRoot / full control
Active exploitationConfirmed
Observed payloadCrypto-miners
Attack surfaceTCP 5900

The short version

  1. 1Update macOS to 26.6.1, 15.7.9, or 14.8.9 or later.
  2. 2Turn Screen Sharing off unless you actively use it.
  3. 3Block inbound TCP 5900 at the firewall; use a VPN instead.

Risk amplifiers

No credentials, no user interaction

The bypass defeats authentication outright rather than guessing it. Strong passwords, account lockout, and user vigilance provide no protection, which is why this is rated critical despite requiring network reachability.

Trivially discoverable exposure

TCP 5900 is a well-known, easily fingerprinted port. Attackers are not targeting specific organisations, they are sweeping the internet, so obscurity offers no shelter for small or low-profile environments.

Root, not a limited foothold

Successful exploitation yields root directly. There is no privilege-escalation step for defenders to detect or interrupt, and every secret on the device should be considered exposed.

Unattended Macs are the likely victims

Build agents, CI runners, media and lab machines, and cloud-hosted Macs are the systems most likely to be internet-exposed, least likely to be patched promptly, and least likely to have anyone notice sustained CPU load.

Crypto-mining is the visible payload, not the ceiling

Mining is what has been observed and reported, but the access obtained is unrestricted. The same access supports credential theft, lateral movement, and ransomware staging — treat mining as evidence of full compromise.

Screen Sharing is on more often than teams believe

The setting is commonly enabled during remote support and rarely turned off afterwards. Assume your enabled-device count is higher than your asset register suggests, and verify rather than estimate.

Sources

Need HLD support?

HLD can help you inventory Macs, confirm patch state across a fleet, check for internet-exposed 5900, and run a compromise assessment on any device that was reachable while unpatched.

Contact HLD

Related briefing

DarkSword: iPhone exploit chain

HLD Shield briefings are interpretive intelligence summaries based on publicly available information and HLD analytical assessment. They do not constitute formal vulnerability assessments or legal advice. Organisations should validate findings against their own environment and defer to Apple’s own security update guidance for remediation decisions. Published 22 August 2026.

More HLD Shield briefings

Stay across the full threat intelligence picture.

Back to HLD Shield