← Back to Feed CACHED · 2026-10-07 10:25:55 · CACHE_KEY CVE-2026-65400
CVE-2026-65400 · CWE-287 · Disclosed 2026-08-06

macOS Screen Sharing (screensharingd) SRP Pre-Authentication Bypass

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

It's like leaving a skeleton key under the mat — except the mat is the internet and the key opens every room in the house

CVE-2026-65400 is a pre-authentication bypass in the macOS Screen Sharing daemon (screensharingd), the built-in VNC server listening on TCP/5900. A flaw in Apple's SRP (Secure Remote Password) state machine means that sending a single malformed, oversized SRP frame causes the daemon's frame-length validator to return a stale success status left over from the preceding operation. The attacker's connection is marked authenticated without any cryptographic verification, and because screensharingd runs as root, the session inherits root-level file access via built-in helpers (SSFileCopySender/SSFileCopyReceiver). On SIP-disabled systems, crontab injection yields a reverse shell; on SIP-enabled systems, SSH-key injection into /var/root/.ssh/authorized_keys or LaunchDaemon creation achieves persistence. Affected versions: macOS Tahoe < 26.6.1, macOS Sequoia < 15.7.9, macOS Sonoma < 14.8.9.

Apple's CRITICAL / 9.8 rating is accurate and, if anything, arrived late. Apple initially scored the flaw at 7.1 before CISA rescored it to 9.8 on August 14, 2026. The NCSC-NL confirmed that every internet-exposed Mac they examined with port 5900 open had been compromised — a 100% hit rate. The attack requires zero authentication, zero user interaction, and zero complexity. Public PoC code appeared on July 29 (fG!'s initial read-only exploit) and a full read/write/RCE variant was public by August 2. This is not a theoretical vuln — it is an active, mass-exploitation event.

"Every internet-exposed Mac with Screen Sharing on was owned. Every single one."
02 · The Attack Path

6 steps from start to impact.

STEP 01

Reconnaissance — Identify Macs with Screen Sharing enabled

The attacker scans for TCP/5900 listeners using masscan, nmap, or Shodan. The RFB banner (RFB 003.889) immediately distinguishes macOS Screen Sharing from generic VNC. Underground forums published lists claiming ~24,000 internet-reachable hosts; @osxreverser cited ~40,000 reachable Macs.
Conditions required:
  • Target Mac has Screen Sharing enabled (off by default)
  • TCP/5900 is reachable from attacker's network position
Where this breaks in practice:
  • Screen Sharing is OFF by default in macOS — requires explicit admin enablement
  • Most enterprises do not expose port 5900 to the internet; perimeter firewalls typically block it
Detection/coverage: GreyNoise and Shodan track port 5900 scanning activity. Perimeter IDS should alert on mass-scan reconnaissance patterns.
STEP 02

RFB Handshake — Connect and negotiate the protocol

The attacker initiates a standard RFB (Remote Framebuffer) connection to port 5900. The daemon responds with its protocol version and supported security types. No credentials are exchanged at this stage. This is indistinguishable from a legitimate connection attempt.
Conditions required:
  • Network path to port 5900 established
Where this breaks in practice:
  • None once port is reachable
Detection/coverage: Network flow logs; Zeek package initconf/zeek-screensharing-rce monitors for protocol desync indicators in the RFB handshake.
STEP 03

SRP Frame Manipulation — Bypass authentication entirely

The attacker sends a crafted SRP frame with an oversized length field. The daemon's frame-length validator erroneously returns a stale success status from the preceding operation, marking the session as authenticated without completing SRP cryptographic verification. The session registers as 'plain SRP' rather than the legitimate 'RSA-SRP.' The exploit is deterministic — it works every time. Tool: CVE-2026-65400.py from HORKimhab/CVE-2026-65400.
Conditions required:
  • None beyond Step 2 — no credentials, no user interaction
Where this breaks in practice:
  • Zero — the exploit is deterministic and reliable on every unpatched, listening host
Detection/coverage: Endpoint Security ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH events showing authentication_type: SRP (legitimate sessions show RSA-SRP) or session_username: root (root is disabled by default).
STEP 04

Root File Access — Read and write arbitrary files

With an authenticated session running as root, the attacker leverages SSFileCopySender and SSFileCopyReceiver helpers to read and write any file on the filesystem. Confirmed targets include /etc/shadow, Safari browsing history, SSH private keys, and system configuration files.
Conditions required:
  • Successful authentication bypass (Step 3)
Where this breaks in practice:
  • None — file helpers are built into Screen Sharing and run as root
Detection/coverage: Monitor for SSFileCopySender processes running as UID/GID 0 with unexpected file paths. Alert on the specific invocation pattern: SSFileCopySender 0 80.
STEP 05

Persistence — Establish long-term root access

Attackers write SSH public keys to /var/root/.ssh/authorized_keys, create malicious LaunchDaemons in /Library/LaunchDaemons/, or modify /etc/sudoers. On SIP-disabled systems, crontab injection provides an additional vector. Observed in-the-wild: XMRig 6.26.0 deployed as .config/sysmond, firewall rules modified to allow mining pool traffic.
Conditions required:
  • Root file write capability (Step 4)
  • SIP disabled for crontab-based RCE (not required for SSH key or LaunchDaemon persistence)
Where this breaks in practice:
  • SIP blocks crontab injection on default configurations, but SSH key and LaunchDaemon persistence work regardless of SIP status
Detection/coverage: File integrity monitoring on /var/root/.ssh/, /Library/LaunchDaemons/, /etc/sudoers. Process monitoring for unexpected binaries in user-writable paths.
STEP 06

Impact — Full host compromise with lateral movement potential

The attacker has persistent root access. Observed campaigns deploy Monero miners (XMRig), but the access equally supports data exfiltration, credential harvesting, lateral movement to other internal systems, and supply-chain attacks via compromised developer signing certificates or CI/CD tokens.
Conditions required:
  • Persistence established (Step 5)
Where this breaks in practice:
  • None — at this point the attacker owns the host
Detection/coverage: EDR behavioral detections; network monitoring for mining pool traffic (Stratum protocol); host-based anomaly detection for unexpected outbound connections.
03 · Compensating Control

1
CRITICAL 9.8→HIGH 6.8
SEVERITY REDUCED
Block TCP/5900 at the perimeter immediately — Create firewall rules blocking inbound TCP/5900 from all untrusted networks. This is a CRITICAL KEV-listed vuln under active exploitation — deploy within hours, not days. This eliminates the internet-facing attack surface entirely but does not protect against internal lateral movement by an attacker already inside the network.
2
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Disable Screen Sharing fleet-wide via MDM — Push a configuration profile via Jamf/Kandji/Mosyle/Intune that disables Remote Management and Screen Sharing (com.apple.screensharing and com.apple.RemoteManagement). Deploy within the noisgate mitigation SLA of 3 days for CRITICAL. This kills the listening daemon entirely — no port, no attack surface, no exploit path.
3
CRITICAL 9.8→IGNORE 0.0
SEVERITY REDUCED
Apply macOS patches (Tahoe 26.6.1, Sequoia 15.7.9, Sonoma 14.8.9) — The definitive fix. Deploy within the noisgate remediation SLA of 90 days for CRITICAL, but given active exploitation with patches available since August 6, push within 3 days alongside control #2. This fixes the root cause and allows Screen Sharing to be re-enabled safely.
4
CRITICAL 9.8→MEDIUM 5.3
SEVERITY REDUCED
Restrict Screen Sharing to VPN/jump-host only — If Screen Sharing must remain enabled for IT support workflows, ensure it is reachable only through an authenticated VPN tunnel or a hardened jump host — never directly from user VLANs or the internet. Deploy within 3 days. This raises attacker cost by requiring VPN or jump-host compromise first.
5
CRITICAL 9.8→CRITICAL 9.8
Deploy Zeek monitoring and endpoint detection — Install initconf/zeek-screensharing-rce on network sensors to detect protocol-desync indicators. Alert on ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH with authentication_type: SRP (legitimate = RSA-SRP) and session_username: root. Deploy within 3 days. Detection does not prevent exploitation but dramatically improves response time for active compromise.
What doesn't work
  • Setting a VNC password — the exploit bypasses the entire authentication layer, including legacy VNC password checks. A VNC password provides zero protection against this attack.
  • Restricting Screen Sharing to specific user accounts — the exploit authenticates without any credentials and inherits root access regardless of account restrictions or user-level access controls.
  • Relying on SIP alone as mitigation — SIP blocks crontab-based RCE but does NOT prevent root-level file read/write. Attackers use SSH key injection into /var/root/.ssh/authorized_keys and LaunchDaemon creation instead, both of which work with SIP enabled.
  • macOS Application Firewall — the built-in Application Firewall does not block connections to system services like Screen Sharing by default. It must be explicitly configured to block screensharingd, which is not a standard configuration.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusYES — confirmed mass exploitation. NCSC-NL reported that every internet-exposed Mac with port 5900 reachable was compromised. XMRig 6.26.0 Monero miners deployed at scale. Underground forums circulated target lists of ~24,000 hosts. NCSC-NL advisory, August 12, 2026
Proof-of-conceptPublic and weaponized. HORKimhab/CVE-2026-65400 — Python script performing SRP bypass, arbitrary file read/write, and reverse shell (SIP-disabled targets). Initial PoC by Pedro Vilaça (fG!) on July 29, 2026 ('It's a pre-auth, stupid!'). Full read/write/RCE variant by bl4sty (warez.sl0p.foo) by August 2, 2026. CTIPilot confirmed remote-root impact August 11.
EPSS score0.01723 (1.7%) — notably low for a KEV-listed, actively exploited vulnerability. This likely reflects EPSS model lag; the score should be treated as stale and unreliable for prioritization. Actual exploitation probability is effectively 100% on exposed hosts.
KEV statusListed August 18, 2026. Federal remediation deadline: August 21, 2026 (BOD 26-04). CISA rescored from Apple's original 7.1 to 9.8 on August 14, 2026.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 9.8. Network-accessible, low attack complexity, no privileges required, no user interaction. Full confidentiality, integrity, and availability impact. Scope unchanged (exploit runs within the host's own authorization zone).
Affected versionsmacOS Tahoe ≤ 26.5.2, macOS Sequoia ≤ 15.7.7, macOS Sonoma ≤ 14.8.7 — all three current macOS release trains are affected.
Fixed versionsmacOS Tahoe 26.6.1, macOS Sequoia 15.7.9, macOS Sonoma 14.8.9 — all released August 6, 2026. A first silent patch attempt landed in macOS 26.6 on July 27, but was incomplete.
Scanning / exposure~24,000–40,000 Macs with TCP/5900 reachable from the internet (per underground forum lists and @osxreverser scans). Port 5900 is shared with generic VNC across OSes; not all listeners are vulnerable macOS hosts. Internal exposure is harder to quantify but likely higher — IT support teams commonly enable Screen Sharing on managed fleets.
Disclosure timelineJuly 27: First pre-auth bug silently patched (macOS 26.6). July 29: fG! publishes 'It's a pre-auth, stupid!' with read-only PoC. Aug 1–2: bl4sty develops full RCE variant. Aug 6: Apple releases patches. Aug 7: NCSC-NL flags vulnerability. Aug 12: Active exploitation confirmed. Aug 14: CISA rescores to 9.8. Aug 18: Added to KEV.
Reporting researcherPedro Vilaça (fG!) — initial discovery and read-only PoC. bl4sty — reverse-engineered wire format, developed full read/write/RCE variant. CTIPilot — independent confirmation of remote-root impact. Calif — secondary analysis citing @osxreverser exposure scans.

Sources.

  1. Arctic Wolf — CVE-2026-65400 Analysis
  2. Resecurity — macOS Screen Sharing Auth Bypass Under Active Exploitation
  3. Huntress — From Screen Share to Root Access
  4. Tanium — Critical macOS Screen Sharing Authentication Bypass
  5. Hard2bit — CVE-2026-65400: Root Without a Password on macOS
  6. SecPod — August 2026 KEV Alert
  7. HORKimhab/CVE-2026-65400 — GitHub PoC Repository
  8. The Hacker News — Critical macOS, SharePoint, vCenter Flaws Under Active Exploitation
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.8/10)

Why this verdict

  • Zero-auth, zero-click, zero-complexity attack. The CVSS vector AV:N/AC:L/PR:N/UI:N is not aspirational — it is the literal exploit chain. One malformed SRP frame, one root session. No credentials, no phishing, no user interaction required.
  • Active mass exploitation with 100% hit rate on exposed hosts. NCSC-NL confirmed that every internet-exposed Mac with port 5900 reachable was compromised. This is an ongoing campaign, not a theoretical risk. KEV-listed August 18, 2026.
  • Public weaponized PoC since July 29, 2026. Multiple working exploits are available on GitHub (HORKimhab/CVE-2026-65400). The exploit is a single Python script. The barrier to entry for any attacker is zero.
  • Role multiplier: developer workstations and CI/CD Mac build servers are supply-chain-critical. macOS is the canonical developer workstation OS. Developer Macs routinely hold source code, code-signing certificates, SSH keys to production, CI/CD tokens (GitHub Actions, GitLab), and cloud provider credentials. Mac Mini build farms for iOS/macOS CI/CD are supply-chain infrastructure. Root compromise of a developer Mac or CI runner = supply-chain pivot. This high-value-role outcome (supply-chain scale) on a component where ≥10% of installs serve the high-value role floors the verdict at CRITICAL.
  • Internal lateral movement vector. While internet exposure is the headline, any attacker already inside the network can pivot to every Mac with Screen Sharing enabled. IT support teams commonly enable Screen Sharing on managed Macs. Post-initial-access, this is a one-step, silent, root-level lateral move with zero additional friction.

Why not higher?

The score is already 9.8. The only theoretical uplift to 10.0 would require Scope:Changed (S:C), meaning the exploit escapes into a different authorization zone. This exploit runs within the host's own context — devastating, but not scope-changing in CVSS terms. 9.8 is the correct ceiling for this attack pattern.

Why not lower?

Screen Sharing being off by default is real friction, but it does NOT justify a downgrade. When the feature IS enabled, the attack is deterministic with a 100% success rate — not probabilistic. Active mass exploitation is confirmed by a national CSIRT. The high-value-role analysis (developer workstations, CI/CD runners) means the blast radius at the top of the installed base is supply-chain-scale, which floors the verdict at CRITICAL regardless of the default-off friction. The EPSS of 1.7% reflects model lag against a two-month-old mass-exploitation campaign, not low risk.

06 · Verification

Crowdsourced verification payload.

Run on each target Mac as any user (no root required). Execute: bash cve-2026-65400-check.sh. Outputs VULNERABLE, PATCHED, or UNKNOWN with details on Screen Sharing status, port 5900 listener state, and macOS version.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/bin/bash
# cve-2026-65400-check.sh
# Check for CVE-2026-65400: macOS Screen Sharing pre-auth bypass
# Run on target macOS host. No root required.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

VERSION=$(sw_vers -productVersion 2>/dev/null || echo "unknown")
BUILD=$(sw_vers -buildVersion 2>/dev/null || echo "unknown")

if [[ "$VERSION" == "unknown" ]]; then
  echo "UNKNOWN - Not a macOS system or sw_vers unavailable"
  exit 2
fi

# Check if Screen Sharing is enabled
SS_ENABLED=false
if launchctl list 2>/dev/null | grep -q "com.apple.screensharing"; then
  SS_ENABLED=true
fi

# Check if port 5900 is actually listening
PORT_OPEN=false
if lsof -iTCP:5900 -sTCP:LISTEN -P -n 2>/dev/null | grep -q screensharingd; then
  PORT_OPEN=true
fi

# Version comparison function
version_gte() {
  printf '%s\n%s' "$2" "$1" | sort -V -C
}

# Determine vulnerability status
MAJOR=$(echo "$VERSION" | cut -d. -f1)
PATCHED=false

case "$MAJOR" in
  26) # macOS Tahoe
    if version_gte "$VERSION" "26.6.1"; then
      PATCHED=true
    fi
    ;;
  15) # macOS Sequoia
    if version_gte "$VERSION" "15.7.9"; then
      PATCHED=true
    fi
    ;;
  14) # macOS Sonoma
    if version_gte "$VERSION" "14.8.9"; then
      PATCHED=true
    fi
    ;;
  *)
    echo "UNKNOWN - macOS $VERSION (build $BUILD) is not in the affected version range (Sonoma 14.x / Sequoia 15.x / Tahoe 26.x)"
    echo "Screen Sharing enabled: $SS_ENABLED | Port 5900 listening: $PORT_OPEN"
    exit 2
    ;;
esac

if $PATCHED; then
  echo "PATCHED - macOS $VERSION (build $BUILD) includes the fix for CVE-2026-65400"
  echo "Screen Sharing enabled: $SS_ENABLED | Port 5900 listening: $PORT_OPEN"
  exit 0
else
  if $PORT_OPEN; then
    echo "VULNERABLE - macOS $VERSION (build $BUILD) is UNPATCHED and Screen Sharing is ACTIVELY LISTENING on port 5900"
    echo "IMMEDIATE ACTION REQUIRED: This host is exploitable right now."
  elif $SS_ENABLED; then
    echo "VULNERABLE - macOS $VERSION (build $BUILD) is UNPATCHED. Screen Sharing is enabled but port 5900 not confirmed listening."
  else
    echo "VULNERABLE - macOS $VERSION (build $BUILD) is UNPATCHED. Screen Sharing appears disabled (reduced but not zero risk)."
  fi
  echo "Screen Sharing enabled: $SS_ENABLED | Port 5900 listening: $PORT_OPEN"
  exit 1
fi