Apple has patched a high-severity vulnerability in macOS Screen Sharing that can allow a remote attacker on the network to authenticate to the service without supplying valid credentials.
Tracked as CVE-2026-65400, the vulnerability affects supported versions of macOS Tahoe, macOS Sequoia and macOS Sonoma. Apple describes the underlying problem simply as an authentication issue addressed through improved state management. Independent analysis published after Apple’s earlier July security updates has provided considerably more detail, tying the flaw to the Secure Remote Password (SRP) authentication path implemented by the macOS Screen Sharing service.
This matters because this is not merely a problem with an incorrectly configured VNC password. The vulnerable authentication path can be reached without possessing a valid Screen Sharing credential, and subsequent research demonstrated that the resulting session could interact with privileged Screen Sharing file-operation components. Those components operate with security-sensitive Apple entitlements, making the vulnerability considerably more serious than an ordinary authentication bypass.
Apple released the fixes on August 6, 2026 in macOS Tahoe 26.6.1, macOS Sequoia 15.7.9 and macOS Sonoma 14.8.9. Apple’s advisories explicitly state that an attacker on the network may be able to authenticate to Screen Sharing without valid credentials.
The supplied technical analysis goes further: it documents arbitrary file read and write capabilities through the privileged Screen Sharing file-transfer helpers and several possible routes from that primitive to remote code execution.
What is CVE-2026-65400?
CVE-2026-65400 is a vulnerability in the macOS Screen Sharing service. Apple identifies the affected component as Screen Sharing and describes the impact as follows:
An attacker on the network may be able to authenticate to Screen Sharing without valid credentials.
Apple lists the vulnerability as:
- CVE: CVE-2026-65400
- Component: Screen Sharing
- Severity: High
- CVSS: 7.1
- CWE: CWE-287, Improper Authentication
- Affected operating systems: macOS Tahoe, macOS Sequoia and macOS Sonoma
- Fixed: macOS Tahoe 26.6.1, Sequoia 15.7.9 and Sonoma 14.8.9
- Release date: August 6, 2026
- Credit: Alfredo Pesoli (@__rev) via Bynario Atlas (bynar.io)
Apple’s three security advisories contain essentially the same description for the vulnerability.
The CVSS information supplied with the vulnerability lists the following vector:
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
That corresponds to network attack access, low attack complexity, low privileges in the CVSS scoring model, no user interaction, unchanged scope, high confidentiality impact and low integrity impact.
There is an important nuance here. Apple’s own description says the attacker may authenticate to Screen Sharing without valid credentials, while the CVSS vector published for the CVE contains PR:L. Those are not identical descriptions of attack prerequisites. The safest way to characterize the issue is therefore to distinguish Apple’s advisory from the independent technical analysis: Apple confirms the authentication bypass, while the reverse-engineering work describes how that bypass can be turned into privileged file operations and, under the conditions examined by researchers, remote code execution.
Why Screen Sharing is security-sensitive
Screen Sharing is not simply a graphical display protocol. macOS allows another computer to connect to a Mac, observe the desktop and control the system through its remote-access infrastructure. Apple documents Screen Sharing as a facility that can allow remote users to see the screen and interact with applications, files and the system. Apple’s documentation also identifies compatibility with VNC, the Virtual Network Computing protocol family.
The underlying architecture becomes particularly important when examining CVE-2026-65400.
macOS Screen Sharing uses the Remote Framebuffer (RFB) protocol, the protocol family underlying VNC implementations. The service supports more than one authentication mechanism. The research material identifies a native Apple authentication path based on a username and password and a legacy VNC authentication path based on a VNC password.
The legacy VNC mechanism is especially relevant to the earlier Screen Sharing vulnerability, CVE-2026-43760, which was disclosed at the end of July. That vulnerability involved a confused-context condition in which an already authenticated legacy VNC session could abuse privileged file-operation helpers.
CVE-2026-65400 is different.
It attacks the authentication machinery itself.
That means changing the VNC password, removing a user from the Screen Sharing access list or disabling legacy VNC authentication does not address the underlying CVE-2026-65400 condition. The research specifically found that the authentication bypass could work even when legacy VNC authentication was disabled and when no local Apple accounts were enabled for Screen Sharing access.
CVE-2026-43760 and CVE-2026-65400 are not the same vulnerability
The two vulnerabilities appeared close together and both involve macOS Screen Sharing, which makes them easy to conflate.
They have a fundamental difference in their attack prerequisites.
CVE-2026-43760 was a post-authentication issue. Research into that vulnerability showed that an attacker who had successfully authenticated through the legacy VNC mechanism could abuse privileged Screen Sharing file-operation components. The resulting confused-context condition allowed filesystem objects to be read or created with root privileges. Apple’s July 27 security releases addressed that vulnerability.
CVE-2026-65400, by contrast, is an authentication bypass. The attacker does not need a legitimate Screen Sharing credential to establish the vulnerable session.
That difference changes the practical risk substantially. A vulnerable host exposed to an untrusted network does not merely present an opportunity for someone who has already obtained a VNC password. The authentication boundary itself becomes the attack surface.
The Screen Sharing architecture behind the bug
The security implications become clearer when looking at the privileged processes involved.
The Screen Sharing daemon is accompanied by two file-operation helper components:
SSFileCopySenderSSFileCopyReceiver
According to the technical analysis supplied with the vulnerability research, these helpers handle filesystem operations associated with Screen Sharing. Under the native Apple username-and-password authentication path, their execution context is associated with the authenticated user. Under legacy VNC authentication, the helpers can operate with root privileges.
This is a classic example of why authentication bugs in privileged remote-management services deserve more attention than their initial CVSS description might suggest.
An authentication failure in an ordinary unprivileged service might expose a limited application interface. Here, authentication occurs in a service that can ultimately invoke privileged filesystem operations.
The security boundary therefore looks roughly like this:
Remote network client | v RFB / VNC protocol | v screensharingd | v Authentication state | v SSFileCopySender / SSFileCopyReceiver | v macOS filesystem
If authentication is incorrectly considered successful, operations downstream of that decision can execute in a context that the attacker was never supposed to reach.
That is the central security problem in CVE-2026-65400.
The SRP authentication failure
The most significant technical detail disclosed by the independent analysis is the interaction with Secure Remote Password (SRP).
The native Apple Screen Sharing authentication mechanism uses SRP to authenticate against an actual macOS user account. The research found that screensharingd contained an error in how it handled the framing and validation associated with this authentication protocol.
The important point is not that SRP itself is broken. There is no evidence here that the underlying SRP cryptographic construction was mathematically defeated. Instead, the problem appears to be an implementation and state-management failure inside Apple’s Screen Sharing daemon.
The research describes a frame-length validation path in which the daemon can return a stale success status. Instead of correctly rejecting malformed or unexpected authentication data, the connection can therefore proceed as though authentication had succeeded.
A cryptographic authentication protocol can be perfectly sound while the software implementing it is insecure. If the application incorrectly interprets an error state as a successful authentication result, an attacker does not need to break the cryptography. They only need to reach the flawed state transition.
Conceptually, the vulnerable logic resembles:
Incoming authentication frame | v Validate frame | +---+---+ | | valid invalid | | v v continue reject
The vulnerable implementation could instead allow an invalid or unexpected condition to inherit an earlier successful status:
Previous state: SUCCESS | vFrame validation fails | vStale SUCCESS value remains | vConnection treated as authenticated
That is why the vulnerability is fundamentally an authentication-state problem rather than an attack against SRP’s cryptographic primitives.
Apple’s public advisory describes the fix as “improved state management,” which is consistent with this characterization.
What happens after authentication is bypassed?
The authentication bypass is only the first step. The more serious consequence comes from what an attacker can do once the Screen Sharing service accepts the connection.
Research into the vulnerability demonstrated that the resulting session could interact with the Screen Sharing file-transfer functionality and access filesystem objects with root-level privileges. In particular, SSFileCopySender carries a highly sensitive Apple entitlement:
com.apple.private.tcc.allow
with:
kTCCServiceSystemPolicyAllFiles
The entitlement inspection provided by the research is:
User@MacBook-Pro ~ % codesign -d --entitlements - /System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySenderExecutable=/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender| [Dict] || :------------------------------------------------------------------------------- || [Key] com.apple.private.tcc.allow || [Value] || [Array] || [String] kTCCServiceSystemPolicyAllFiles || [Key] com.apple.security.app-sandbox || [Value] || [Bool] true || [Key] com.apple.security.temporary-exception.files.absolute-path.read-write || [Value] || [Array] || [String] / || [Key] com.apple.security.temporary-exception.files.home-relative-path.read-write || [Value] || [Array] || [String] |
The entitlement gives the helper access to files beyond what a normal sandboxed process would receive. The research specifically notes that kTCCServiceSystemPolicyAllFiles grants Full Disk Access and can bypass normal TCC restrictions for the operations performed by that signed helper.
That makes the vulnerable service particularly dangerous.
A normal remote authentication bypass might expose a user session. Here, the service is connected to a privileged Apple-signed helper with filesystem capabilities that are intentionally unavailable to ordinary applications.
From arbitrary file access to remote code execution
The initial proof of concept published by Pedro Vilaça, also known as fG!, was primarily concerned with demonstrating the authentication bypass and filesystem access. Subsequent reverse engineering recovered more of the Screen Sharing wire format and separated read and write functionality.
The resulting research demonstrated that the primitive could be used to read and modify arbitrary filesystem objects accessible through the privileged file-copy path.
Turning arbitrary file write into code execution then becomes a question of finding a writable location or configuration mechanism that causes macOS to execute attacker-controlled content.
Several persistence and execution mechanisms were investigated.
One involves creating a LaunchDaemon that executes a payload after reboot. Another involves modifying a shell startup file such as:
.zshenv
which can execute when a shell environment is initialized.
There was also an attempted route involving the creation of a cron entry under:
/var/at/tabs/root
That particular route has an important limitation. The research found that the location is protected by TCC and that the SSFileCopyReceiver helper does not possess the same Full Disk Access entitlement as SSFileCopySender. The published analysis was subsequently updated to clarify that the specific crontab-based RCE path required System Integrity Protection (SIP) to be disabled.
That caveat matters. It would be inaccurate to describe every published RCE technique as universally successful against a fully hardened default macOS installation. The broader research demonstrated powerful arbitrary filesystem access and identified multiple possible routes to code execution, but individual execution mechanisms have their own macOS security controls and environmental requirements.
The most defensible description is therefore that CVE-2026-65400 enables a pre-authentication Screen Sharing compromise that can reach privileged filesystem operations, with independently demonstrated paths toward remote code execution.
Why SIP and TCC do not make the authentication bypass harmless
macOS has several security layers that make post-exploitation more difficult, particularly System Integrity Protection (SIP) and Transparency, Consent, and Control (TCC).
Those controls remain important, but they do not repair the authentication failure itself.
TCC is especially relevant because the privileged Screen Sharing helper already has an Apple-signed entitlement for full filesystem access. This is fundamentally different from an ordinary application attempting to read protected files.
The research found that SSFileCopySender possesses:
kTCCServiceSystemPolicyAllFiles
while SSFileCopyReceiver does not have the same entitlement. That difference explains why some filesystem-based exploitation techniques work while others encounter additional protection boundaries.
Disabling VNC authentication does not fix CVE-2026-65400
One of the easiest mistakes administrators could make is to assume that the problem is specifically the legacy VNC password mechanism.
It is not. The vulnerability resides in the native Apple authentication path implemented by Screen Sharing. The technical research demonstrated exploitation with legacy VNC authentication disabled and without local Apple accounts being configured for Screen Sharing access.
That means the following measures are not sufficient fixes for CVE-2026-65400:
Remove Screen Sharing usersDisable legacy VNC password authenticationChange the VNC password
Those controls affect normal authentication configuration, but the vulnerable state-management error occurs before legitimate authentication has been established.
The correct fix is the Apple security update.
If immediate patching is impossible, disabling Screen Sharing removes the vulnerable remote service from exposure. Apple’s documentation provides the normal Screen Sharing control under System Settings > General > Sharing.
Which macOS versions are affected?
Apple’s August 6 security releases address CVE-2026-65400 in the three supported macOS branches covered by the advisories:
macOS Tahoe: update to 26.6.1
macOS Sequoia: update to 15.7.9
macOS Sonoma: update to 14.8.9
Apple released all three updates on August 6, 2026, and each advisory explicitly identifies Screen Sharing as the affected component and CVE-2026-65400 as the associated vulnerability.
The research material also identifies the earlier vulnerable builds associated with the public exploitation work:
macOS Tahoe 26.6 and earliermacOS Sequoia 15.7.8 and earliermacOS Sonoma 14.8.8 and earlier
The material notes that public proof-of-concept work targeted earlier versions such as macOS Tahoe 26.5.2, Sequoia 15.7.7 and Sonoma 14.8.7.
Administrators should not use those older build boundaries as a reason to delay patching. The practical remediation point is much simpler: the affected systems should be moved to Apple’s August 6 security builds.
Why internet-facing Macs are particularly concerning
Screen Sharing is not enabled on every Mac by default, which limits the overall attack surface. But organizations increasingly deploy Macs as remotely managed workstations, developer systems, hosted build machines and bare-metal servers.
That changes the exposure model.
Cloud providers and specialized infrastructure vendors increasingly offer dedicated Apple hardware, including Mac mini systems, for remote workloads. A newly provisioned system may have remote-access functionality enabled for administration. The supplied research specifically identified hosted bare-metal Apple systems as an area of concern and reported finding potentially vulnerable systems exposed through Internet-connected infrastructure.
Apple’s own documentation confirms that Screen Sharing is a network-facing remote-access capability and that VNC clients can be used to connect to Macs.
For a workstation used only inside a trusted LAN, the exposure is different from a Mac with TCP access to Screen Sharing from the public Internet. A vulnerable service should still be patched in either case, but Internet exposure eliminates the network-boundary protection that would otherwise reduce the number of systems capable of reaching the service.
Detection: Endpoint Security provides useful telemetry
One of the most useful aspects of the published research is that macOS provides security telemetry that can help defenders identify suspicious Screen Sharing sessions.
Apple’s Endpoint Security framework exposes Screen Sharing events. The relevant event type is:
ES_EVENT_TYPE_NOTIFY_SCREENSHARING_ATTACH
Apple’s Endpoint Security API defines fields including:
authentication_typeauthentication_usernameexisting_sessiongraphical_session_idsession_usernamesource_addresssource_address_typesuccessviewer_appleid
Apple’s current developer documentation confirms these properties for es_event_screensharing_attach_t.
The supplied research states that Screen Sharing attach and detach events were introduced in macOS 13.0 and can be observed using Apple’s eslogger utility.
A suspicious event observed during exploitation was:
{ "event": { "screensharing_attach": { "graphical_session_id": 258, "viewer_appleid": null, "session_username": "root", "source_address_type": 1, "success": true, "authentication_type": "SRP", "source_address": "<redacted>", "authentication_username": "root", "existing_session": true } }}
The root session username is particularly interesting from a detection perspective because the research notes that the macOS root account is disabled by default and would be unusual as a normal Screen Sharing identity.
A legitimate connection looked different:
{ "event": { "screensharing_attach": { "authentication_type": "RSA-SRP", "session_username": "user", "viewer_appleid": null, "source_address": "<redacted>", "authentication_username": "m1", "source_address_type": 1, "existing_session": true, "graphical_session_id": 257, "success": true } }}
The research highlights the difference between:
authentication_type: SRP
seen in the vulnerable authentication path and:
authentication_type: RSA-SRP
seen in the legitimate connection. The researchers also observed that sessions created through the vulnerable path did not receive the expected cryptographic protection.
This should not be interpreted as a universal detection signature on its own. Authentication telemetry needs to be correlated with source address, user identity, expected administrative activity and subsequent filesystem or process activity. But an unexpected successful Screen Sharing session associated with root, particularly from an unfamiliar source address, deserves investigation.
Filesystem telemetry can reveal exploitation
Endpoint Security can provide another layer of visibility through filesystem events.
The research identifies events such as:
ES_EVENT_TYPE_NOTIFY_LOOKUPES_EVENT_TYPE_NOTIFY_OPENES_EVENT_TYPE_NOTIFY_GETEXTATTRES_EVENT_TYPE_NOTIFY_FSGETPATHES_EVENT_TYPE_NOTIFY_GETATTRLISTES_EVENT_TYPE_NOTIFY_STATES_EVENT_TYPE_NOTIFY_CLOSE
When these events are collected, defenders may be able to correlate operations performed by:
SSFileCopySender
with the filesystem path being accessed or modified.
That correlation is valuable because an attacker exploiting CVE-2026-65400 is not simply creating a network connection. The vulnerable Screen Sharing session ultimately interacts with privileged filesystem functionality. Unexpected access to sensitive filesystem locations by SSFileCopySender is therefore considerably more meaningful than a generic Screen Sharing connection alone.
Process execution telemetry
The Screen Sharing helper also provides a process-level detection opportunity.
The research identifies the following execution path:
/System/Library/CoreServices/RemoteManagement/screensharingd.bundle/Contents/Support/SSFileCopySender.bundle/Contents/MacOS/SSFileCopySender 0 80
Endpoint Security process execution events can be used to identify instances of this helper and correlate them with Screen Sharing authentication events and subsequent filesystem operations.
The arguments are also useful during investigation. Initial information-disclosure exploitation attempts may show:
0 80
representing UID and GID values in the observed exploitation flow.
However, the research explicitly warns that these values should not be treated as permanent indicators. An attacker who enumerates another account can cause different UID/GID values to appear. The analysis also notes that account enumeration can produce Screen Sharing events where:
session_username: null
appears when an attacker guesses an invalid account.
For that reason, robust detection should focus on the combination of:
Screen Sharing attach +unexpected authentication state +unexpected source address +SSFileCopySender execution +privileged filesystem activity
rather than relying on one static process argument.
The July-to-August disclosure timeline
The vulnerability’s disclosure history is unusual because it followed another Screen Sharing vulnerability very closely.
On July 27, 2026, Apple released the macOS 26.6, 15.7.8 and 14.8.8 update wave. Among other fixes, those releases addressed CVE-2026-43760, the Screen Sharing confused-context vulnerability associated with legacy VNC authentication.
On July 29, Bynar.io published research into CVE-2026-43760. On the same day, security researcher Pedro Vilaça (fG!) published research titled “It’s a pre-auth, stupid!”, identifying a separate pre-authentication problem that appeared to have been fixed as a side effect of Apple’s earlier update. His disclosure included an obfuscated proof-of-concept binary named:
navi_the_clown
The proof of concept demonstrated the ability to exploit vulnerable Screen Sharing servers for filesystem disclosure.
Between August 1 and August 2, researcher bl4sty reverse-engineered the PoC, recovered the relevant wire format and traced the authentication bypass to the SRP frame-length validation logic. Further work produced read/write functionality and investigated RCE techniques. A correction subsequently clarified the limitations of the cron-based execution technique on systems with SIP enabled.
Finally, on August 6, Apple released the dedicated fixes:
macOS Tahoe 26.6.1macOS Sequoia 15.7.9macOS Sonoma 14.8.9
and explicitly assigned the pre-authentication Screen Sharing issue CVE-2026-65400.
Why the August 6 update matters even for systems that received the July update
The sequence of patches makes this vulnerability particularly important for administrators who believed their Macs were already protected after the July 27 update.
The July update addressed CVE-2026-43760. Subsequent research revealed that a separate pre-authentication authentication flaw had also been disturbed by that release, but the final fix for the underlying issue arrived in the August 6 builds.
That means the July 27 builds should not be treated as the final remediation point for CVE-2026-65400.
For this specific vulnerability, the relevant fixed builds are:
26.6.115.7.914.8.9
Apple’s August 6 advisories explicitly identify those versions and the Screen Sharing authentication fix.
What administrators should do
The primary remediation is straightforward: install the August 6 security updates.
For supported systems, move to:
macOS Tahoe 26.6.1macOS Sequoia 15.7.9macOS Sonoma 14.8.9
If patching cannot be performed immediately, disable Screen Sharing until the system can be updated. Apple documents the Screen Sharing control under:
System Settings -> General -> Sharing -> Screen Sharing
and provides the option to turn Screen Sharing off.
For infrastructure teams, the remediation should also include an inventory review. Identify Macs running Screen Sharing, determine whether the service is reachable from untrusted networks, and pay particular attention to hosted Apple hardware and remotely administered Mac systems.
Do not rely on changing the VNC password as the remediation for CVE-2026-65400. Do not assume that removing Screen Sharing users fixes it. Do not assume that disabling legacy VNC authentication eliminates the vulnerable native authentication path. The published research specifically demonstrated the bypass under conditions where those legacy controls were not providing the authentication boundary.
Incident response considerations
Organizations that discover an unpatched Mac with Internet-exposed Screen Sharing should treat the system as potentially exposed rather than assuming that exploitation would have required a stolen password.
The most useful investigation starting points are Screen Sharing authentication events, source addresses, the authentication type and username associated with the session, execution of SSFileCopySender, and filesystem operations performed by that helper.
A suspicious event sequence could look like:
Unexpected remote source | vSuccessful Screen Sharing attach | vauthentication_type = SRP | vUnexpected session_username | vSSFileCopySender execution | vPrivileged filesystem access | vPersistence or execution activity
Investigators should also look for modifications to startup and persistence mechanisms, particularly if there is evidence that the attacker progressed beyond filesystem disclosure.
The research identified LaunchDaemon creation and shell startup-file modification as two execution mechanisms worth examining.
If there is evidence of exploitation, merely changing the Screen Sharing configuration is not enough. The system should be investigated for unauthorized file modifications, persistence, credential access and subsequent activity. Where the integrity of the host cannot be established, rebuilding the system may be preferable to assuming that patching alone removed an attacker’s changes.
The broader security lesson
CVE-2026-65400 is a useful example of why remote administration services deserve the same security scrutiny as traditional Internet-facing application servers.
Screen Sharing looks like a convenience feature. Underneath it is a network protocol implementation, an authentication state machine, a privileged system daemon and a collection of helper processes that can interact with the filesystem.
That combination creates a large security boundary.
The vulnerability was not caused by a broken password policy. It was not primarily a VNC password leak. It was not a cryptographic break of SRP. The core problem was that the Screen Sharing implementation could incorrectly transition an authentication session into a successful state.
Once that state was reached, the attacker was interacting with functionality that had privileges far beyond those of an ordinary application.
The technical chain is therefore more accurately represented as:
Network access | vScreen Sharing / RFB | vSRP authentication handling | vIncorrect authentication state | vAuthenticated Screen Sharing session | vPrivileged file-operation helper | vRoot-level filesystem access | +----------------------+ | | v vFile disclosure File modification | v Persistence / execution | v Potential remote RCE
This is also why the vulnerability should not be reduced to the phrase “Screen Sharing authentication bypass.” That accurately describes Apple’s public advisory, but it leaves out the security impact demonstrated by the independent technical research.
At the same time, calling every published exploitation technique a universally reliable remote root exploit would also overstate the evidence. Some RCE paths depend on additional system conditions, and the published cron-based technique, for example, was later shown to require SIP to be disabled.
The most accurate characterization is that CVE-2026-65400 is a high-severity macOS Screen Sharing authentication flaw that can allow network attackers to bypass authentication and reach privileged Screen Sharing functionality. Independent research has demonstrated arbitrary filesystem access and investigated multiple routes to remote code execution, making exposed and unpatched systems a serious security concern.
Final assessment
CVE-2026-65400 deserves immediate attention from anyone operating macOS systems with Screen Sharing or Remote Management enabled, particularly where those services are reachable from untrusted networks.
Apple’s official fix is available now:
macOS Tahoe 26.6.1macOS Sequoia 15.7.9macOS Sonoma 14.8.9
Apple explicitly identifies the issue as an authentication flaw that can allow a network attacker to authenticate to Screen Sharing without valid credentials.
The independent research explains why that seemingly short advisory description has much larger consequences. A vulnerable screensharingd authentication state can lead into privileged file-transfer functionality, and the affected Apple-signed helper includes the kTCCServiceSystemPolicyAllFiles entitlement. The resulting filesystem access can expose sensitive data and provide primitives that researchers have used to investigate persistence and remote code execution.
For defenders, the response is therefore clear: patch the Mac, disable Screen Sharing if patching is temporarily impossible, and investigate exposed systems for suspicious Screen Sharing sessions and privileged filesystem activity.
Changing a VNC password is not a substitute for the security update.
Removing a user from the Screen Sharing access list is not a substitute for the security update.
Disabling legacy VNC authentication is not a substitute for the security update.
The fix is the operating-system update itself.
Apple’s official security advisories for the three affected releases are available here:
macOS Tahoe 26.6.1 security content
macOS Sequoia 15.7.9 security content
macOS Sonoma 14.8.9 security content
Apple’s Screen Sharing documentation also confirms that Screen Sharing is a VNC-compatible remote-access service and provides the controls for disabling it when necessary.
