Apple’s Screen Sharing fix: CVE-2026-65400 and unauthenticated access

Screen Sharing is meant to give a trusted person control of a Mac. CVE-2026-65400 breaks an earlier part of that arrangement: Apple says a network attacker could gain access without valid credentials. The fix belongs on the review list for shared and occasional-use Macs as well as everyday work machines.

The published fixes

Apple identifies CVE-2026-65400 as a Screen Sharing authentication issue that could let a network attacker gain access without valid credentials. Apple released the Tahoe fix in macOS 26.6.1 on August 6 and credits Alfredo Pesoli via Bynario Atlas with the report.

Apple’s macOS Tahoe 26.6.1 security advisory

Apple published fixes for the same CVE in macOS Sequoia 15.7.9 and macOS Sonoma 14.8.9 on August 6. Check the installed macOS branch before comparing version numbers; the three branches have different numbering.

Apple’s macOS Sequoia 15.7.9 security advisory

Apple’s macOS Sonoma 14.8.9 security advisory

CISA added CVE-2026-65400 to its Known Exploited Vulnerabilities catalog on August 18. That supports prioritizing affected systems rather than treating the issue as a purely hypothetical risk. A catalog entry does not establish whether any particular Mac in your business was attacked.

CISA’s current Known Exploited Vulnerabilities catalog

Where the authentication check failed

Apple describes the correction as improved state management. That tells us the flaw involved how authentication progressed, and that the result could be Screen Sharing access without valid credentials. It does not reveal the exact implementation error.

Apple’s description of the authentication-state correction

An authentication exchange normally establishes a connection, evaluates credentials, accepts an identity and creates an authorized session. Each step needs the right checks to have completed for that connection. A partial or failed exchange must never be mistaken for a successful login.

Apple does not say which transition failed, whether concurrent activity was involved or which messages triggered the bug. There is no basis in this advisory to call it a particular race condition or cryptographic failure.

Check how someone can reach Screen Sharing

A remote session involves three separate checks: reaching the service, authenticating, and receiving permission to view or control the Mac. Network restrictions can limit who reaches the first step. They cannot correct a faulty authentication check in the service itself.

Apple’s Screen Sharing documentation describes controls over allowed users and the ability for another computer to view and control the shared Mac. Review those settings together with the authorized remote-support path. A working user allowlist is an important policy control, but this CVE concerns the preceding requirement to authenticate correctly.

Apple’s Screen Sharing configuration guide

The advisories name Screen Sharing on specific macOS branches. They do not extend this finding to SSH, Apple account sign-ins or every Apple remote-management product.

Include occasional-use Macs in the inventory

Record the model, macOS branch and build, whether Screen Sharing is enabled, allowed users and the approved network path used for support. Give intermittent-use machines an owner too. A laptop kept for remote support can otherwise miss routine desktop checks for months.

If the service is no longer needed, have its owner disable it after checking for support dependencies. Where it is needed, limit reachability to the approved management path and keep access specific to the intended users. These measures reduce exposure; the applicable macOS update corrects the disclosed authentication bug.

Current settings cannot explain past access

CISA’s entry confirms known exploitation, but does not tell you which Macs were involved. If you suspect an incident, preserve remote-access and endpoint records, the relevant time period and the configuration in use then. Enabled Screen Sharing shows potential exposure, not proof of misuse. Disabling it today tells you nothing about whether it was enabled last week.

Update the right branch, then check it

Use Apple’s Software Update interface to obtain an appropriate supported update for the Mac. Apple recommends the latest compatible macOS and explains that Software Update offers software compatible with the model. The versions listed above identify the original fixes for this issue; they are not a recommendation to downgrade or to ignore newer releases.

Apple’s instructions for updating macOS

After maintenance, record the installed version on each Mac. Keep offline and deferred devices on the exception list. A spare machine that has not checked in is still unfinished work, even if every online laptop reports success.

Give remote access a business reason

Apple’s Screen Sharing guide explains that another computer can view and control the shared Mac. Its settings are under System Settings, General, Sharing. Apple also provides controls for limiting allowed users. Review those settings with the person responsible for support; avoid cutting off the only maintenance path before arranging another way to manage the device.

Apple’s guide to Screen Sharing settings

Keep the access review short enough to finish: who needs remote access, what task does it support, and who approves changes? “Someone who used to help us” is a reason to revisit the setting, not leave it enabled indefinitely.

• Turn off unneeded Screen Sharing through the normal settings or your managed configuration process.

• For required access, restrict it to the intended support users and approved management network paths. Review existing access rules with your administrator.

• After patching, verify the legitimate support workflow still works. Record the owner and next review date so the access decision remains visible.

Investigate unexpected sessions separately

A patched Mac and a justified access configuration address the maintenance work. Unexpected remote sessions still need an explanation. Preserve the relevant device and identity records and follow those signs through the incident process before closing them out.

Source check: September 8, 2026. This article analyzes public findings; the vulnerability was not discovered by Short Circuit LLC.