A Mac with Screen Sharing exposed to the internet is not merely offering remote desktop. Before Apple’s August update, it could offer an attacker a path past authentication—and incident reports now make the difference between “vulnerable” and “compromised” operationally important.

CVE-2026-65400 affects Screen Sharing in macOS. Apple described a network attacker being able to authenticate without valid credentials and addressed the problem through improved state management. The Dutch National Cyber Security Centre later reported exploitation against internet-exposed systems, where attackers obtained root access and installed cryptocurrency miners.

TL;DR

  • Update to macOS Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9, or a later fixed release.
  • Do not expose TCP 5900 or Screen Sharing directly to the internet, even after patching.
  • Treat a previously exposed, unpatched Mac as an incident-response candidate—not just a patching task.
  • Hunt for unexpected remote sessions, privileged processes, persistence, miners, and outbound connections.

Why This Is More Than a Desktop Bug

Screen Sharing is often enabled for convenience on lab Macs, build machines, help-desk targets, and systems tucked behind “temporary” router rules. Those exceptions tend to outlive the reason they were created.

The vulnerable service sits on an authentication boundary. If an attacker reaches it and bypasses that decision, the graphical desktop is only the visible part of the access. A session may expose files, browser data, developer credentials, mounted shares, password prompts, and administrative workflows. Reports of root-level compromise raise the incident scope further.

Apple’s wording says an attacker “on the network” may authenticate without valid credentials. That does not mean every Mac is remotely exploitable from anywhere: the service must be enabled and reachable. It does mean defenders should inventory exposure rather than assume a fleet-wide CVSS score answers the risk question.

🔴 RED TEAM — The Practical Attack Path

Screen Sharing is enabled
        ↓
TCP 5900 is reachable from an attacker-controlled network
        ↓
CVE-2026-65400 bypasses the expected authentication state
        ↓
The attacker establishes remote access
        ↓
Privilege, credentials, persistence, and local data become follow-on targets

Internet exposure is the obvious route, but it is not the only one. A compromised workstation, hostile guest network, flat office LAN, or breached VPN account can put an attacker “on the network.” Restricting the service to a management segment reduces the number of systems that can even attempt the first connection.

Cryptomining is noisy and easy to understand, but it should not define the maximum impact. A miner is one payload choice. The same access can support credential theft, data collection, tampering, or a quieter foothold.

🔵 BLUE TEAM — Patch, Scope, and Hunt

Confirm the Fixed Version

Install Apple’s fixed August releases or a later supported version. Verify the version on every Mac rather than trusting that automatic updates completed. Managed fleets should query device inventory and flag both vulnerable builds and update failures.

For a local check:

Terminal window
sw_vers -productVersion
sudo lsof -nP -iTCP:5900 -sTCP:LISTEN

The first command confirms the OS version. The second identifies a local listener; an empty result does not prove that Screen Sharing was never enabled or that a different remote-management service is absent.

Remove Direct Exposure

Disable Screen Sharing where it is not required. Where remote administration is necessary, place it behind a VPN or tightly controlled management network, restrict source addresses, and keep administrative identities separate from daily-use accounts.

Check edge firewalls, cloud security groups, host firewalls, router forwarding rules, and remote-management tooling. A host setting can look correct while an old network rule still creates the route attackers need.

Investigate Systems That Were Reachable

Build a timeline covering the period before patch installation. Review:

  • Screen Sharing, authentication, and unified-log activity for unexpected sources or times;
  • new launch agents, launch daemons, login items, users, SSH keys, or configuration profiles;
  • unusual root-owned processes, high CPU usage, mining pool traffic, or newly downloaded binaries;
  • browser sessions, developer tokens, cloud credentials, keychains, and mounted network shares accessible from the Mac;
  • outbound connections and DNS requests that continue after the remote service is disabled.

Preserve relevant logs before cleaning the machine. If unauthorized root access is supported by evidence, rebuilding from a trusted source and rotating exposed credentials is safer than deleting the obvious miner and declaring victory.

What to Do Today

  1. Find Macs running Screen Sharing or listening on TCP 5900.
  2. Identify which were reachable from the internet, VPN users, guest networks, or broad internal segments.
  3. Patch them to a fixed release and verify the installed version.
  4. Remove unnecessary exposure and require a controlled management path for the rest.
  5. Investigate previously exposed systems and rotate credentials when the evidence warrants it.

Remote access should be treated as infrastructure, not a checkbox in System Settings. Give it an owner, an allowed-source list, logging, and an expiry date. Convenience is not a durable network boundary.

Sources