CVE-2026-65400: macOS Screen Sharing Authentication Bypass Under Active Exploitation

Executive Summary

CVE-2026-65400 is an authentication issue in Apple’s macOS Screen Sharing service, implemented by the screensharingd daemon. Apple confirmed that an attacker on the network may be able to authenticate to Screen Sharing without valid credentials. The company patched the flaw on August 6, 2026, in macOS Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9, describing the fix as improved state management.

Independent reverse engineering indicates the flaw involves a protocol state-management weakness in the Screen Sharing authentication handshake. Because screensharingd runs as root, a successful bypass places an attacker inside a privileged network service. From that position, the file-transfer helpers used by Screen Sharing can provide root-level file access that may be converted into code execution or persistence through suitable writable locations.

Exploitation is not merely theoretical. CISA added CVE-2026-65400 to the Known Exploited Vulnerabilities Catalog on August 18, 2026, and set a federal remediation due date of August 21, 2026, under BOD 26-04. NCSC-NL has reported incidents in which internet-exposed Macs with TCP/5900 open were compromised and a Monero (XMRig) miner was deployed.

A threat actor on an underground forum has also published a downloadable list that the poster claims contains approximately 24,000 internet-accessible hosts with TCP/5900 exposed. That figure should be treated as an unverified threat-actor claim of potentially exposed hosts, not as 24,000 confirmed vulnerable or compromised Macs. Port 5900 is used by VNC and remote-desktop services across multiple operating systems, and an open port does not by itself establish that a host is an unpatched Mac running Screen Sharing.

Vulnerability Overview

CVE-2026-65400 is a critical pre-authentication vulnerability affecting macOS Screen Sharing, a remote-access service implemented by the screensharingd daemon. The service uses Apple’s proprietary RFB/VNC protocol variant over TCP/5900 and includes an SRP/RSA-SRP authentication mechanism.

The vulnerability is caused by an authentication state-management weakness that may allow an attacker on the network to reach an authenticated Screen Sharing state without providing valid credentials. Apple addressed the issue through improved state management in security updates released on August 6, 2026.

The vulnerability is rated CVSS 9.8 (Critical) and has been added to CISA’s Known Exploited Vulnerabilities catalog. Confirmed exploitation has included compromised Internet-exposed Macs and deployment of the XMRig cryptocurrency miner.

Key Details

What Is macOS Screen Sharing?

macOS Screen Sharing is an Apple-built remote desktop service implemented by the screensharingd daemon. It exposes an Apple-proprietary RFB/VNC protocol variant over TCP/5900 and allows users and administrators to remotely view and control a Mac. The service can be enabled through System Settings → General → Sharing → Screen Sharing and can also be activated through Apple Remote Desktop.

Once a client is authenticated, Screen Sharing supports remote desktop control, file transfer, clipboard sharing, and other management functions. Its file-transfer functionality relies on the SSFileCopySender and SSFileCopyReceiver helper processes.

The security impact of CVE-2026-65400 is significant because screensharingd runs as root. In addition, SSFileCopySender holds the kTCCServiceSystemPolicyAllFiles entitlement, granting Full Disk Access and allowing it to bypass normal Transparency, Consent, and Control (TCC) prompts for protected directories.

As a result, a successful authentication bypass can provide access to privileged file operations through a root-owned service. However, System Integrity Protection (SIP) remains an independent security boundary and continues to restrict access to protected system locations.

Why a Screen Sharing Compromise Extends Beyond a Single Host

A compromised Mac is rarely an isolated endpoint. Developer and administrative systems may contain source code, SSH keys, cloud credentials, VPN configurations, browser sessions, and other sensitive data that can provide access to additional systems.

A successful pre-authentication compromise of an exposed Screen Sharing service can therefore cross multiple security boundaries:

• Developer and IT workstations: May expose source code, SSH keys, cloud credentials, and authenticated browser sessions.
• Administrative Macs: May provide access to management tools, privileged accounts, or other corporate endpoints.
• Home and small-office Macs: Internet-exposed systems may have limited centralized monitoring and can be directly reachable by attackers.

The operational risk of CVE-2026-65400 therefore extends beyond the affected Mac itself. The combination of reachable TCP/5900, a pre-authentication flaw, and privileged Screen Sharing components can turn a single compromised endpoint into a potential foothold for credential theft and lateral movement.

Disclosure and Exploitation Timeline

Affected and Fixed Versions

CVE-2026-65400 affects supported macOS releases before the security updates released by Apple on August 6, 2026. The following versions contain the fix:

Apple addressed the vulnerability through improved authentication state management. Organizations should upgrade to the applicable fixed release as soon as possible, particularly for systems with Screen Sharing exposed over TCP/5900.

Root Cause: Authentication State-Machine Weakness

Apple describes CVE-2026-65400 as an authentication issue caused by improper state management. The vulnerability affects the authentication state machine used by macOS Screen Sharing and can allow a network attacker to reach an authenticated state without successfully completing the expected credential-validation process.

Independent reverse engineering provides a more detailed explanation of the failure. Public research indicates that the vulnerable path involves SRP frame-length validation and incorrect error handling. Under the vulnerable condition, an authentication-processing failure can return or retain a success state instead of cleanly propagating an authentication failure. This can cause screensharingd to advance the connection into an authenticated state before valid credentials have been verified.

Importantly, the vulnerability is not a break of the SRP cryptographic algorithm itself. The security boundary fails because the service does not reliably enforce the relationship between authentication validation and the authenticated session state.

Authentication State Machine

The Screen Sharing service uses an Apple-specific RFB/VNC protocol variant with an SRP-based authentication mechanism. During a normal connection, the client and server negotiate a security type, after which the client is expected to complete the required authentication exchange before the session can transition into an authenticated state.

Conceptually, the expected flow is:

RFB Connection
      ↓
Security-Type Negotiation
      ↓
SRP Authentication
      ↓
Credential Validation
      ↓
Authentication Success
      ↓
Authenticated Session

The vulnerable behavior occurs when malformed authentication input causes validation or state handling to fail incorrectly. Instead of reliably transitioning to an authentication-failure state, the service may retain or reach an authenticated state despite the authentication exchange not being successfully completed.

Malformed SRP Input
        ↓
Validation / State Error
        ↓
State Desynchronization
        ↓
Incorrect Authentication State
        ↓
Authenticated Session

Public research describes related pre-authentication flaws in the same codebase, but researchers differ on the exact internal mechanism and on which behavior should be attributed specifically to CVE-2026-65400. The safest interpretation is therefore to treat the detailed state-machine behavior as research-derived rather than canonical Apple implementation details.

This distinction is important: the confirmed root cause is an authentication state-management weakness; the precise packet-level mechanism remains based on independent research.

The Authentication Flow

macOS Screen Sharing uses an Apple-specific RFB/VNC protocol variant over TCP/5900. When a client connects, the server and client exchange RFB protocol information and negotiate the available security types. Modern Screen Sharing uses an SRP-based authentication mechanism, with RSA-SRP used for legitimate authenticated sessions.

Under normal conditions, the authentication process follows a defined sequence. The client establishes the RFB connection, the server advertises its supported security types, the client selects the Apple SRP mechanism, and the server validates the authentication proof before transitioning the connection into the authenticated state. Only after this transition can the client access authenticated Screen Sharing functionality.

The diagram above contrasts this expected behavior with the vulnerable path associated with CVE-2026-65400.

In the normal flow, the SRP proof is successfully validated and the authentication state is updated only after verification succeeds. This maintains the intended security boundary between an unauthenticated connection and an authenticated Screen Sharing session.

In the vulnerable flow, malformed SRP input can trigger an error during authentication processing. Public reverse engineering indicates that, under the vulnerable condition, the resulting validation failure may not be correctly propagated through the authentication state machine. This can cause the state machine to become desynchronized and potentially transition the connection into the AUTHENTICATED state without a valid SRP proof.

The important point is that CVE-2026-65400 does not require breaking the SRP cryptographic mechanism itself. Instead, the weakness is in the surrounding authentication logic: the service must ensure that an authentication failure can never result in an authenticated session.

From a security perspective, the critical invariant is:

No valid authentication proof → no authenticated session.

CVE-2026-65400 violates this expected state transition under the vulnerable condition.

Apple has not published the affected screensharingd source code or the exact packet-level trigger. Therefore, the vulnerable flow shown in the diagram should be treated as a research-derived conceptual model, not a confirmed reconstruction of Apple's internal implementation.

Two Pre-Authentication Bugs in the Same Codebase

Public research indicates that at least two independent pre-authentication flaws affected screensharingd during the same disclosure period. Although the issues share similar authentication-state behavior, researchers disagree on their precise internal mechanisms and, importantly, on which behavior should be attributed specifically to CVE-2026-65400.

Earlier Pre-Authentication Bug

The first issue was reportedly fixed silently in macOS 26.6 on July 27, 2026, without a CVE assignment. fG! and Calif describe this flaw as a stale-success return condition.

In this model, an SRP frame fails a length or parsing validation check and the function exits through an error path. However, an existing success value can be propagated back to the caller instead of a definitive authentication failure. The surrounding state machine can consequently interpret the authentication attempt as successful.

fG! subsequently published a read-only proof of concept, navi_the_clown, demonstrating arbitrary file retrieval when the relevant file path is known. Public research also reports that this variant does not require a valid account name.

CVE-2026-65400

CVE-2026-65400 was patched by Apple on August 6, 2026. Independent reverse engineering describes the vulnerability as an authentication-state failure in which malformed SRP input can interfere with validation and cause the authentication state machine to become desynchronized.

Under this model, the connection may reach an authenticated state even though the expected credential-verification process has not successfully completed.

Some public analyses indicate that this path may require a valid account name. However, Apple does not document a valid username as an explicit prerequisite in its security advisory. On systems where usernames are exposed through the login interface, this requirement may also be relatively easy for an attacker to satisfy.

Attribution Differences

The primary source of confusion is the attribution of the stale-success mechanism. Huntress and some public proof-of-concept analyses associate that behavior directly with CVE-2026-65400. Calif, however, distinguishes the stale-success behavior as the earlier July vulnerability and describes CVE-2026-65400 separately as an authentication-state desynchronization issue.

These differences are important when describing the technical root cause. Rather than presenting one reconstruction as definitive, this article treats the published analyses as complementary research accounts and clearly distinguishes vendor-confirmed information from independently reconstructed behavior.

Apple has not published the affected screensharingd source code or the exact packet-level trigger. Consequently, the precise internal state-machine behavior described by researchers should be regarded as a research-derived model rather than a canonical description of Apple's implementation.

From a defensive perspective, the distinction does not reduce the urgency: any unpatched Screen Sharing service that is reachable by an attacker should be considered at risk of pre-authentication exploitation and should be patched, restricted, or disabled.

Conceptual Code-Level Reconstruction

The following pseudocode is a conceptual reconstruction of a flawed SRP frame handler. It is not disassembly and not actual Apple source code. It is intended only as a mental model for how a missing error return or stale success value can cause the authentication state machine to advance despite a failed validation:

// Conceptual reconstruction — not actual Apple source
int srp_process_frame(Session *s, const uint8_t *frame, size_t len) {
    // A length or parsing check fails. Instead of propagating failure,
    // the function returns a stale success value to the caller.
    if (len < MIN_SRP_FRAME_LEN || frame[0] != EXPECTED_SRP_MSG_TYPE) {
        // Missing: return AUTH_FAILURE;  ← the conceptual fix
        goto cleanup;  // returns last_status, possibly still AUTH_SUCCESS
    }

    // Normal SRP proof validation would happen here.
    // In the vulnerable path it is skipped because the state machine
    // already believes the step succeeded.

cleanup:
    return last_status;  // may still be AUTH_SUCCESS from a prior step
}

// Caller sees AUTH_SUCCESS and advances state to AUTHENTICATED.
// The session may continue without the cryptographic protections
// that a completed SRP handshake would normally provide.

This reconstruction is intentionally simplified. Apple has not published the affected source code, and public researchers have described two related pre-authentication flaws in the same codebase. The state-machine model should therefore be treated as a research-derived explanation, not as verified Apple source code or a guaranteed packet-level exploit recipe.

Why Pre-Authentication Changes the Risk Model

The pre-authentication nature of CVE-2026-65400 significantly increases its risk because the authentication barrier is bypassed before normal credential validation takes place.

Three factors are particularly important:

• Account restrictions are insufficient: Limiting Screen Sharing to specific users does not address a vulnerability that occurs during the authentication process itself.
• Password changes do not fix the flaw: Rotating Screen Sharing or VNC credentials does not remediate the underlying authentication state-management weakness.
• Network exposure is the critical condition: An attacker must be able to reach the vulnerable Screen Sharing service. NCSC-NL reported exploitation of systems with TCP/5900 accessible from the Internet.

Therefore, an exposed and unpatched Screen Sharing service should be treated as a high-risk attack surface regardless of the configured Screen Sharing accounts or password settings.

Attack Chain: From Internet Exposure to Possible Code Execution

CVE-2026-65400 does not directly provide arbitrary command execution. Instead, successful exploitation can bypass the Screen Sharing authentication boundary and provide access to privileged file-transfer functionality. Depending on the available writable locations and macOS security controls, this access may subsequently be used for sensitive data theft, persistence, or possible code execution.

Public research indicates that exploitation can be triggered with a relatively small number of malformed protocol messages and does not rely on traditional memory-corruption techniques such as heap grooming or ASLR bypasses.

1. Reconnaissance

The attacker acquires or generates a list of hosts with TCP/5900 open. The underground forum post claims roughly 24,000 such hosts, but the figure should be treated as an unverified threat-actor claim. Public scans around the same disclosure window found tens of thousands of internet-facing port-5900 services; an independent @osxreverser scan cited by Calif found around 40,000 reachable Macs with Screen Sharing.

# Example authorized discovery command
nmap -p 5900 --open -Pn target-range.example.com/24

# runZero query to identify Apple macOS hosts with port 5900
os:="Apple macOS%" AND port:5900 AND protocol:vnc

2. RFB / Protocol Handshake

The client establishes a TCP connection to port 5900 and performs the RFB protocol negotiation. Apple Screen Sharing uses an RFB 003.889 banner and advertises supported security types, including the Apple-specific SRP authentication mechanism.

At this stage, identifying the protocol is useful for distinguishing potential Apple Screen Sharing services from generic VNC deployments.

3. SRP Authentication Bypass

The client selects security type 36 and sends a malformed SRP message. In the vulnerable path, the frame-length validator bails out early or the state machine desynchronizes, and a stale success value or missing error return causes the daemon to treat the connection as authenticated before any credential proof is verified.

4. Authenticated Session Established

Following the authentication-state failure, the connection may be treated as authenticated even though the expected credential-validation process was not successfully completed.

Public research indicates that, for the CVE-2026-65400 desynchronization path, the failure occurs before the normal authenticated session is fully established. Once the service accepts the connection as authenticated, the client can access Screen Sharing functionality that would normally require successful authentication.

Because screensharingd runs as root, the resulting service context is highly privileged, although individual helper processes remain subject to their own entitlements and macOS security boundaries.

5. Privileged File Operations via SSFileCopy Helpers

Screen Sharing provides file-transfer functionality through SSFileCopySender and SSFileCopyReceiver.

SSFileCopySender operates with privileged access and holds the kTCCServiceSystemPolicyAllFiles entitlement, providing Full Disk Access. This can allow access to protected user data without triggering the normal TCC consent prompts.

However, TCC and SIP are separate security mechanisms. Full Disk Access does not automatically bypass System Integrity Protection, and certain protected system locations remain restricted.

6. File Read/Write and Possible RCE

Privileged file access can expose sensitive information including SSH keys, browser data, credentials, source code, and other protected files, depending on the applicable macOS security controls.

File-write capabilities may also provide a path to persistence or code execution when a suitable execution-triggering location is writable. The important distinction is that this is a post-authentication exploitation chain rather than automatic command execution provided directly by CVE-2026-65400.

7. Post-Exploitation and Persistence

Once privileged access has been obtained, attackers may attempt to maintain access, steal credentials, or monetize the compromised system.

Potential post-exploitation activities include:

• Creating or modifying persistence mechanisms such as LaunchDaemons.
• Adding unauthorized SSH keys.
• Modifying user startup or other writable execution locations.
• Deploying cryptocurrency-mining software such as XMRig.
• Altering firewall configuration or other security controls.
• Using stolen credentials or keys for subsequent lateral movement.

NCSC-NL has specifically reported XMRig deployment in real-world exploitation. Other artifacts, including unauthorized SSH keys, LaunchDaemons, or firewall modifications, should be treated as plausible investigation targets rather than confirmed NCSC-NL campaign artifacts.

Representative Protocol Exchange

The following exchange is a conceptual illustration of the protocol messages that may occur during a vulnerable session. Exact byte sequences depend on the specific proof-of-concept implementation and on which of the two pre-auth bugs is targeted. It is not a guaranteed exploit recipe.

# Conceptual protocol exchange (illustrative, not a verified exploit recipe)
Client → Server: RFB 003.889 banner
Server → Client: RFB 003.889 banner

Server → Client: supported security types, including Apple SRP (type 36)
Client → Server: selects Apple SRP (type 36)

Client → Server: malformed SRP authentication message

# Server state machine incorrectly advances to AUTHENTICATED
Server → Client: security result = success

# Session continues without the protections of a completed SRP handshake
Client → Server: authenticated Screen Sharing operation
Client → Server: privileged file-operation request
Server → Client: file-operation response (read or write data)

This reconstruction is useful for defensive analysis and detection engineering. It should not be treated as confirmed wire-level exploit traffic.

How Researchers Find Exposed Hosts

Researchers and threat actors use the same basic internet-scanning techniques to identify TCP/5900 listeners. The exact tooling used for the @osxreverser scan that Calif cites (~40,000 reachable Macs) has not been published, but the methodology is well understood: perform a TCP SYN scan of the IPv4 address space for port 5900, then banner-grab promising hosts to identify the RFB version and, where possible, the operating system.

Masscan and zmap are the most common high-speed scanners. They can scan the entire public IPv4 space for a single port in hours. Nmap is then used for slower, more accurate banner and service identification. Shodan, Censys, and runZero provide ready-made query interfaces for the same data.

Typical Exposed-Host Workflow

• Masscan/zmap: SYN-scan large netblocks (or the entire IPv4 space) for open TCP/5900.
• Nmap banner grab: identify RFB 003.889 banners and security-type advertisements.
• OS fingerprinting: combine the banner with nmap OS detection or runZero asset data to guess macOS.
• Geolocation / ASN mapping: produce country, ISP, and organization breakdowns for the resulting list.

The resulting count is a snapshot of internet-reachable port-5900 services, not a census of vulnerable Macs. Many hosts in such a list will be Linux or Windows VNC servers, patched Macs, or honeypots. The underground ~24,000-host list and the @osxreverser ~40,000-host figure are therefore best understood as upper-bound reconnaissance datasets.

Example Scan Commands

The following commands must be run only against networks you own or have explicit written authorization to scan.

# High-speed SYN scan of a large range for TCP/5900
masscan -p5900 0.0.0.0/0 --max-rate 10000 -oG masscan-5900.grep

# Slower, accurate banner and service identification on the open hosts
nmap -p5900 -sV -sS -Pn --open -iL open-5900-hosts.txt -oA nmap-5900-banners

# Filter for Apple Screen Sharing banner in the nmap output
grep -i "RFB 003.889" nmap-5900-banners.nmap

# runZero query for Apple macOS hosts with port 5900
os:="Apple macOS%" AND port:5900 AND protocol:vnc

# Shodan query for VNC / Apple Remote Desktop services
shodan search "port:5900 RFB" --fields ip_str,port,org,os

# Censys query for VNC services on port 5900
censys search "services.port: 5900 and services.service_name: VNC" --pages 1

Interpreting the Results

A list of ~40,000 open TCP/5900 hosts therefore contains:

• Confirmed Apple Screen Sharing / Apple Remote Desktop listeners (RFB 003.889 banner).
• Generic third-party VNC servers on Linux, Windows, or other operating systems.
• Patched Macs that still leave the service reachable.
• Honeypots, NAT redirects, and misconfigured services.

Only a targeted, authorized probe can confirm whether a specific host is an unpatched Mac. Scan counts are useful for estimating exposure and prioritizing patching; they are not proof of vulnerability or compromise.

Public Proof-of-Concept Code

Several working proof-of-concept implementations have been published on GitHub. They demonstrate the practical exploitation of CVE-2026-65400 and are valuable references for defenders who need to understand the protocol behavior and for authorized red-team testing in isolated labs.

• panchocosil/CVE-2026-65400-poc — read-only Python PoC. It connects to TCP/5900, performs the RFB/SRP handshake, triggers the pre-auth bypass, and reads root-only files such as /etc/sudoers, /etc/passwd, and /etc/master.passwd. The bug is described as racy and may require retries. Patched hosts are detected and not retried.
• acheong08/CVE-2026-65400 — extended Python PoC derived from the read-only version that adds arbitrary file write and achieves RCE. It can write LaunchDaemon plists for persistence or overwrite existing privileged helper tools (for example Microsoft AutoUpdate, ZoomDaemon, TeamsUpdaterDaemon) for immediate execution.
• HORKimhab/CVE-2026-65400 — draft PoC with read, write, and exec commands, including reverse-shell capability (reportedly SIP-disabled only).
• initconf/zeek-screensharing-rce — Zeek detection package that observes the same protocol artifacts in network traffic.

The existence of public read/write PoCs lowers the exploit barrier significantly. A defender should assume that any internet-exposed, unpatched Screen Sharing listener can be compromised with off-the-shelf tooling.

Lab Setup and Validation

The purpose of a lab is to validate exposure, patch status, and detection logic, not to prove full exploitability against production systems. The following setup reproduces the network and endpoint artifacts for authorized testing.

Lab Components

• Target: unpatched macOS VM or bare-metal host with Screen Sharing enabled (version before 26.6.1 / 15.7.9 / 14.8.9).
• Attacker: Linux or macOS host on the same isolated network segment with Python 3 and the public PoC cloned.
• Network capture: tcpdump / Wireshark on the target segment to observe the RFB 003.889 banner and SRP exchange.
• Endpoint telemetry: ES collector or red-team telemetry tool to capture ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH events.
• Network detection: Zeek or Suricata instance with the initconf/zeek-screensharing-rce package.

Prepare the Target VM

# Enable Screen Sharing (equivalent to System Settings → General → Sharing → Screen Sharing → On)
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.screensharing.plist

# Verify screensharingd is listening on TCP/5900
sudo lsof -i :5900

# Confirm the target is unpatched
sw_vers -productVersion
# Expected vulnerable output: 26.6, 15.7.8, 14.8.8, or earlier.

Run the Read-Only PoC

# Clone the public PoC
git clone https://github.com/panchocosil/CVE-2026-65400-poc.git
cd CVE-2026-65400-poc

# Read /etc/sudoers (default target)
python3 poc_screensharing.py <TARGET_IP>

# Read /etc/master.passwd with 50 retries and a longer timeout
python3 poc_screensharing.py <TARGET_IP> /etc/master.passwd -r 50 -t 10

# Expected success output:
#   [+] Banner: RFB 003.889
#   [+] Security types include SRP (36)
#   [+] SecurityResult = 0 (authenticated)
#   [+] File content: ...

# Expected patched output:
#   [-] SecurityResult != 0 or SRP type not advertised
#   [-] Host does not appear vulnerable (or is patched)

Security Impact

CVE-2026-65400 has a high security impact because it combines a pre-authentication bypass with a root-privileged Screen Sharing service. A successful attack can provide access to privileged file operations without requiring valid credentials.

1. Root-Privileged File Access

The screensharingd daemon runs as root. Bypassing its authentication gate therefore gives the attacker an authenticated session inside a root-privileged service, not merely a desktop viewing session. Through SSFileCopySender the attacker can read and write files that root can access, subject to SIP and other macOS protections.

2. Arbitrary File Read and Data Theft

Full Disk Access lets the attacker read user keychains, browser profiles, cloud tokens, SSH private keys, source code, and system secrets such as /etc/sudoers without triggering TCC dialogs, as long as the paths are not protected by SIP.

3. Remote Code Execution and Persistence

Write access to writable system and user locations enables multiple RCE and persistence vectors: LaunchDaemons, shell startup files, and SSH authorized_keys. Cron-based persistence is limited on SIP-enabled systems. Persistence mechanisms can survive reboots and user logouts.

4. TCC Bypass, Not SIP Bypass

The SSFileCopySender entitlement grants kTCCServiceSystemPolicyAllFiles, which bypasses the normal TCC prompts for protected directories. However, System Integrity Protection (SIP) continues to restrict writes to certain system directories. The bug defeats authentication and TCC consent prompts; it does not defeat SIP.

5. Lateral Movement

A compromised Mac becomes a foothold inside the network. SSH keys, VPN configurations, and cached credentials stolen from the Mac can be used to pivot to other systems, cloud tenants, or identity providers.

6. Resource Abuse and Financial Motivation

Confirmed in-the-wild activity includes deployment of the XMRig Monero miner. Opportunistic attackers are motivated by cryptocurrency profit today, but the same access vector could be repurposed for ransomware, credential theft, or espionage tomorrow.

7. Supply-Chain and Trust Impact

If a developer or build Mac is compromised, attackers can inject code into software projects, sign malicious updates with stolen signing identities, or pivot into CI/CD pipelines. The blast radius extends beyond the single endpoint.

Overall Impact

CVE-2026-65400 is a pre-authentication vulnerability in a root-privileged network service. It removes the authentication barrier, grants root-level file access through privileged helpers, and is being actively exploited against internet-exposed systems. The correct response is to treat every unpatched, reachable TCP/5900 Mac as potentially compromised until a host-forensics review rules out attacker activity.

Fix and Mitigation

Organizations should treat CVE-2026-65400 as a high-priority vulnerability because exploitation has been confirmed against Internet-exposed macOS systems. The primary remediation is to install Apple’s security updates and remove unnecessary exposure of Screen Sharing.

Immediate Actions

1. Patch affected systems immediately.
   Upgrade to macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9. These releases contain Apple’s security fix for the vulnerability.
2. Disable Screen Sharing when it is not required.
   Navigate to System Settings → General → Sharing → Screen Sharing and disable the service.
3. Block TCP/5900 from the Internet.
   Prevent Screen Sharing and VNC services from being directly accessible from untrusted networks.
4. Restrict required remote access.
   If Screen Sharing is necessary, limit it to trusted networks and place the service behind a VPN, firewall policy, or jump host rather than exposing TCP/5900 publicly.
5. Investigate previously exposed systems.
   Identify Macs that were reachable over TCP/5900 while running a vulnerable version. Treat these systems as potentially compromised until appropriate forensic checks have been completed.
6. Hunt for signs of compromise.
   Look for unexpected SSH keys, unauthorized LaunchDaemons, suspicious high-CPU processes such as XMRig, modified firewall rules, unusual Screen Sharing sessions, and other unexpected system changes.

Long-Term Hardening

• Enforce security updates through MDM to reduce patching delays.
• Maintain an inventory of Internet-facing services and regularly review unnecessary exposure.
• Monitor inbound TCP/5900 connections from untrusted networks.
• Collect Screen Sharing and file-transfer telemetry for security monitoring.
• Segment Macs containing sensitive credentials, source code, or signing identities from general user networks.
• Regularly audit authorized_keys, LaunchDaemons, and other persistence locations for unauthorized modifications.
• Use VPN or jump-host access for remote administration instead of exposing Screen Sharing directly to the Internet.
• Do not rely on password rotation alone as a mitigation; the authentication state-management flaw must be patched or the service disabled.

Detection Artifacts and Indicators

The following artifacts can help defenders identify exposed systems, suspicious Screen Sharing activity, and potential post-exploitation activity associated with CVE-2026-65400. Not every indicator confirms exploitation. Network exposure and protocol characteristics should be treated as discovery or heuristic signals, while endpoint and filesystem artifacts require correlation with other evidence.

Conclusion

CVE-2026-65400 is a critical pre-authentication vulnerability in the root-privileged macOS Screen Sharing service. Apple confirms that an attacker on the network may authenticate to Screen Sharing without valid credentials and describes the fix as improved state management. Independent research provides additional insight into the affected authentication state machine, although the exact packet-level mechanism remains research-derived.

Once the authentication barrier is bypassed, the attacker may reach privileged Screen Sharing file-transfer functionality. Real-world incidents have demonstrated the potential impact, including root access and deployment of the XMRig cryptocurrency miner. Further RCE and persistence depend on available writable locations and macOS security controls.

The reported ~24,000-host underground list should be viewed as a reconnaissance resource rather than a confirmed count of vulnerable or compromised Macs. Nevertheless, it highlights the risk posed by Internet-exposed TCP/5900 services.

Organizations should prioritize three actions: patch affected Macs, remove Internet exposure of Screen Sharing, and investigate previously exposed systems for signs of compromise. With active exploitation confirmed and the vulnerability listed in CISA KEV, exposed unpatched systems should be treated as a high-priority security risk.