macOS Screen Sharing Vulnerability Exploited in Attacks

macOS Screen Sharing Vulnerability Exploited in Attacks

A recently patched macOS Screen Sharing vulnerability exploited in attacks, tracked as CVE-2026-65400, can weaken the authentication protecting Apple's remote-access feature. The flaw may allow an attacker who can reach the Screen Sharing service to authenticate without valid credentials.

Apple addressed the issue in updates released on August 6, 2026. The affected macOS branches received fixes in macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9. Contemporary reporting describes Apple's fix as improved state management around Screen Sharing authentication.

The problem became more urgent after the Dutch National Cyber Security Centre reported attacks involving Macs whose Screen Sharing service was accessible from the internet. According to the NCSC advisory cited in the original reporting, attackers gained access to vulnerable systems and deployed Monero cryptocurrency-mining malware.

For businesses, patching is the first action, not the whole response. A Mac that ran an affected version while Screen Sharing was exposed to an untrusted network may also need review for unauthorized access.

Hoplon Infosec has covered the broader issue in its analysis of macOS security threats and SOC visibility. Modern Mac fleets are business endpoints, and they need the same attention to patching, monitoring, and incident visibility as other enterprise devices.

What is CVE-2026-65400?

CVE-2026-65400 is an authentication vulnerability affecting macOS Screen Sharing. It may allow a network attacker to authenticate to the service without valid credentials.

Screen Sharing lets another computer remotely view and control a Mac. When enabled, a permitted remote user can see the desktop, open apps, work with files and windows, and interact with the system. Apple also allows administrators to restrict Screen Sharing to selected users.

CVE-2026-65400 affects the authentication boundary around that remote connection. It is therefore different from a simple weak-password problem. The issue concerns whether the service correctly validates a connection before allowing access.

Reporting on the vulnerability says Apple addressed the authentication problem through improved state management. CVE-2026-65400 has been associated with the Screen Sharing security updates released in August.

Security researcher Alfredo Pesoli of Bynario Atlas was credited with finding the flaw in Apple's security information.

Which macOS Versions Fix CVE-2026-65400?

The August 6 fixes were released for Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9.

macOS branch	Fixed version
macOS Tahoe	26.6.1
macOS Sequoia	15.7.9
macOS Sonoma	14.8.9

The important detail is the final revision number. Installing Tahoe 26.6, for example, should not be confused with installing the later 26.6.1 update associated with this particular Screen Sharing issue. The July 26.6 release contained other Screen Sharing fixes, discussed later in this article.

To check for available updates, open:

Apple menu → System Settings → General → Software Update

Apple recommends using the latest macOS version compatible with the Mac and confirms that Software Update is the normal way to find, download, and install compatible macOS updates.

For a business fleet, checking versions centrally is preferable where management tooling is available. A larger environment should not depend solely on individual users confirming that they clicked Update.

Is the macOS Screen Sharing Vulnerability Being Exploited?

According to the Dutch NCSC, active abuse has been observed on systems where Screen Sharing was accessible from the internet.

The advisory referenced in the original reporting described attacks against multiple systems with port 5900 exposed. It also linked the compromises to installation of a Monero cryptocurrency miner.

That is relevant because 5900 is not an arbitrary port. Apple documents TCP port 5900 as the default Screen Sharing connection port and lists TCP and UDP 5900 for Apple Remote Desktop and Screen Sharing services.

Apple's vulnerability information and the NCSC attack observations answer different questions. Apple's information describes the flaw and fix. The NCSC reporting describes activity observed against exposed systems.

Why Does Internet-Exposed Screen Sharing Matter?

Exposure determines whether a remote attacker has a network path to the vulnerable service.

A Mac with Screen Sharing limited to a trusted internal network presents a different situation from a Mac with port 5900 forwarded directly from the internet.

Apple's own Remote Desktop documentation shows that NAT configurations can forward TCP and UDP port 5900 to systems behind a router. That is useful when remote administration is intentional, but it also demonstrates why unwanted port forwarding needs to be identified.

When reviewing affected Macs, check:

• whether Screen Sharing is enabled
• which users are allowed to connect
• whether Remote Management is enabled
• whether TCP or UDP port 5900 is exposed externally
• whether a router forwards port 5900 to the Mac
• whether VPN or trusted management access limits reachability
• whether the host firewall allows the connection
• how long the system remained unpatched
• whether unexpected remote activity occurred during that period

For organizations with many internet-facing systems, Attack Surface Management is directly relevant here. Hoplon's service focuses on discovering and monitoring internet-facing assets and exposures—the same kind of visibility needed to find services that were accidentally left reachable from outside the organization.

An open service still does not prove successful exploitation. Exposure tells you that an attack path existed. Evidence from the endpoint and network is needed to determine whether someone actually used it.

What Could an Attacker Reach on a Business Mac?

A business Mac can hold or provide access to far more than local files.

Depending on the user and device, the endpoint may have access to:

• corporate email
• internal documents
• cloud applications
• active browser sessions
• development environments
• source code
• administrator utilities
• company VPN connections
• stored credentials
• authentication material
• internal network resources

That does not mean CVE-2026-65400 automatically exposes all of these resources. The actual impact depends on what occurred after access and what permissions the user or endpoint had.

A cryptocurrency miner may produce an obvious clue, such as high CPU use. Other remote activity can be much less visible.

That is where endpoint security becomes important. Endpoint protection is not limited to antivirus scanning; it can also involve monitoring, detection, investigation, containment, and recovery when suspicious behavior occurs on laptops and other business devices.

CVE-2026-65400 is Not the Only Recent Screen Sharing Flaw

Several macOS Screen Sharing security issues appeared close together in 2026, and they should not be treated as one vulnerability.

Apple's macOS Tahoe 26.6 security update, released on July 27, included several separate Screen Sharing Server vulnerabilities:

• CVE-2026-43779
• CVE-2026-43777
• CVE-2026-43760

Apple says CVE-2026-43779 involved the possibility of an application intercepting network connections intended for another process. CVE-2026-43777 could allow a remote attacker to cause a denial of service, while CVE-2026-43760 involved access to user-sensitive data.

Independent researchers also investigated another pre-authentication weakness involving the screensharingd daemon.

Public technical research into that earlier issue described an authentication bypass and explored root-level file access and possible execution paths. Those findings help explain the wider security attention around Screen Sharing, but they should not be used as technical proof of CVE-2026-65400.

The vulnerabilities are separate.

Mixing their technical details could create inaccurate statements about:

• affected macOS versions
• authentication requirements
• root access
• remote code execution
• System Integrity Protection
• exploitation prerequisites

CVE-2026-65400 received its own later security fix.

How Can You Check Whether a Mac is Exposed?

Start with three things: version, service status, and network exposure.

Check the macOS Version

Open:

Apple menu → About This Mac

Then compare the installed version with the patched version for that macOS branch.

Software updates can be checked through:

System Settings → General → Software Update

Apple recommends keeping macOS current because updates include security, stability, and compatibility improvements.

Check Whether Screen Sharing Is Enabled

Go to:

Apple menu → System Settings → General → Sharing

Look for Screen Sharing.

Apple confirms that when Screen Sharing is turned off, other computers on the network cannot connect to the Mac through that feature.

While you are there, check Remote Management as well. Apple notes that Screen Sharing and Remote Management cannot both be enabled at the same time through the normal Sharing configuration.

Check Whether Port 5900 Is Listening

Administrators can use Terminal to see whether a process is listening for TCP connections on port 5900:

sudo lsof -nP -iTCP:5900 -sTCP:LISTEN

If nothing is returned, there may be no TCP listener on that port at that moment.

If a listener does appear, confirm why it is there before assuming it is malicious. Screen Sharing and legitimate remote-management software can use port 5900.

Apple documents port 5900 as a standard port for Screen Sharing and Apple Remote Desktop.

How to Disable Screen Sharing on macOS

If Screen Sharing is not required, turning it off removes the macOS Screen Sharing service from normal use and reduces unnecessary remote-access exposure.

Method 1: Disable Screen Sharing in System Settings

1. Open Apple menu.
2. Select System Settings.
3. Open General.
4. Select Sharing.
5. Find Screen Sharing.
6. Turn it Off.

Apple's current Mac User Guide documents the same path and states that computers on the network can no longer connect through Screen Sharing when it is disabled.

For most individual Macs, this is the simplest method.

Method 2: Disable Screen Sharing From Terminal

For managed or security-hardened macOS systems, the Screen Sharing service can also be disabled with launchctl:

sudo /bin/launchctl bootout system/com.apple.screensharing

sudo /bin/launchctl disable system/com.apple.screensharing

The macOS 26 Tahoe Security Technical Implementation Guide uses these commands to stop and disable the com.apple.screensharing service at the system level.

The same approach is also reflected in CIS-based macOS hardening guidance.

You can check the disabled-service state with:

/bin/launchctl print-disabled system | grep com.apple.screensharing

For a production fleet, test administrative commands on representative systems first and deploy them through the organization's normal device-management process.

How to Disable Apple Remote Management

Screen Sharing is not the only macOS feature capable of remote desktop administration.

If Remote Management / Apple Remote Desktop is enabled and the organization does not need it, Apple documents this command for disabling Remote Management:

sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -deactivate

Administrator privileges are required. Apple says the command disables Remote Management and denies previously available logins.

You can also review Remote Management through the Mac's Sharing settings.

Do not disable a legitimate management service blindly on business endpoints. Confirm that the organization's IT, support, or MDM workflows do not depend on it first.

How Should Port 5900 Be Blocked?

If Screen Sharing does not need to accept connections from the internet, do not publish or forward port 5900 to the Mac.

Apple lists port 5900 for Screen Sharing and Apple Remote Desktop traffic.

At the network boundary, a simple policy should look like this:

Internet → Mac TCP 5900: DENY

Internet → Mac UDP 5900: DENY

Also check the router or firewall for any NAT or port-forwarding rule that maps external port 5900 to the Mac.

For example, remove rules similar to:

Public IP:5900 → Mac private IP:5900

Apple's Remote Desktop documentation specifically describes TCP and UDP 5900 forwarding when Remote Desktop must work through a NAT router. If you do not need that access, such forwarding should not remain enabled.

If remote administration is necessary, avoid exposing the service broadly. Limit access through trusted network paths, controlled VPN access, or other approved management architecture.

For larger environments, this is another place where Attack Surface Management can help reveal forgotten public services before they become an easy target.

What Should You Do If Screen Sharing Must Stay Enabled?

Disabling the service is not always practical. Help desks, administrators, and remote-support teams may depend on it.

If Screen Sharing must remain available:

• install the current security update
• allow only users who genuinely require Screen Sharing
• avoid direct internet exposure
• limit network reachability
• remove unnecessary NAT forwarding
• review firewall rules
• monitor remote-access activity
• keep System Integrity Protection enabled
• periodically review whether the service is still required

Apple allows administrators to configure Screen Sharing for All users or Only these users. Choosing a limited user list is preferable when only a small number of administrators require access.

A vulnerable remote service is not just a patch-management concern. It belongs in the wider vulnerability management process, where teams identify affected assets, understand exposure, prioritize remediation, fix the weakness, and verify the result.

Does Installing the Patch Prove a Mac Was Never Compromised?

No. Patching closes the known vulnerable condition, but it cannot establish what happened before the update was installed.

Imagine a Mac that ran an affected version while Screen Sharing was reachable from the public internet.

The patch still needs to be installed immediately. Once that is done, however, administrators may have another question: was the endpoint accessed during the vulnerable period?

Depending on available logging and security tooling, useful areas to review include:

• unexpected Screen Sharing sessions
• unusual processes
• cryptocurrency-mining activity
• unfamiliar persistence mechanisms
• newly created or modified files
• unexpected outbound connections
• abnormal CPU usage
• unexplained administrative actions
• changes that do not match normal user behavior

One indicator should not be treated as proof of CVE-2026-65400 exploitation. High CPU use, for example, can have many causes.

The investigation should establish a timeline and determine whether the activity matches legitimate administration or an unauthorized connection.

Organizations that do not have a clear inventory of endpoints, network exposure, identities, cloud resources, and security controls may benefit from a broader Cyber Security Assessment. Hoplon's assessment covers endpoints, networks, identity, cloud, policy, and people, making it more appropriate when the concern extends beyond one Mac or one vulnerability.

Should You Disable Screen Sharing?

Disable it when there is no legitimate business requirement. Keep it only when remote screen access serves a defined purpose and can be properly controlled.

Unnecessary services create unnecessary attack surface.

For a Mac that does not need Screen Sharing, the practical sequence is simple:

1. Update macOS.
2. Turn Screen Sharing off.
3. Check Remote Management.
4. Remove external port 5900 forwarding.
5. Confirm port 5900 is no longer unexpectedly listening or exposed.
6. Review the endpoint if it had previously been internet-accessible.

This is one place where repeating the same security advice is unnecessary: once the service is removed or tightly restricted and the Mac is patched, the remaining question is whether earlier exposure requires investigation.

When Does This Become an Incident-Response Problem?

It becomes an incident-response issue when there is credible evidence that unauthorized activity occurred, not merely because a vulnerable version was installed.

Signs that deserve deeper investigation can include:

• unexplained remote sessions
• a Monero or other cryptocurrency miner
• unexpected administrator activity
• suspicious persistence
• unknown outbound connections
• unauthorized file changes
• evidence of credential access
• indications that another system was reached from the Mac

Once those signs exist, simply deleting a suspicious process or applying a patch may leave important questions unanswered.

The investigation may need to determine:

• when access began
• which accounts were involved
• what processes ran
• what files changed
• what credentials were available
• whether other systems were reached
• whether persistence remains
• whether credentials need to be reset
• whether the Mac should be rebuilt
• when the endpoint can safely return to normal use

For an organization facing evidence of compromise, Hoplon Infosec's Incident Readiness, Response & Recovery service is a more natural next step than treating the situation as routine patch management. Hoplon lists containment, forensic investigation, threat eradication, recovery, and post-incident hardening among its response capabilities.

Where there is no confirmed incident but the organization needs to understand wider exposure and business impact, a Cybersecurity Risk Assessment can help evaluate the weakness within the broader environment.

What Should IT Teams Do About CVE-2026-65400?

Patch affected Macs first, then focus investigation on systems that had Screen Sharing enabled and were reachable from untrusted networks.

A practical priority order is:

1. Identify affected Macs.
2. Install the appropriate security update.
3. Find Macs with Screen Sharing or Remote Management enabled.
4. Check whether port 5900 was publicly reachable.
5. Disable unnecessary remote-access services.
6. Remove unwanted NAT or firewall exposure.
7. Review higher-risk endpoints for suspicious activity.
8. Escalate systems with evidence of compromise to incident response.
9. Verify that remediation actually reached the entire fleet.

Not every Mac carries the same risk.

A patched device whose Screen Sharing service was never reachable from an untrusted network is a different case from an unpatched endpoint that accepted internet connections on port 5900.

That context should influence remediation priority.

Can macOS Security Updates Be Automated?

Yes. macOS supports automatic update controls, which can reduce the amount of time endpoints remain unpatched after security fixes are released.

Apple's Software Update settings allow compatible macOS updates to be found and installed, and Apple recommends keeping Macs on the latest compatible version for security, stability, and compatibility.

Automation still needs verification.

A dashboard showing that automatic updates are enabled does not necessarily prove that every endpoint has completed installation. Remote laptops can remain offline, updates can fail, and devices can fall outside normal management.

For a business fleet, patch deployment and patch verification should be treated as separate tasks.

The Practical Takeaway

CVE-2026-65400 affects a feature designed to let another computer remotely interact with a Mac. That makes the combination of an unpatched system and unnecessary network exposure particularly important.

Start by checking the macOS version.

Then look at Screen Sharing and Remote Management. If they are not needed, disable them. If they are needed, make sure they are limited to authorized users and trusted network paths rather than exposed broadly to the internet.

Port 5900 deserves the same review. Remove unwanted forwarding rules and block public access where there is no legitimate requirement.

For systems that were exposed before patching, configuration changes alone do not answer whether somebody connected earlier. If suspicious processes, remote sessions, miners, persistence, or unexplained network activity appear, treat that Mac as an investigation rather than just another patch ticket.

The patch closes the vulnerability. Knowing your exposure tells you which systems need a closer look.

 

Frequently Asked Questions

What is the macOS Screen Sharing vulnerability?

The macOS Screen Sharing vulnerability tracked as CVE-2026-65400 is an authentication issue that may allow a network attacker to authenticate to Screen Sharing without valid credentials.

Is CVE-2026-65400 being actively exploited?

According to the Dutch NCSC reporting cited for this incident, exploitation has been observed against systems exposing Screen Sharing to the internet.

Which macOS versions fix CVE-2026-65400?

The reported fixes are macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9.

What port does macOS Screen Sharing use?

Apple documents TCP port 5900 as the default Screen Sharing port. Apple's broader port reference also lists TCP and UDP 5900 for Screen Sharing and Apple Remote Desktop.

How do I disable Screen Sharing on a Mac?

Go to System Settings → General → Sharing and turn Screen Sharing off. Apple says other computers on the network can no longer connect through Screen Sharing after it is disabled.

How can I disable Screen Sharing from Terminal?

For supported hardened configurations, the service can be stopped and disabled with:

sudo /bin/launchctl bootout system/com.apple.screensharing

sudo /bin/launchctl disable system/com.apple.screensharing

The macOS Tahoe STIG documents these commands for disabling Screen Sharing system-wide.

How can I check port 5900 on macOS?

Run:

sudo lsof -nP -iTCP:5900 -sTCP:LISTEN

A returned listener means a process is accepting TCP connections on port 5900. Investigate the process and configuration before deciding whether it is expected.

Should port 5900 be exposed to the internet?

If there is no documented need for public Screen Sharing or Remote Desktop access, it should not be exposed through internet-facing NAT or firewall rules. Apple confirms that Remote Desktop configurations can use port forwarding for TCP and UDP 5900, which is why those rules should be reviewed carefully.

Does an open port 5900 prove a Mac was hacked?

No. An open or exposed port indicates reachability. It does not prove that an attacker successfully authenticated or compromised the system.

Is disabling Screen Sharing enough to fix CVE-2026-65400?

No. Disabling Screen Sharing reduces the attack surface, but affected Macs should still receive the appropriate macOS security update.

Does installing the security update remove existing malware?

A security update fixes the vulnerability it addresses. It should not be treated as proof that previously installed malware, persistence, or unauthorized changes are absent.

Is CVE-2026-65400 the same as the Screen Sharing flaws fixed in July?

No. Apple's July 27 macOS Tahoe 26.6 update included separate Screen Sharing Server vulnerabilities such as CVE-2026-43779, CVE-2026-43777, and CVE-2026-43760.

Does CVE-2026-65400 provide remote code execution as root?

Apple's reported description of CVE-2026-65400 concerns an authentication bypass. Separate Screen Sharing research has discussed root-level access and potential execution paths for other vulnerabilities, so those technical details should not automatically be attributed to CVE-2026-65400.

Why are Monero miners involved?

According to the NCSC reporting associated with the incident, attackers installed Monero cryptocurrency-mining malware on compromised systems. Cryptominers use the victim machine's computing resources to perform cryptocurrency-mining work.

Related Articles 

• macOS Security Threats 2026: The Hidden SOC Gap
• macOS and iOS Vulnerabilities Exploited in Attacks
• macOS TCC Bypass Vulnerability Explained
• MacSync Stealer macOS: New Malware to Bypass Gatekeeper