一个用于远程控制 Mac 的功能，变成了无需正常密码认证的入口
macOS 自带的 Screen Sharing，也就是“屏幕共享”，是一项允许用户通过网络远程查看和控制 Mac 桌面的功能。它基于 VNC/RFB 体系工作，在常见配置中会通过 TCP 5900 提供服务，因此不少家庭用户、远程开发环境、托管 Mac mini 和企业运维场景都会使用它进行远程管理。
正常情况下，远程访问首先应该经过身份认证，只有输入正确的账号凭证之后，客户端才能进入系统。但 CVE-2026-65400 恰恰出现在认证过程本身，Apple 官方将其描述为 Screen Sharing 中的身份认证问题，网络攻击者可能在没有有效凭证的情况下完成认证，而修复方式则是改进认证过程中的状态管理。
这意味着，风险并不是“攻击者已经拿到了你的 Mac 密码”，而是攻击者可能直接绕过本来应该阻止陌生人的认证机制。只要目标设备开启了 Screen Sharing，而且对应服务能够从互联网直接访问，攻击面就已经形成。
漏洞核心在于 Screen Sharing 的认证状态管理
安全研究人员对该漏洞进一步分析后发现，问题涉及 macOS screensharingd 服务在处理 Secure Remote Password，也就是 SRP 认证过程时的状态管理。
Screen Sharing 在原生 Apple 认证路径中会使用真实 macOS 用户账号，并通过 SRP 完成身份验证，但漏洞会让服务在异常请求状态下错误保留之前的成功状态，使连接在实际上没有完成合法认证的情况下，被错误地视为已经通过认证。
因此，仅仅修改 Screen Sharing 密码、增加密码复杂度，或者调整允许远程登录的用户，并不能真正修复这个问题。因为攻击者利用的是身份认证逻辑自身，而不是传统意义上的暴力破解或密码猜测。
这也是为什么 CVE-2026-65400 的风险远高于普通弱密码问题。对于 pre-authentication，也就是认证前漏洞来说，攻击者甚至不需要先拥有一个低权限账户，就有机会进入后续攻击流程。
为什么一个屏幕共享漏洞最终能够取得 root 权限？
如果漏洞只能让攻击者看到远程桌面，本身已经足够严重，但 CVE-2026-65400 的实际影响进一步扩大到了高权限文件访问和代码执行。
macOS Screen Sharing 内部包含用于文件传输和远程操作的辅助组件，其中部分进程拥有较高系统权限。研究人员发现，一旦认证绕过与这些组件结合，攻击者就可能进一步访问普通用户进程无法直接读取的系统资源，并寻找能够以高权限执行代码的路径。
这也是 CISA-ADP 后续把漏洞影响重新评估为完整机密性、完整性和可用性破坏的重要原因。
真实攻击进一步证明，这种风险并不只是理论推导。荷兰 NCSC-NL 已确认，其掌握的实际攻击案例中，攻击者最终都获得了 root 权限。
在 macOS 中，root 代表最高级别的系统权限。一旦攻击者能够以 root 身份执行代码，就不再只是控制一个应用程序，而是可能读取敏感文件、修改系统配置、安装持久化程序、创建隐藏账户，甚至把这台 Mac 作为后续攻击的基础设施。
荷兰 NCSC 已确认漏洞正在被实际利用
此次事件最值得关注的变化，是 CVE-2026-65400 已经从“存在公开漏洞”进入“真实世界攻击”阶段。
荷兰国家网络安全中心 NCSC-NL 在后续安全公告中明确表示，已经收到多个相关攻击报告，而这些被攻击系统存在一个共同特征：TCP 5900 端口直接暴露在互联网。
在 NCSC-NL 掌握的案例中，攻击者成功取得了受影响 Mac 的 root 权限，并进一步安装 Monero 门罗币挖矿程序。
这说明攻击者已经不仅能够理解漏洞原理，还已经拥有可以直接用于现实攻击的利用链。
对于服务器和公网远程管理服务来说，一旦漏洞 PoC 被公开并能够自动化，后续通常很快就会出现大规模互联网扫描。攻击者并不需要知道具体目标是谁，只需要不断扫描哪些公网 IP 的 5900 端口处于开放状态，再自动判断目标系统是否存在漏洞即可。
因此，对于仍然把 macOS Screen Sharing 暴露到公网的设备来说，风险已经具有明显的时间敏感性。
为什么攻击者选择安装 Monero 挖矿程序？
目前已经观察到的 Payload 主要是 Monero，也就是门罗币挖矿程序。
这种攻击方式在过去多年中一直非常常见，因为攻击者一旦控制大量服务器、NAS、PC 或云实例，就可以直接利用受害设备的 CPU 资源进行加密货币挖矿，而不需要进一步寻找如何出售窃取的数据。
对于单台设备来说，挖矿收益可能很有限，但如果攻击者可以通过自动扫描控制成百上千台机器，整体计算资源就能够产生持续收益。
受害用户则可能看到 Mac 长期高 CPU 占用、设备温度升高、风扇持续运行、性能下降以及电力消耗异常。
不过真正值得关注的并不是 Monero 本身，而是攻击者已经获得了 root。
挖矿只是当前观察到的一种后续行为。如果攻击者愿意，同样的权限理论上也可以用于部署信息窃取工具、远程后门或其他恶意软件。
因此，不能因为目前发现的是“矿工”就认为风险只涉及性能下降。
CVSS 为什么升到了 9.8？
CVE-2026-65400 当前的 CVSS 3.1 基础评分已经被 CISA-ADP 调整为：
9.8 / 10，Critical
对应向量为：
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
这几个指标基本说明了为什么该漏洞被重新评估为严重级别。
AV:N 表示漏洞可以通过网络触发，不需要攻击者能够物理接触设备。
AC:L 表示攻击复杂度较低，并不依赖非常苛刻的竞争条件或特殊环境。
PR:N 表示攻击者不需要事先拥有系统账号或其他权限。
UI:N 表示用户不需要点击链接、打开附件或者确认任何提示，攻击可以在没有用户交互的情况下发生。
与此同时，机密性、完整性和可用性影响均被评为 High，意味着成功利用后可能对系统造成全面影响。
对于一个公网远程管理服务而言，这几项条件同时出现，是非常典型的高风险组合。
真正危险的，是把 TCP 5900 直接放到公网
从目前已经确认的攻击案例来看，最关键的共同点并不是“用户开启过屏幕共享”，而是屏幕共享服务可以从互联网直接访问。
如果一台 Mac 只在家庭或企业局域网中启用了 Screen Sharing，而路由器没有把 TCP 5900 转发到公网，那么互联网攻击者通常无法直接连接这个服务。
但如果用户为了远程办公，在家庭路由器中配置了：
公网 TCP 5900 → 内网 Mac TCP 5900
或者设备本身就直接拥有公网 IPv4/IPv6，并允许互联网访问 5900，那么这台 Mac 就已经成为公开互联网中的一个远程服务。
攻击者不需要知道这台 Mac 属于谁，只需要扫描开放端口即可发现它。
过去一些用户可能认为“我的密码足够复杂，所以把远程桌面放到公网也没关系”，但 CVE-2026-65400 再次证明，这种思路存在明显问题。
如果漏洞发生在身份认证之前，那么密码再复杂也无法阻止攻击。
哪些 macOS 版本已经修复？
Apple 已经通过 2026 年 8 月发布的系统更新修复 CVE-2026-65400。
目前对应的已修复版本包括：
| macOS 分支 | 已修复版本 |
|---|---|
| macOS Tahoe | 26.6.1 |
| macOS Sequoia | 15.7.9 |
| macOS Sonoma | 14.8.9 |
如果设备仍然运行低于这些版本的对应系统，就应该尽快进入：
系统设置 → 通用 → 软件更新
安装最新安全更新。
由于漏洞已经出现真实利用和公开技术细节，因此在补丁已经存在的情况下，没有必要继续让设备运行存在已知认证绕过问题的版本。
普通 Mac 用户需要多担心？
这次漏洞虽然严重，但并不意味着所有连接互联网的 Mac 都可以直接被远程入侵。
风险最高的是开启 Screen Sharing，并且让 TCP 5900 从公网直接可达的设备。
普通家庭用户如果从未开启屏幕共享，也没有在路由器中配置 5900 端口转发，那么实际攻击面明显更小。
不过，系统仍然建议及时更新，因为用户可能过去为了测试、远程办公或设备管理开启过相关功能，而自己已经忘记；笔记本也会频繁进入公司、酒店和其他不同网络环境，长期依赖“我应该没有打开过”并不是好的安全策略。
如果暂时无法升级系统，可以进入：
系统设置 → 通用 → 共享
检查“屏幕共享”是否开启。
如果没有实际使用需求，直接关闭即可。
如果曾经把 5900 暴露在公网，仅仅更新系统还不一定够
如果一台存在漏洞的 Mac 曾经长期把 TCP 5900 暴露在互联网，那么现在安装补丁只能阻止后续利用，却不能证明此前从未被攻击。
尤其是在 NCSC-NL 已经确认真实攻击活动存在之后，这类设备应该进一步检查是否出现过异常。
例如，可以观察近期是否存在持续异常 CPU 占用、未知后台进程、异常网络连接以及不认识的 LaunchDaemon 或其他启动项目。
如果设备曾经出现长时间满载、风扇异常、陌生进程持续占用大量 CPU，则需要考虑是否存在恶意挖矿或其他入侵活动。
对于企业、服务器或者存储重要凭证的 Mac，如果已经确认攻击者曾经获得 root 权限，那么简单删除发现的挖矿程序并不能保证设备已经恢复可信状态。
攻击者可能已经植入其他持久化机制，或者读取了本地保存的密钥、Token 和凭证。
这种情况下，更稳妥的方法通常是重新部署系统，并轮换设备上存储的重要密码、SSH Key、API Token 和其他敏感凭证。
为什么仅仅修改 Screen Sharing 密码没有意义？
CVE-2026-65400 是身份认证流程自身存在逻辑错误，而不是密码强度不足。
这意味着把密码从 8 位改成 30 位，并不会修复漏洞。
同样，关闭传统 VNC 密码认证、重新设置 VNC 密码或者调整 Screen Sharing 用户列表，也不能替代 Apple 已经发布的安全补丁。
这种区别非常重要。
面对普通暴力破解，强密码确实能够显著提高攻击成本；面对 pre-authentication 漏洞，攻击者的目标却是让系统根本不进入正常密码验证过程。
因此，本次漏洞真正有效的处理方式是：
安装 Apple 安全更新，并减少 Screen Sharing 的公网暴露。
远程控制 Mac 更合理的网络架构是什么？
如果确实需要从外部访问家中、工作室或者机房里的 Mac，更合理的方法通常不是把 VNC/Screen Sharing 的 5900 端口直接映射到互联网。
传统结构可能是：
互联网 → 公网 TCP 5900 → Mac Screen Sharing
这种模式下，整个互联网都可以接触到 Screen Sharing 服务，安全性主要依赖服务自身没有漏洞，以及账号认证足够可靠。
更安全的思路则是：
远程设备 → VPN → 内部可信网络 → Mac Screen Sharing
这样 Screen Sharing 只需要对局域网开放，陌生互联网设备连服务本身都看不到。
即使未来 Screen Sharing、VNC、SSH 或其他远程管理程序再次出现新的认证漏洞，攻击者也无法像扫描公网服务一样直接触达目标，因为外面还有一层网络访问控制。
这种设计通常被称为减少攻击面。
VPN 无法修复 CVE-2026-65400，但可以减少公网攻击面
CVE-2026-65400 存在于 Apple Screen Sharing 软件本身，真正修复漏洞的方法只能是安装 Apple 发布的系统更新。
365VPN 或其他 VPN 工具无法改变 screensharingd 内部的认证代码。
但 VPN 在这种事件中的价值，是帮助用户重新设计远程访问路径，使内部服务不必直接面对整个互联网。
如果用户只是为了从外部访问一台家庭 Mac，没有必要一定把 TCP 5900 开放给全世界。更加理想的方式，是首先进入一个受控的 VPN 网络，再在内部访问对应 Mac。
这种思路不仅适用于 Screen Sharing，也适用于 SSH、NAS 管理后台、数据库、摄像头和其他远程管理服务。
这次事件真正应该吸取什么教训？
CVE-2026-65400 的意义并不只是“Mac 出现了一个 9.8 分漏洞”。
更加值得关注的是，它再次说明远程服务的安全不能只建立在密码之上。
一个今天没有公开漏洞的远程管理服务，并不意味着明天仍然没有漏洞。
如果它长期直接暴露在互联网，那么新的漏洞一旦公开，全球扫描器可能在几小时甚至几分钟内就开始寻找目标。
而如果服务本身只存在于内部网络，攻击者首先必须突破另一层访问边界，才能接触到存在漏洞的程序。
因此，安全补丁和网络隔离并不是二选一。
补丁解决已知漏洞。
减少公网暴露则降低未知漏洞未来被直接利用的机会。
365VPN 安全团队建议
CVE-2026-65400 已经不再是一个单纯的理论漏洞。
它具备网络可利用、低复杂度、无需已有权限和无需用户交互等危险特征，CISA-ADP 当前给出的 CVSS 3.1 基础评分已经达到 9.8 Critical，而荷兰 NCSC-NL 也确认，已有将 TCP 5900 暴露到互联网的 Mac 遭到实际攻击，攻击者获得 root 权限并安装 Monero 挖矿程序。
对于普通用户来说，现在最重要的动作并不复杂：把 macOS 更新到已经修复漏洞的版本，如果没有使用需求就关闭 Screen Sharing，同时检查家中路由器是否曾经配置过 5900 端口转发。
对于企业、托管 Mac mini 和远程运维环境，更应该重新审视网络架构。远程桌面、SSH、数据库和其他管理服务不应该仅仅因为“有密码”就长期暴露在公网，更理想的做法是先通过受控网络进入内部环境，再访问真正的管理服务。
如果一台存在漏洞的 Mac 曾长期把 5900 暴露到互联网，那么在完成系统更新之外，还应该进一步排查是否存在异常进程和持久化行为；如果已经确认 root 级入侵，则需要把系统完整性和本地凭证安全重新纳入评估。
补丁解决的是 CVE-2026-65400，而减少公网暴露，解决的是下一次未知漏洞出现时，你是否会第一时间成为互联网扫描器能够直接攻击的目标。