Yes. CISA added CVE-2026-65400 to its Known Exploited Vulnerabilities catalogue on 18 August 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Apple macOS contains an improper authentication vulnerability that could allow an attacker on the network to authenticate to Screen Sharing without valid credentials.
What “being exploited in the wild” means for this CVE
For a CVE like this, the practical question is not just whether a flaw exists, but whether it has crossed from theoretical exposure into active abuse. CISA’s KEV listing is the strongest operational signal that defenders should treat it as a live threat, not a routine patch-cycle item. That makes exposure confirmation and urgent prioritisation the first two decisions to make.
Because the vulnerability is an improper authentication issue affecting network access to Screen Sharing, the key operational question is whether any macOS systems expose that service in a reachable way and whether those systems are in business-critical or high-trust roles. If the service is not needed, disable or restrict it rather than waiting for a convenience-based exception to turn into an exposure window.
Zero-Day and Exploited Vulnerabilities Guide is the right internal playbook when you need to triage a KEV-listed issue, decide how fast to act, and line up post-fix validation.
CISA Known Exploited Vulnerabilities Catalog is the authoritative source for confirming that a vulnerability has been added to KEV and for checking the associated remediation urgency.
How to confirm exposure and reduce the attack surface
Start by inventorying macOS assets that can accept network connections to Screen Sharing, especially endpoints that are remotely reachable, privileged, or used by administrators. A flaw in authentication only matters where the service is exposed, so the fastest way to shrink risk is to identify which systems actually offer that path and whether the service is required for any approved workflow.
If Screen Sharing is needed, constrain it to the smallest practical set of users, hosts, and network segments. If it is not needed, remove the exposure entirely by turning it off or blocking it at the network and host level. For network-facing authentication flaws, reducing reachability is often the only meaningful short-term control when patch deployment is delayed.
Use the vendor advisory for exact version and mitigation guidance rather than guessing at affected ranges. For a KEV-listed issue, you should treat every exposed instance as suspect until proven otherwise, because the operational assumption is that exploitation may already be happening elsewhere.
NIST National Vulnerability Database helps when you want a canonical record for the CVE and a reference point for vulnerability metadata.
CVE Program is useful when you need the authoritative identifier record and a stable way to track the issue across tooling and advisories.
What to do if patching must wait
If you cannot remediate immediately, treat the issue as an exposure management problem, not just a patch backlog item. Restrict access to the affected service, segment the hosts that provide it, and monitor for unexpected inbound attempts against Screen Sharing or related remote administration paths. Temporary compensating controls should be explicit, time-bound, and owned, not informal exceptions that drift into permanence.
Also check for earlier compromise on any exposed macOS host. For an authentication weakness, the evidence may be subtle, so review remote access logs, administrative activity, new user sessions, and changes to remote management settings. If the system supports sensitive access or stores credentials, assume that follow-on abuse is possible until the host is reviewed.
If the affected systems are used for administration, consider whether cached sessions or adjacent credentials could have been exposed during the exploitation window. In that case, rotate any materially exposed secrets and invalidate sessions that depended on the vulnerable access path.
Vulnerability Management Guide is the better internal reference when you need to prioritise, apply exceptions, and verify remediation after a KEV event.
FIRST EPSS is useful when you need another prioritisation signal alongside KEV to decide where to focus scarce remediation capacity.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack surface, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | KEV-listed exploitation needs risk-based prioritisation and response timing. |
| Recommendation — Prioritise exposed macOS hosts and track remediation as a risk decision. | ||
| NIST SP 800-53 Rev 5 | AC-17 — Remote Access | Screen Sharing is a remote access path that must be controlled and restricted. |
| IA-5 — Authenticator Management | Improper authentication directly implicates credential and authenticator handling. | |
| Recommendation — Restrict remote access to Screen Sharing and limit who can use it. Rotate any exposed credentials and invalidate stale sessions tied to the vulnerable path. | ||
| ISO/IEC 27001:2022 | A.8.5 — Secure authentication | The flaw is an authentication weakness on a network service, so secure authentication controls are directly relevant. |
| Recommendation — Strengthen authentication requirements and remove unnecessary remote access exposure. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Exposure reduction depends on controlling who can reach and use the remote service. |
| Recommendation — Tighten access to the affected service and remove unneeded remote access paths. | ||
| MITRE ATT&CK | T1021 — Remote Services | Screen Sharing is a remote service access path that attackers can abuse after exploitation. |
| Recommendation — Monitor and restrict remote service use, especially on high-value macOS systems. | ||
Practitioner Guidance
What to prioritise: Any macOS system with Screen Sharing reachable from networks you do not fully trust should be at the front of the queue, especially administrative endpoints and shared support machines. The business question is whether the service is truly required, because unnecessary exposure is the easiest risk to remove quickly.
What to verify: Confirm the service state, the network path to it, and whether the host has evidence of remote access attempts or unexpected logins. If patching is delayed, verify that the compensating control actually blocks the attack path and is not just a policy statement.
Decision rule: If the host cannot be patched immediately, disable or tightly restrict the exposed service first, then review logs and sessions. If the host is exposed and important, do not wait for proof of compromise before acting, because KEV status means the exploitation assumption is already strong.
Practitioner takeaway: For a KEV-listed authentication flaw, the right sequence is exposure reduction, compromise check, then patching or mitigation, not the other way around.
Related resources from NHI Mgmt Group
- How do you patch or mitigate CVE-2026-65400 (Apple macOS Improper Authentication)?
- CVE-2026-65400 (Apple macOS Improper Authentication)
- Is CVE-2026-42018 (JFrog Artifactory Improper Authentication) being exploited in the wild?
- Is CVE-2026-59822 (BerriAI LiteLLM Improper Authentication) being exploited in the wild?