Skip to main content
boxmining
Menu

Mac Screen Sharing Flaw Is Being Exploited: Patch CVE-2026-65400 Now

Michael GuMichael Gu
12 min read
News
An exposed Mac screen-sharing connection bypassing an authentication gate and driving a hidden Monero mining processor
Contents

Bottom line: Update macOS now if you use Screen Sharing or Remote Management. Apple fixed CVE-2026-65400 in macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9. The Dutch National Cyber Security Centre says attackers have already compromised multiple Macs whose Screen Sharing port was reachable from the public internet, obtained root access and installed Monero miners. A Mac is not automatically internet-exposed just because Screen Sharing is enabled, but leaving TCP port 5900 open to the world turns this bug into an immediate incident risk.

The Coin Bureau alert gets the urgent part right: unpatched, exposed Macs are being hijacked for cryptocurrency mining. The details matter, though, because this is not a universal drive-by attack against every Mac.

The vulnerable service must be enabled and reachable by the attacker. For the incidents confirmed so far, the Dutch NCSC advisory specifically says port 5900 was accessible from the internet. That is common in some data centres, Mac-hosting environments and remote-support setups, but much less common on a normal home Mac behind a router with no port forwarding.

What happened?

Apple released emergency updates on August 6, 2026 for a flaw in macOS Screen Sharing. The company’s Tahoe 26.6.1 security notice says a network attacker may be able to authenticate to Screen Sharing without valid credentials. Apple attributes the bug to incorrect state management and identifies it as CVE-2026-65400.

The same fix appears in Sequoia 15.7.9 and Sonoma 14.8.9. The vulnerability has a CVSS 3.1 base score of 7.1, or High, with low attack complexity and no user interaction required once the attacker can reach the vulnerable service.

On August 12, the NCSC updated its advisory after receiving reports of active exploitation. It said multiple affected systems had exposed port 5900 to the internet. In every reported case, the attacker obtained root access and installed a Monero cryptocurrency miner.

That sequence gives us a clear timeline:

  1. August 6: Apple ships patches for Tahoe, Sequoia and Sonoma.
  2. August 7: The Dutch NCSC publishes its first advisory.
  3. August 12: The NCSC confirms public proof-of-concept code and active exploitation on multiple systems.
  4. August 17: The Coin Bureau warning brings the incident to a wider crypto audience.

The patch arrived before the public confirmation of attacks. That is good news for people who update quickly and bad news for internet-facing systems that still have not been patched.

How does the Screen Sharing attack work?

Screen Sharing is not a passive broadcast feature. When enabled, it lets another computer view the Mac’s desktop, control the pointer and keyboard, open apps, work with files and restart the machine. Apple’s Screen Sharing guide describes that level of control directly.

CVE-2026-65400 breaks the authentication boundary in front of those capabilities. Apple has not published the packet-level exploit, and this guide will not reproduce it. The important defensive fact is that an attacker who can reach the vulnerable Screen Sharing service may be accepted without valid credentials.

The confirmed victims were running the service on TCP port 5900 and making that port reachable from the public internet. Once inside, the attackers reportedly escalated to root—the highest operating-system privilege—and installed mining software.

Root access changes the incident from “someone used my CPU” to “someone controlled the machine.” A root-level intruder may be able to create persistence, inspect local data, tamper with security tools, access browser sessions or watch what the user does. The NCSC report confirms the miner; it does not establish that every victim had files, passwords or crypto assets stolen. It would still be unsafe to assume mining was the only action.

This is not the same as the July Screen Sharing bug

Two recent macOS vulnerabilities involve Screen Sharing, which has caused some reporting to blend them together.

CVE-2026-65400 is the August authentication flaw now under active exploitation. It can let a network attacker authenticate without valid credentials and was fixed in Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9.

The earlier CVE-2026-43760 involved the legacy VNC password path and privileged file-copy helpers. In that case, the attacker needed the separately configured VNC password. Bynario’s technical report on the July flaw showed that an authenticated VNC viewer could abuse file operations running with root authority. Apple fixed that issue in the July releases.

Both bugs reinforce the same operational lesson: remote-control services are high-value attack surfaces. Patch them promptly, expose them only to trusted networks and turn them off when they are not required.

Is your Mac at risk?

Treat your Mac as high priority if all three conditions are true:

  • it is running an older version than Tahoe 26.6.1, Sequoia 15.7.9 or Sonoma 14.8.9;
  • Screen Sharing or Remote Management is enabled; and
  • the service is reachable by an untrusted device, especially through public TCP port 5900.

The last point is easy to misunderstand. Seeing a local process listen on port 5900 does not prove the public internet can reach it. A home router normally blocks unsolicited inbound connections unless someone created a port-forwarding rule, enabled an unsafe automatic mapping or placed the Mac directly on a public network. A cloud firewall, data-centre edge rule or hosting provider can also expose the port.

An attacker on the same local network may still be able to reach the service. That makes shared offices, flat networks and poorly isolated public Wi-Fi more sensitive than a trusted home LAN.

If Screen Sharing and Remote Management are both off, this specific service is not available for the exploit. Updating still matters because macOS releases contain other security fixes.

How to prevent CVE-2026-65400 exploitation

1. Install the patched macOS release

Open Apple menu → System Settings → General → Software Update and install the newest update offered for your Mac. Apple’s macOS update guide recommends using Software Update to obtain the latest compatible security fixes.

After the restart, verify the version under Apple menu → About This Mac. For the three affected release families documented by Apple, the patched minimums are:

macOS releasePatched version
Tahoe26.6.1 or later
Sequoia15.7.9 or later
Sonoma14.8.9 or later

Do not assume an older unsupported macOS release is safe merely because it is absent from Apple’s three August notices. If the Mac cannot receive a current security update, disable the affected sharing services and plan a move to a supported operating system or device.

2. Turn off Screen Sharing and Remote Management if unused

Go to Apple menu → System Settings → General → Sharing.

  • Turn off Screen Sharing if you do not need it.
  • Turn off Remote Management if it is not required by your organization.
  • If you must keep Screen Sharing, open its information panel and restrict access to named users rather than all users.
  • Disable the legacy “VNC viewers may control screen with password” option unless a documented use case requires it.

Changing a VNC password is not a substitute for installing the patch. CVE-2026-65400 is an authentication flaw, so the defense must fix the vulnerable code or remove network access to it.

3. Remove public access to TCP port 5900

Check every layer that can publish the Mac to the internet:

  • router port-forwarding and UPnP mappings;
  • macOS and third-party firewall rules;
  • data-centre or colocation edge firewalls;
  • cloud security groups and network ACLs;
  • remote-support appliances, tunnels and reverse proxies; and
  • hosting-provider defaults for dedicated Mac services.

Do not expose VNC or Screen Sharing directly to 0.0.0.0/0 or the entire IPv6 internet. If remote access is necessary, place it behind a properly maintained VPN or zero-trust access layer, require a separately authenticated device or user, and restrict the destination service to approved source networks. A VPN reduces exposure; it does not remove the need to patch the Mac.

Ask an administrator to test reachability from outside the trusted network. A scan from the same Mac can confirm that something is listening locally, but only an external check of the router, firewall or hosting edge can establish whether port 5900 is publicly reachable.

4. Patch fleets, not just the Mac on your desk

The most exposed machines are often the easiest to forget: headless Mac minis, build runners, render nodes, lab machines, remote desktops and Macs rented in a data centre.

Inventory all macOS endpoints, record their OS version, Screen Sharing state, Remote Management state and network exposure, then enforce the patch through device management. Alert on newly opened inbound port 5900 and on sharing settings that drift from policy.

For a small team, the minimum useful record is a list of Macs with an owner, location, update status and reason for any remote-access exception. “We needed it once” is not a reason to leave a root-capable service exposed forever.

5. Separate crypto activity from everyday remote-access risk

Crypto users often keep exchange sessions, browser wallets, API keys, seed backups or trading tools on one workstation. That concentration turns a Mac compromise into a financial-security incident even when the first visible payload is only a miner.

  • Keep long-term assets in a hardware wallet and verify transaction details on the hardware screen.
  • Never store seed phrases in notes, screenshots, cloud drives or browser autofill.
  • Use withdrawal allowlists, hardware security keys and non-SMS two-factor authentication where supported.
  • Give exchange API keys only the permissions they need; disable withdrawals and rotate unused keys.
  • Use a separate low-value wallet for routine dApp activity.
  • Do not approve a wallet transaction simply because the request appears on your own Mac after suspected compromise.

A hardware wallet cannot make a compromised computer trustworthy, but it can stop malware from silently signing with a key that never leaves the device.

How to check for possible compromise

Cryptojacking often produces sustained CPU usage, heat, fan noise, battery drain or a machine that becomes slow while supposedly idle. Open Activity Monitor → CPU and look for unexplained processes consuming significant resources.

Those symptoms are warnings, not a clean bill of health. A miner can be renamed, stopped temporarily or configured to throttle itself. Normal Activity Monitor output does not prove the Mac was never accessed.

Organizations should review endpoint and firewall telemetry for:

  • unexpected inbound connections to TCP port 5900;
  • Screen Sharing sessions from unknown addresses;
  • new or unexplained privileged processes;
  • persistent high CPU with outbound connections to mining infrastructure;
  • unfamiliar launch items, scheduled jobs or configuration profiles; and
  • security controls that were disabled or logs that unexpectedly stopped.

The NCSC advisory does not publish hashes, filenames, wallet addresses or mining-pool indicators for the observed campaign. Avoid treating an unrelated online IOC list as proof that a system is safe.

What to do if you suspect your Mac was hacked

Disconnect first

Remove the Mac from Wi-Fi and Ethernet, or isolate it through your management platform. Do not keep using it for email, exchanges, password management or wallet approvals.

If it is a company machine, contact the security or IT team before deleting files or running cleanup utilities. They may need memory, logs and disk evidence to determine what happened across the network.

Treat root access as a full-system compromise

Deleting a high-CPU process does not remove persistence or prove that credentials were untouched. Patch the OS, but do not treat patching an already-compromised host as remediation by itself.

For a personal Mac with material financial accounts, the safest recovery path is usually to back up essential documents carefully, erase and reinstall macOS from a trusted recovery path, then restore only known-good data. An organization should follow its incident-response and reimaging process.

Rotate secrets from a clean device

From another trusted device, begin with the accounts that can reset everything else:

  1. secure the primary email account and password manager;
  2. revoke active sessions and rotate important passwords;
  3. reset exchange credentials, API keys and withdrawal settings;
  4. review Apple Account devices and security alerts;
  5. revoke exposed SSH keys, remote-access credentials and work tokens; and
  6. move crypto assets to a new wallet only if there is a credible chance that the old seed or signing key was exposed.

Do not enter an old seed phrase into a website or “recovery service.” Scam responders often target people immediately after a real security incident.

Preserve the timeline and report the incident

Record the Mac model, macOS version, public IP, sharing settings, relevant firewall rules, suspicious process names, network destinations and timestamps. Preserve screenshots and logs. Organizations should notify their incident-response provider, hosting company and relevant national cyber authority. If exchange accounts or wallet funds moved, contact the exchange and law enforcement quickly with transaction hashes and destination addresses.

Why attackers install Monero miners

Cryptominers are a common first payload because they turn stolen computing power into revenue. Monero can be mined on general-purpose CPUs, and the open-source XMRig miner runs across major desktop and server platforms. Attackers do not need to steal the victim’s crypto balance; they steal electricity, hardware life and compute time instead.

The miner is also evidence of access, not a measure of the attacker’s maximum capability. Someone with root control of a Mac can potentially do far more than mine coins. That is why the right response is containment and trusted recovery, not merely force-quitting the process that makes the fans spin.

The practical verdict

CVE-2026-65400 is serious, actively exploited and already patched.

The highest-risk group is clear: operators of Macs with Screen Sharing or Remote Management enabled, running an unpatched release, with TCP port 5900 exposed to the internet. Data centres, hosted Mac services, build farms and unattended Mac minis deserve immediate attention.

For everyone else, the response is still simple: install the update, check General → Sharing, and turn off remote-control services you do not use. Security incidents often begin with a forgotten convenience setting. This one can end with an attacker holding root access to a machine that also holds the keys to your financial life.

macOS Screen Sharing exploit FAQ

What is CVE-2026-65400?

It is a high-severity authentication flaw in macOS Screen Sharing that may let a network attacker authenticate without valid credentials.

Which macOS versions contain the fix?

Apple documents the fix in macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9. Later compatible releases should include it.

Is every Mac vulnerable from the internet?

No. The attacker must be able to reach the Screen Sharing service. The confirmed incidents involved Macs with TCP port 5900 exposed to the public internet.

Does turning off Screen Sharing prevent this attack?

Turning off Screen Sharing and Remote Management removes access to this service, but users should still install the security update.

Is changing the VNC password enough?

No. This vulnerability can bypass valid-credential checks. Install the patch and remove untrusted network access to port 5900.

What did attackers install?

The Dutch NCSC says attackers gained root access and installed Monero cryptocurrency miners on multiple internet-exposed systems.

Does finding a miner mean my crypto wallet was stolen?

Not necessarily, but root access can expose far more than CPU time. Isolate the Mac, recover it through a trusted process and rotate sensitive credentials from a clean device.

Sources and further reading

Security disclosure: This article provides defensive information, not personalized incident-response, legal or financial advice. Do not probe systems or networks you do not own or have explicit permission to test. If a Mac handles sensitive company or financial data and root compromise is suspected, use a qualified incident-response professional.

Share

Found this useful?

Share it with someone who'd want to read it.

Related