CVE-2026-65400 (CVSS 9.8): macOS Screen Sharing Zero-Auth Bypass Hands Attackers Root Access — CISA Rescores After Active Monero Mining Rampage

On 14 August 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) did something it rarely does: it raised the severity score of an existing vulnerability eight days after the vendor patched it. The vulnerability — CVE-2026-65400, an authentication bypass in Apple macOS’s built-in Screen Sharing service — was re-scored from 7.1 to a critical 9.8, placing it in the same tier as the most dangerous flaws ever catalogued. The reason? Real-world attackers had already been inside corporate and university Macs, achieving root access and deploying Monero cryptocurrency miners on every machine they touched.

If your organisation has even a handful of Macs — and in India’s IT services, BFSI, and media sectors, many do — and if those Macs have ever had Screen Sharing enabled, this is an emergency-level patch event. Here is everything you need to know.

Background: macOS Screen Sharing and Why It Is Exposed

macOS Screen Sharing — Apple’s built-in remote desktop feature — operates over the Virtual Network Computing (VNC) protocol on TCP port 5900. It is enabled with a single checkbox under System Settings → General → Sharing and is used legitimately by IT administrators, helpdesk teams, and remote workers across the globe. What makes it dangerous is how quietly it can be turned on and forgotten: a macOS update can restore a previously enabled Sharing preference, and home-office setups frequently lack the network perimeter controls that block direct internet access to port 5900.

According to internet scan data cited in technical advisories, approximately 40,000 Screen Sharing hosts were accessible directly from the public internet at the time exploitation was confirmed — nearly 50% of them in the United States, with significant concentrations in universities and technology companies. India has a substantial installed base of Apple hardware in software development, financial services, and creative industries; organisations in those sectors should treat this as an active, not theoretical, threat.

Technical Breakdown: How CVE-2026-65400 Works

Apple’s own advisory describes the fix as: “An authentication issue was addressed with improved state management.” Independent researchers have since reverse-engineered the flaw, and the root cause maps squarely to CWE-287: Improper Authentication.

Screen Sharing uses the Secure Remote Password (SRP) protocol to authenticate connecting clients without transmitting passwords in the clear. SRP is a sound cryptographic design — when implemented correctly. In the vulnerable macOS versions, a faulty frame-length validation path in the SRP implementation returns a stale “success” state to the authentication state machine. The state machine reads that value and concludes the session has been authenticated, even though no actual credential exchange has taken place. Any client that sends a specific malformed SRP handshake obtains a fully authenticated Screen Sharing session.

The vulnerability’s NIST/NVD CVSS:3.1 vector tells the full story:

CVSS Metric	Value	Meaning
Attack Vector	Network	Exploitable from anywhere on the internet
Attack Complexity	Low	No special conditions required
Privileges Required	None	Fully pre-authentication
User Interaction	None	No user click or approval needed
Scope	Unchanged	Impact contained within the OS
C / I / A Impact	High / High / High	Full compromise of all three pillars
Base Score	9.8 CRITICAL	Rescored by CISA from Apple’s original 7.1

Once inside an unauthenticated Screen Sharing session, the attacker effectively controls the Mac graphically — they can open Terminal, escalate to root via legitimate system mechanisms, install software, exfiltrate data from Keychain, and pivot to internal resources accessible from that machine.

The CISA Rescore: Why 7.1 Became 9.8

Apple’s initial CVSS scoring of 7.1 reflected a network-adjacent attack vector assumption — the thinking being that VNC services are not normally internet-facing. That assumption collapsed when exploitation began targeting internet-exposed port 5900 directly.

On August 14, 2026 — eight days after Apple released the out-of-band patch and two days after the Dutch NCSC-NL confirmed active exploitation — CISA replaced the CVSS vector string to reflect operational reality: attack vector Network, no privileges required, no user interaction, full C/I/A impact. The resulting CVSS 9.8 places CVE-2026-65400 in the same gravity category as unauthenticated remote-code execution bugs like the Windows DNS Server wormable flaw (CVE-2026-62878) covered on this blog. CISA simultaneously added the flaw to its Known Exploited Vulnerabilities catalog, triggering mandatory patch deadlines for U.S. federal agencies under Binding Operational Directive 22-01.

The rescore should serve as a lesson for security teams everywhere: vendor-assigned CVSS scores reflect design-time assumptions, not field reality. Organisations that triaged CVE-2026-65400 as a 7.1 “important” during the August 6 patch wave may now find themselves behind exploits that assumed a 9.8 severity all along.

Active Exploitation: Root Access and the Monero Miner

The Dutch National Cyber Security Centre (NCSC-NL) published an advisory on August 12, 2026, confirming that attackers were actively targeting Macs with port 5900 exposed to the internet. The NCSC-NL reported that in every confirmed case, the attacker executed two specific post-exploitation steps:

1. Root privilege escalation — the forged Screen Sharing session provided administrative desktop access, which was used to open a privileged shell and escalate to the system’s root account.
2. Monero (XMR) cryptocurrency miner deployment — a silent background XMRig-based miner was installed and configured to mine Monero using the victim machine’s CPU resources, beaming profits to attacker-controlled wallets.

Monero is the cryptocurrency of choice for cryptojackers because its ring-signature and stealth-address architecture makes proceeds effectively untraceable — a stark contrast to Bitcoin or Ethereum transactions. But the financial damage is only part of the picture: root access means the attacker can install persistent backdoors, exfiltrate credentials from the macOS Keychain, pivot to internal services (databases, code repositories, CI/CD pipelines) accessible from that Mac, or sell the foothold to a secondary threat actor for ransomware deployment.

Security researcher Alfredo Pesoli of Bynario is credited with discovering the underlying flaw. The BleepingComputer write-up notes that exploitation was observed across multiple systems before CISA’s KEV designation — the classic sign of an active opportunistic campaign.

Who Is at Risk in India?

Enterprise India may be tempted to dismiss this as an Apple consumer problem. That would be a mistake. Consider the environments where macOS is prevalent:

• IT/ITES and software development firms — developer MacBook Pros are common across Bengaluru, Hyderabad, Pune, and Gurugram. Many engineers enable Screen Sharing for personal convenience and never disable it.
• BFSI sector — fintech companies and broking firms increasingly deploy Mac workstations for compliance, analytics, and trading operations.
• Media, advertising, and creative agencies — Mac-first environments where machines may not be managed by an MDM platform that enforces OS updates.
• Universities and research institutions — one of the confirmed global exposure clusters, particularly relevant for IITs and IIMs with international collaboration programmes.

If your organisation lacks a mobile device management (MDM) solution enforcing macOS updates — or if personal Macs are used for work under a BYOD policy — treat every unpatched Mac as potentially compromised until verified otherwise.

What You Should Do Right Now

As a zero-trust security practitioner, my advice breaks into three tracks:

Immediate (within 24 hours)

• Patch every Mac in your environment. Update to macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, or macOS Sonoma 14.8.9. If MDM is deployed (Jamf, Mosyle, Kandji), push a forced update policy immediately. Refer to Apple’s security updates page to confirm installed versions.
• Disable Screen Sharing on all machines that do not require it. Navigate to System Settings → General → Sharing → Screen Sharing and toggle it off. For fleet management, enforce this via a configuration profile.
• Block TCP port 5900 at the perimeter. No Mac should ever expose VNC directly to the internet. Verify your firewall policies ensure port 5900 is dropped inbound on all external-facing interfaces.

Short-Term (within 1 week)

• Hunt for IOCs on existing machines. Check for the Monero miner: look for processes named xmrig, unusual sustained CPU spikes, and outbound connections to mining pool domains (pool.supportxmr.com, minexmr.com). Inspect /Library/LaunchDaemons/ and /Library/LaunchAgents/ for unfamiliar persistent entries.
• Review firewall and SIEM logs for port 5900 activity. Any inbound attempt to TCP 5900 from an external IP is a scanning or exploitation indicator. Correlate with endpoint logs to identify potentially compromised devices.
• Rotate credentials on any Mac that was internet-accessible while unpatched. Assume credential exfiltration from Keychain. Rotate all secrets — SSH keys, API tokens, VPN credentials — stored on potentially compromised machines.

Structural (zero-trust posture)

• Never expose remote-access services directly to the internet. All remote desktop and VNC access must be gated behind a VPN or zero-trust access proxy. This is a foundational principle — not optional.
• Enforce MDM-based patch compliance. An unmanaged Mac running a months-old OS is an uncontrolled attack surface. MDM enrollment should be a condition of network access under a zero-trust model.
• Monitor for lateral movement from Mac endpoints. Root access on a developer Mac often means access to cloud credentials, source code, and internal APIs. Integrate macOS endpoint logs into your SIEM and alert on unexpected privileged process spawns.

Frequently Asked Questions

Does this affect iPhones, iPads, or Apple TVs?

No. CVE-2026-65400 is specific to the macOS Screen Sharing service, which runs only on Mac computers. iOS, iPadOS, tvOS, and watchOS do not run the Screen Sharing daemon and are unaffected. However, a compromised Mac linked to iCloud may expose shared credentials, so iCloud account passwords should be rotated on any machine suspected of compromise.

My Mac was patched on August 6 — am I safe from this flaw?

If you applied macOS Tahoe 26.6.1, Sequoia 15.7.9, or Sonoma 14.8.9 before any attacker reached your port 5900, you are protected against CVE-2026-65400. However, even patched machines should be checked for signs of prior compromise: inspect /Library/LaunchDaemons/ for unfamiliar entries, review process history for xmrig or sustained CPU spikes, and audit outbound network connections in the period between August 6 and your actual patch date.

We use Apple Remote Desktop rather than plain VNC — are we still affected?

Yes. Apple Remote Desktop (ARD) uses the same underlying Screen Sharing infrastructure and the same VNC port 5900. If ARD is enabled and port 5900 is accessible, the vulnerability applies. The CVE-2026-65400 patch covers both the Screen Sharing toggle and the ARD management service.

Our FortiGate default policy blocks inbound traffic — do we need to do anything additional?

FortiGate’s implicit deny-all rule blocks unauthorised inbound traffic on the WAN interface, but verify that no policy exception permits TCP 5900 inbound from any external zone — such rules can be introduced inadvertently during remote-work provisioning. Additionally, enable Application Control to detect VNC protocol traffic regardless of port number, since attackers sometimes re-serve VNC on alternate ports to evade simple port-block policies.

Sources: BleepingComputer · The Hacker News · NIST NVD CVE-2026-65400 · CISA KEV Catalog · SC Media