What You Need to Know About the macOS Screen Sharing Vulnerability
Apple recently patched a vulnerability in macOS Screen Sharing that could allow an attacker on the same network to bypass authentication and gain unauthorized access to a Mac. MacStadium has blocked the default Screen Sharing port at the network edge while customers patch their Macs. Here’s what Mac admins need to know and what steps to take now.
What is CVE-2026-65400?
On August 6, Apple released emergency security updates for CVE-2026-65400, an authentication vulnerability in macOS Screen Sharing. According to Apple's security documentation, an attacker on the network may be able to authenticate to Screen Sharing without valid credentials. Apple addressed the problem by improving state management.
In practical terms, the vulnerability could allow an attacker who is already on the same network as a vulnerable Mac to bypass the normal authentication process for Screen Sharing. That's significant because Screen Sharing isn't simply a way to view what's happening on a Mac. When enabled, it can provide remote access to the system. An attacker who successfully exploited the vulnerability could potentially interact with the Mac as if they had legitimate remote access.
Who is at risk?
The vulnerability is particularly relevant for organizations that use Macs as part of their development, testing, IT, or infrastructure environments. For MacStadium customers, Screen Sharing is not an incidental desktop feature. It is a standard way to reach remote Macs hosted in our data centers, and many of those systems are intentionally accessible over the internet.
Potentially affected scenarios include:
- Macs with Screen Sharing enabled
- Macs used for remote administration or support
- Shared Mac environments
- Mac build and CI infrastructure
- Developer workstations that can be accessed remotely
- Macs located on corporate, office, or other shared networks
“An attacker on the network" does not mean someone must be on the same local network. It means anyone who can reach the Screen Sharing service. In an enterprise environment, "same network" can mean shared networks, remote access infrastructure, or large numbers of connected Macs.
What makes this vulnerability concerning?
CVE-2026-65400 occurs before authentication. An attacker does not need a valid macOS account, an approved Screen Sharing user, or a legacy VNC password. Public technical analysis has demonstrated unauthenticated file access and paths to remote code execution on vulnerable systems.
Because the flaw is in the authentication path itself, rotating passwords, changing the list of allowed users, or disabling legacy VNC authentication does not fix it. The Mac must be updated to a patched version of macOS.
As with many vulnerabilities, the potential impact depends on the configuration and privileges available on the affected system. But unauthorized remote access to a developer workstation or infrastructure host can have consequences well beyond the initial connection. For organizations using Macs to build software, run CI/CD pipelines, or host development environments, that makes patching particularly important.
How did MacStadium respond?
MacStadium did not wait for every internet-exposed Mac to be updated before reducing the risk to customers. We blocked inbound traffic to TCP port 5900, the default Screen Sharing port, at the MacStadium network edge. This centrally applied action removed direct internet access to the default Screen Sharing port across MacStadium-hosted infrastructure in one step, whether or not an individual Mac had already been patched.
Blocking port 5900 was a preemptive protection for customers while host-by-host remediation was still underway. We recognize that it interrupts established workflows, but given the severity of the vulnerability and the way hosted Macs are accessed, leaving the default Screen Sharing service exposed during the patching window was not an acceptable risk. The network block provides immediate containment; customers must still update the Mac to remove the underlying vulnerability.
We have published a remediation guide for our customers. Use this guide to connect over SSH, check the installed macOS version, apply the appropriate update, and verify the patched build after the Mac restarts. After confirming the patched version, customers who require direct Screen Sharing can configure the service on an alternate port. Port 5900 will remain blocked at the MacStadium network edge. Moving Screen Sharing to a non-default port can reduce automated scanner traffic, but it is not a substitute for patching or network access controls.
SSH remains available. It is not affected by this vulnerability or by the port block. Macs behind a firewall or VPN, with no Screen Sharing port exposed to the public internet, are not at risk from internet-based exploitation of this vulnerability. Their private Screen Sharing access remains available.
What should Mac admins do?
1. Patch your Macs
Apple has fixed CVE-2026-65400 in macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9. Apple has not released a fix for macOS Ventura or earlier; Macs on those releases must be upgraded to a supported version or kept isolated with Screen Sharing disabled.
Don't assume that a Mac is safe simply because its user doesn't regularly use Screen Sharing. Patch all relevant Macs as soon as possible, including firewalled systems, powered-off systems, and machines provisioned from older restore images. A newly deployed Mac can still be vulnerable if its starting image predates the August 6 updates. Keeping macOS current is still the best way to address the underlying vulnerability.
2. Audit Screen Sharing
Take a look at where Screen Sharing is enabled across your environment.
Ask:
- Which Macs have Screen Sharing enabled?
- Why is it enabled?
- Who has access?
- Are there systems where it's no longer necessary?
- Are any internet-facing or remotely accessible systems relying on it?
- Are shared or infrastructure Macs configured differently from employee workstations?
Removing unnecessary remote-access functionality is a good security practice regardless of this particular vulnerability.
3. Consider your network exposure
The vulnerability requires network access, so network architecture matters. Organizations should consider how their Mac environments are segmented and who or what can communicate with systems running Screen Sharing.
Network controls become especially important when Macs are hosted in a data center or cloud environment. A developer's laptop may sit behind a corporate network, home router, or other layers of network protection. Hosted Mac infrastructure can have a different exposure model, particularly when remote access is an intentional part of the workflow.
For organizations running Macs at scale, putting a firewall in front of that infrastructure can provide an additional layer of control over who can communicate with those systems. At MacStadium, customers can use firewalls for hosted Mac environments to control network access and help reduce the attack surface of their Mac infrastructure.
4. Get help from MacStadium if needed
If you are a MacStadium customer and you are concerned that a Mac was compromised, do not simply patch the Mac and restore public access. Back up the files you need, then open a MacStadium Support ticket for a full wipe and reinstall. Our remediation guide includes a secure-copy example and instructions for engaging our team. If Screen Sharing stopped working before MacStadium announced the port block, or you notice unexpected activity on the Mac, contact Support before re-enabling the service.
MacStadium’s network block addresses the immediate exposure on the default port. Customers still need to update each Mac, verify the installed version, and decide how Screen Sharing should be reached going forward. If you would rather have MacStadium handle the update, reconfiguration, or a clean reinstall, open a Support ticket.
The bottom line
CVE-2026-65400is a useful reminder that Mac infrastructure needs to be treated as infrastructure, not simply as another category of endpoint. Security practices traditionally associated with servers and cloud infrastructure—patch management, network segmentation, access control, monitoring, and least privilege—matter for Mac infrastructure too.
For teams running large numbers of Macs, manually checking every machine isn't a sustainable security strategy. Centralized management and automation can make it easier to identify vulnerable systems, enforce configuration policies, and roll out security updates consistently.
Organizations should also consider which remote-access services are enabled, who can reach them, how Mac infrastructure is segmented, and whether network-level controls such as firewalls can reduce unnecessary exposure. For teams running Macs for development, CI/CD, testing, or other critical workloads, these controls become increasingly important as their Mac footprint grows.