CVE-2026-65400：远程 Mac 如何自查？2026 清单

症状：远程 Mac 或 CI 节点启用了屏幕共享，但你不确定是否安装了修复。
最快解法：先核对 macOS 更新，再检查屏幕共享和远程管理的启用状态及网络可达范围；不要把 SSH 登录直接等同于 CVE-2026-65400 的受影响服务。

这份 CVE-2026-65400 远程 Mac 安全自查清单，适合维护远程 Mac、macOS 开发主机或自托管 CI 节点的工程师，尤其是启用了图形远程访问的团队。

负责 Apple 平台构建的 CI 运维人员，可用这些步骤安排更新和回归验收；开发基础设施负责人，则可据此留存主机清单、修复证据与异常升级路径。

最后更新于 2026 年 10 月 26 日；数据核实自 Apple 安全公告与安全更新列表、CISA 公告。 Apple 后续发布安全更新或补充漏洞说明时，应重新核对对应分支的公告。

漏洞范围只指向屏幕共享认证

Apple 将 CVE-2026-65400 描述为 macOS Screen Sharing 的认证问题：网络上的攻击者可能在没有有效凭据的情况下通过该服务完成认证。这个描述不能扩展成“所有远程连接都受影响”，也不能据此说 SSH 本身存在同一漏洞。(Apple 关于 CVE-2026-65400 的安全内容)

Apple 在 Tahoe 26.6.1、Sequoia 15.7.9、Sonoma 14.8.9 的安全内容中列出了该问题。后续版本是否已经包含修复，应以对应分支的 Apple 公告和安全更新记录为准，而不是仅凭系统名称、主版本号或“能正常登录”来判断。(Apple Sonoma 安全内容)

截至本文核对时，Apple 的版本页面列出 Golden Gate 27、Tahoe 26、Sequoia 15、Sonoma 14 的当前更新版本分别为 27.0.1、26.7.1、15.8.1、14.8.9。这些是版本核查线索，不替代 CVE 修复证据；遇到分支更新或设备无法升级时，仍需检查该分支具体公告。(Apple macOS 版本与构建信息)

CISA 于 2026 年 8 月 18 日将该 CVE 加入已知遭利用漏洞目录。这说明它值得提高修复优先级，但不能据此推断你的主机已经遭到访问。(CISA 公告)

按主机状态决定先做什么

下面的风险等级是运维分流用的判断，不是漏洞评分。若补丁状态未知，同时屏幕共享又能从不可信网络访问，优先限制暴露并安排更新；若有异常会话或账户，则按事件响应流程处理，不要只做版本升级后就结案。

先留版本证据，再安排补丁

第一步：记录版本和构建信息

在主机打开“苹果菜单”中的“关于本机”，记录 macOS 名称与完整版本；点击版本号查看构建信息。无图形界面的节点，可通过现有资产管理或受控运维流程取回版本信息，并保留采集时间与主机标识。Apple 的版本说明也明确指出，可以在“关于本机”查看系统版本和构建号。

不要只记录“系统已更新”。CI 节点常因构建依赖、维护窗口或兼容性要求滞后于日常工作站；只有版本、构建信息和适用公告能够互相对应，才便于团队复核。

第二步：对照对应分支的公告

按主机当前系统分支打开 Apple 安全内容页面，查找 CVE-2026-65400 和 Screen Sharing 条目，再核实已安装版本是否达到公告修复版本，或是否属于该分支后续更新。可从 Apple 安全更新列表进入相关页面；本文核对的公告还包括 Sequoia 15.7.9 的安全内容。(Apple Sequoia 安全内容)

若系统版本低于已公告的修复版本，或分支状态无法确认，就把主机列为待修复，而不是用“密码已改”“用户白名单已收紧”替代补丁。访问控制可以降低暴露，但不是修复该漏洞。

第三步：在维护窗口更新并验收构建

按团队维护流程安装适用于该主机分支的更新。更新前确认构建依赖、签名与发布流程有回退方案；更新后重新记录系统版本和构建信息，并执行能代表实际生产流程的构建任务。

CI 节点还要检查 Runner 是否重新上线、构建任务能否取回凭据、签名或制品流程是否正常。安全补丁已安装不代表流水线验收完成；同样，流水线跑通也不能单独证明补丁已安装。

再查图形远程访问的真实暴露面

第四步：盘点服务、用户和网络路径

在“系统设置 → 通用 → 共享”中，分别记录屏幕共享、远程管理和远程登录的开关状态及允许访问的用户。Apple 文档说明，屏幕共享与远程管理不能同时启用；两者均可提供图形控制能力，检查时不要把服务名称混为一谈。(Apple 屏幕共享设置说明)

接着逐层核对主机防火墙、路由器端口转发、云网络入站规则和管理网络边界。Apple 的 Remote Desktop 端口参考列出 TCP 5900 用于控制和观察，UDP 5900 用于屏幕发送与共享；如果使用端口映射或自定义端口，也要追查映射目标，不能只看默认端口。

只检查配置表不够：规则可能来自不同网络层，某处的“允许”与另一处的“拒绝”会共同决定实际可达性。使用组织批准的外部检测方式确认自有主机是否能从不可信网络访问；不要对不属于你的地址做探测。

第五步：区分 SSH 与屏幕共享

SSH 用于终端登录和文件传输，屏幕共享提供图形会话，两者应分别盘点。Apple 把远程登录说明为通过 SSH 或 SFTP 访问 Mac，并在“共享”设置中单独配置允许访问的用户；这也说明 SSH 状态不能代替屏幕共享状态检查。(Apple 远程登录与 SSH 说明)

因此，“只开启 SSH”的节点不应被直接判定为受该 Screen Sharing 漏洞影响；但如果团队清单里没有明确记录屏幕共享是否关闭，就仍需核实图形远程访问设置和网络规则。SSH 构建工作流可继续单独验收，同时确认关闭不需要的图形远程访问不会中断构建。

异常信号要按事件流程处理

没有看到异常连接，不等于此前从未发生访问；当前系统版本已修复，也不能证明修复前没有被访问。若发现未知会话、陌生账户、非预期的远程管理变更或其他可疑迹象，应依照组织事件响应流程保全日志与主机状态、限制相关访问，并升级给负责安全调查的人员。

CISA 的收录信息支持提高处理优先级，但不能替代主机侧调查，也不能将个别攻击报道扩大成“所有远程 Mac 均已受侵”。如果调查需要临时停用屏幕共享，先评估是否会影响值班、CI 运维或故障恢复，并通过变更流程执行。

常见自查问题

Apple 已发布哪些分支的修复信息？
Apple 的安全内容页面列出 Tahoe 26.6.1、Sequoia 15.7.9 和 Sonoma 14.8.9 的修复信息。后续系统更新可能继续包含修复，但应按对应分支的公告确认，不能把旧公告中的版本号机械套用到不同分支。

怎样确认远程 Mac 已修复？
记录主机系统版本与构建信息，查阅对应 Apple 安全内容页面中 CVE-2026-65400 的条目，再确认已安装修复版本或其后续更新。补上屏幕共享配置和网络可达性复核记录，便于审计时还原主机当时状态。

只有 SSH 的节点是否仍要检查屏幕共享？
SSH 和屏幕共享是不同的访问路径，Apple 对该 CVE 的描述指向 Screen Sharing，并不意味着 SSH 同样受影响。核实屏幕共享、远程管理是否关闭，再独立检查 SSH 的用户范围和构建任务；若配置不明，先补齐资产记录。

如何判断屏幕共享端口是否暴露公网？
联合检查主机防火墙、云网络入站规则、路由与端口映射，并从授权的外部检测点验证实际可达范围。TCP 5900 是 Apple 资料列出的控制与观察端口；有自定义映射时，还要沿规则追到目标主机。发现不可信网络可达时，先按流程限制访问。

安全验收不应止于“打了补丁”：你还需要能说明哪台主机、运行什么系统版本、启用了哪些远程服务、从哪些网络可以访问，以及异常时由谁接手。把这些记录和构建验收结果放在同一变更单里，后续排查才能区分补丁问题、网络暴露和流水线回归。

如果你目前依赖一台常驻自管 Mac，更新窗口、设备空闲时段和访问边界都要自己维护；Linux 主机则不能替代需要 macOS 专属工具链的构建环境。本机方案适合长期固定负载或需要物理接口的团队；若你只是需要临时的远程 Mac 测试或短期 CI 验收，租用 zshmac 的远程 Mac 可省去购置和闲置维护，但启用前仍应按本文清单核实访问方式与安全责任。可先查看 远程 Mac 方案对比和常见使用问题，再决定是否适合你的运维方式。

常见问题