macOS Tahoe 26.6.1：屏幕共享漏洞与你该做的事

苹果在 2026 年 8 月 6 日星期四发布了 macOS Tahoe 26.6.1，距离 26.6 仅过去十天。没有开发者测试版，没有公测版，没有任何新功能，Safari 没有升级，固件也没有变化。发行说明里只写了一条安全修复，安全文档里也只列出了一个 CVE。

这个组合本身就是新闻。苹果通常会先向开发者推送小版本更新至少几天再正式发布，而 x.x.1 版本一般会在安全修复之外附带若干 bug 修复。这一次苹果完全跳过了种子版本阶段，只带来一个条目：屏幕共享（Screen Sharing）组件中的 CVE-2026-65400。同一天，苹果还把相同的修复回移到了 macOS Sequoia 15.7.9 和 macOS Sonoma 14.8.9——厂商这么做，说明它希望修复一次性覆盖所有版本，而不只是当前版本。

macOS Tahoe 26.6.1 的屏幕共享漏洞值得认真理解，因为这个故事的诚实版本里，本该有关键细节的地方存在一大块空白。苹果的影响描述只有一句话。它没说受影响的服务是否必须处于开启状态，也没有描述漏洞机制。有几家媒体用无人佐证的具体细节填补了这块空白。本文会讲清楚哪些是真正确认的、哪些确实未知、谁才是现实中的高风险人群，以及无论漏洞如何工作都值得去做的实际操作：审计你自己 Mac 上的远程访问暴露面。

核心要点

• macOS Tahoe 26.6.1 为 25G76 版本，2026 年 8 月 6 日发布，只包含一条安全修复，别无其他。 Safari 停留在 26.6，系统固件保持 18000.161.9 不变，没有任何新功能。根据 Mr. Macintosh 对更新包的拆解，增量更新在 Apple 芯片上约 2.1 GB，在 Intel 上约 898.9 MB。
• CVE-2026-65400 是屏幕共享中的身份验证绕过漏洞。 苹果的影响描述原文是：「网络上的攻击者可能无需有效凭据即可通过屏幕共享的身份验证。」修复方式，用苹果的话说，是「通过改进状态管理解决了一个身份验证问题」。苹果将功劳归于与 Bynario Atlas 合作的 Alfredo Pesoli（@__rev），德国媒体 heise 称 Bynario Atlas 是一套基于 AI 的漏洞检测系统。
• 影响范围是本地网络，不是公开互联网。 heise 指出，如果 Mac 位于本地网络内、且路由器上没有转发相关端口，就无法从互联网发起远程屏幕共享。现实中的威胁模型是共享 Wi-Fi 网络：办公室、宿舍、联合办公空间、酒店、咖啡馆。
• 苹果没有说明攻击是否需要屏幕共享处于开启状态，而这恰恰是立即更新的最强理由。 heise 明确表示，目前尚不清楚屏幕共享或 Apple Remote Desktop 是否必须处于激活状态，也不清楚在屏幕共享总体关闭的情况下能否发起攻击。新 Mac 上屏幕共享默认关闭，所以很多人希望得出「我从没暴露过」的结论。但苹果公开的任何材料都不支持这个结论。
• 同一修复也落地于 macOS Sequoia 15.7.9（版本 24G830）和 macOS Sonoma 14.8.9（版本 23J631）。 苹果同一天回移到两个更旧的大版本，是它把这件事看得比较严重的合理信号。苹果表示没有已知的在野利用。就这个问题而言，继续留在旧版 macOS 没有问题，只要你安装对应的补丁。

macOS Tahoe 26.6.1 到底是什么

Tahoe 26.6 于 2026 年 7 月 27 日发布，版本号 25G72，是整个 Tahoe 周期中规模最大的一批安全修复，一口气关闭了 140 多个问题。我们的macOS Tahoe 26.6 完整解读介绍了其中的内容，包括苹果称之为「为 macOS 27 做准备」的 Spotlight 重建索引工作。

macOS Tahoe 26.6.1 则完全是另一种类型的更新。它的版本号是 25G76，日期为 2026 年 8 月 6 日，存在的意义就是堵上一个洞。

关于这个更新包，以下是已确认的信息：

• 版本号： 25G76
• 发布日期： 2026 年 8 月 6 日，大约在 26.6 之后十天
• 测试版种子： 无。没有开发者测试版，也没有公测版
• 新功能： 无
• Safari： 停留在 26.6 版本，未升级
• 系统固件： 保持 18000.161.9 不变
• 安全内容： 一个 CVE，即屏幕共享中的 CVE-2026-65400
• 苹果安全文档： support.apple.com/en-us/148170

下载体积数据来自 Mr. Macintosh，他一贯会公布苹果各次发布的更新包细节。增量更新在 Apple 芯片上约 2.1 GB，在 Intel 上约 898.9 MB。如果你下载的是完整安装器而非增量包，体积要大得多。Intel 增量包不到 1 GB 而 Apple 芯片增量包超过 2 GB，在 Tahoe 上属于正常现象，因为 Apple 芯片路径包含一份签名系统卷负载，重建方式不同。

为什么跳过测试版值得注意

苹果发布小版本更新的常规节奏是：至少一次开发者种子版，通常还有一个候选发布版，往往在一两天后再放出公测版。这个流程的存在意义，是在数百万台机器安装更新前发现回归问题。

跳过它并非闻所未闻，但足够反常，因而具有信息量。当苹果不做种子推送、也没有任何功能负载就直接发布时，合理的解读是：修复很小、边界清晰，而苹果希望它比种子版日程允许的速度更快地送出去。这跟「这个漏洞正在被利用」不是一回事。苹果明确表示没有已知的在野利用。它只意味着苹果不想再等一周。

回移是第二个信号。苹果会为当前版本之前的两个 macOS 版本维护安全更新，但并不总是在同一天把同一个修复推给全部三个版本。这次同时推给 Sequoia 15.7.9 和 Sonoma 14.8.9，说明苹果认为这个问题不应该在任何受支持的机器上继续悬着。

截至今天的版本时间线

如果你想确认自己所处的位置，近期值得关注的 Tahoe 版本如下：

• 26.5，2026 年 5 月 11 日，详见我们的 macOS Tahoe 26.5 更新指南
• 26.5.1，2026 年 6 月 1 日
• 26.5.2，2026 年 6 月 29 日
• 26.6，2026 年 7 月 27 日，版本号 25G72
• 26.6.1，2026 年 8 月 6 日，版本号 25G76

要确认你自己的 Mac 正在运行什么版本，打开「终端」并运行：

sw_vers

它会打印产品名称、版本号和内部版本号。如果版本显示 26.6.1、内部版本显示 25G76，说明你已经打上了补丁。你也可以点击苹果菜单，选择「关于本机」，再点击版本号来显示内部版本号。

CVE-2026-65400 究竟允许了什么，说人话版

苹果的安全文档以简略著称。这一次，全部描述加起来只有两句话。

影响：

网络上的攻击者可能无需有效凭据即可通过屏幕共享的身份验证。

修复：

通过改进状态管理解决了一个身份验证问题。

这两句话都值得逐字细读。

「通过屏幕共享的身份验证」

Mac 上的屏幕共享是一项交出图形会话实时控制权的服务。连接上来的人能看到显示器上的内容，可以移动指针、打字、打开应用，并读取登录用户能读取的一切。它不是文件传输通道，也不是只读视图。它就是你的办公桌本身。

正常情况下，访问这项服务需要凭据。取决于配置方式，这意味着某个被允许连接的用户的账户密码，或者在启用了传统 VNC 选项时使用的独立 VNC 密码。服务会在授予会话前校验这些凭据。

「无需有效凭据即可通过身份验证」意味着这道校验可以在没有正确密钥的情况下被判定为通过。攻击者并没有拿到你的密码，他们也不需要。他们只是让服务进入了一种「认为身份验证已成功」的状态。

这能带来什么，取决于该连接被授权成什么权限级别。如果 Mac 上连接的账户是管理员，那就是一个具备管理员权限的会话，实际效果几乎等同于完全控制这台机器。如果共享账户是标准用户，那就是该用户的访问权限——但这依然足以读取文稿、翻看邮件、看到屏幕上的一切。

「改进状态管理」

苹果描述修复时用的词汇量很小，每个短语大致对应一类 bug。「改进状态管理」通常指向某项服务在多步骤流程中错误地记录了自身进度。代码中某处保存着「这个连接是否已通过验证」的判断，而这个判断有可能是错的。

公开记录到此为止。苹果没有公布漏洞机制，除苹果自己之外，也没有任何厂商公告描述过它。

关于研究者致谢

苹果致谢的是与 Bynario Atlas（bynar.io）合作的 Alfredo Pesoli（@__rev）。heise 称 Bynario Atlas 是一套基于 AI 的漏洞检测系统，这使得本次事件成为自动化发现流水线产出苹果致谢 CVE 的较为显眼的案例之一。不同媒体对该研究者姓名拼写的报道略有出入；但致谢本身没有争议。

现实威胁模型：仅限本地网络

苹果影响声明中「网络上的攻击者」这个说法承担了很大的信息量，它也是判断该有多担心时最有用的一条背景。

heise 的报道明确划出了边界：如果 Mac 位于本地网络内，且路由器上没有转发相关端口，就无法从互联网发起远程屏幕共享。屏幕共享监听 TCP 5900 端口，Apple Remote Desktop 则在此之外使用 3283。消费级路由器不会转发这些端口，除非有人专门去配置；而网络地址转换意味着公网上的攻击者无法直接拨通你 Mac 的内网地址。

所以攻击者必须已经处在与你的 Mac 相同的网段上。

「在同一网络上」在现实中意味着什么

这没有听上去那么罕见。以下这些网络，你都在和无法控制的人共享同一个广播域：

• 办公室 Wi-Fi，包括没有与主网络正确隔离的访客网络
• 联合办公空间，其存在意义就是让陌生人共享基础设施
• 大学宿舍和校园网，往往是扁平且庞大的
• 酒店 Wi-Fi，经常是所有房间共用一个子网
• 咖啡馆和机场 Wi-Fi
• 会议和活动网络
• 共享宽带的公寓楼

风险明显更低的网络：

• 设备数量少且全部已知的家庭网络，前提是 Wi-Fi 密码没有广泛外传，且网络中没有不受信任的设备
• 仅通过你自己控制的手机蜂窝网络共享上网的机器

有一个细节值得点明。「网络上的攻击者」并不要求真有人拿着笔记本坐在楼里。网络中一台已被攻陷的设备同样管用。这包括一台被感染的 Windows 电脑、一台疏于维护的 IoT 设备，或者一台存在已知缺陷的路由器。本地网络的范围限制大大缩小了风险，但并没有把风险降为零。

为什么这是个严重漏洞，但不必恐慌

三个事实共同决定了这里的温度。第一，苹果表示没有已知的在野利用。第二，攻击需要网络邻接，因此不存在全网大规模扫描的场景。第三，苹果没有公布机制，这意味着潜在攻击者必须自行发现，而不是照着一篇分析文章照做。

与之相对的是，这个修复紧急到跳过了测试版种子推送，重要到被回移了两次。正确的应对是本周装上更新，顺手审计一下你的共享设置。而不是把 Mac 从互联网上拔掉。

谁才是真正有实质风险的人

并不是每台 Mac 面临的暴露程度都一样，与其发一份笼统警告，不如说得具体些。

较高风险

作为服务器长期开机的 Mac mini 和 Mac Studio。 这类机器最可能长期开启屏幕共享，因为它们往往没有接键盘和显示器。它们一直通电、一直在网上，也没人盯着屏幕看。放在储物间里跑媒体服务器、构建代理或家庭自动化中枢的 Mac mini，正好符合这一画像。

共享办公室和联合办公空间里的 Mac。 不受信任的网络，加上一台可能为了 IT 便利而开启了屏幕共享的机器，是这里最糟糕的组合。

由 IT 统一管理的机队。 使用 Apple Remote Desktop 或通过 MDM 启用远程观察的组织，是按策略在大量机器上同时开启了屏幕共享基础设施。如果你在管理一支机队，这次更新是优先部署项，下文的审计步骤应当按规模执行，而不是一台台手动做。

曾经开过屏幕共享然后忘了关的人。 这比人们承认的更常见。你为了帮家人、或者为了从笔记本连回台式机而打开了它，然后它就一直开着。

在路由器上转发了 5900 端口的 Mac。 如果有人刻意把屏幕共享暴露到互联网上，本地网络的限制就保护不了他们。这种配置在这个 CVE 出现之前就是个坏主意，现在更是。

较低风险

使用默认设置、只待在家庭网络里的笔记本。 新 Mac 上屏幕共享默认关闭。如果你从未开启过它，而且家庭网络规模小、设备都认识，那么你的暴露程度很低。

大部分时间处于睡眠或关机状态的 Mac。 没有运行的服务是无法被访问的。

位于正确分段的访客网络后面的机器。 访客 SSID 上的客户端隔离会阻止该网络上的设备互相访问，从而消除了攻击所需的邻接性。

以上这一切都要附加一个前提，原因见下一节。

苹果没有告诉我们的部分

这是大多数报道跳过的部分，也是最该塑造你对这次更新看法的部分。

开启还是关闭，这个问题没有答案

苹果的公告没有说明 CVE-2026-65400 是否需要屏幕共享处于开启状态才能被利用。heise 直接点出了这一空白：目前尚不清楚访问是否必须依赖屏幕共享或 Apple Remote Desktop 处于激活状态，也不清楚在屏幕共享总体关闭的情况下是否仍可能发生攻击。

这对个人风险评估极为重要，因为屏幕共享默认是关闭的。如果服务必须处于运行状态，受影响人群就很小且是自我筛选出来的。如果共享栈中某个组件在开关关闭时依然监听或响应，那么受影响人群就是受支持版本上的每一台 Mac。

两个方向上都有合理论据。在「系统设置」中关闭的服务，在 macOS 上确实不会开着监听套接字，这支持较窄的解读。另一方面，macOS 对若干系统服务使用 launchd 套接字激活机制，因此某个 launch daemon 可以处于休眠状态，而系统仍然持有一个可按需将其唤起的套接字，这又支持较宽的解读。苹果选择两次回移并跳过测试版种子推送，至少与较宽的解读弱相关，但这算不上证据。

诚实的答案是：苹果之外没有人知道，我也不打算装作知道。

在这种不确定下该如何思考： 把未知当作更新的理由，而不是当作去推断自己是否曾暴露的邀请。安装 26.6.1 的代价是重启一次。猜错「关闭的开关是否保护了你」的代价，是一个陌生人拥有你的屏幕。这种不对称本身就足以做出决定，不需要那块缺失的细节。

机制未公开，部分已发表的细节无人佐证

关于这个漏洞，更详细的技术说法正在流传，包括究竟是哪个守护进程出了问题、什么触发了错误状态，以及攻击者多快能拿到特权 shell。这些说法出现在少数几家二三线媒体上，来源单一，既没有得到苹果证实，也没有得到 heise 或 9to5Mac 报道的佐证——后者的报道中完全没有这些细节。请谨慎对待，不要围绕它们来安排你的应对。

这不是杞人忧天。过度具体的漏洞分析会影响行为。如果你读到某个漏洞只对开启了特定设置的机器有效，你可能就会跳过更新。而如果这个细节其实是编造的，你就白白跳过了一次更新。

具体到你该怎么做

• 安装 26.6.1、15.7.9 或 14.8.9，取决于你运行的是哪个 macOS
• 不要拿「我的屏幕共享是关的，所以我没事」当作推迟的理由
• 无论如何都审计一下你的共享设置，因为这件事本身就值得做
• 在可靠的技术分析出现之前，忽略关于漏洞利用机制的各种说法

如何审计你 Mac 的远程访问暴露面

这是本文最实用的核心部分，无论你是否曾因这个具体的 CVE 而处于风险中，它都有价值。大多数人从来没有真正看过自己的 Mac 向网络暴露了什么。

打开系统设置，进入通用，再进入共享。你会看到一列带独立开关的服务。其中三项管辖对你机器的远程访问，而人们经常把它们搞混。

屏幕共享（Screen Sharing）

这就是 CVE-2026-65400 影响的服务。开启后，其他机器可以通过 VNC、经由 TCP 5900 端口连接进来并接管你的图形会话。

怎么查： 在「共享」面板中查看「屏幕共享」这一行。如果开关是关的，服务就没有启用。如果是开的，点击旁边的小信息按钮，查看访问列表。

访问列表意味着什么： 默认选项是「所有用户」或指定列表。这里的「所有用户」指的是 Mac 上的每一个用户账户，包括你创建后早已遗忘的任何账户。限制为指定名单严格来说更好。点击信息按钮，选择「仅允许这些用户访问」，然后添加确实需要访问的具体账户。

该面板中的「电脑设置」 还包含两个选项。一个允许任何人请求控制屏幕的权限，此时会向登录用户弹出提示。另一个启用 VNC 密码，让非 Apple 客户端可以用共享密码而非账户凭据连接。VNC 密码是两条身份验证路径中较弱的一条，而且受协议限制最长只有 8 个字符。如果你不是特别需要它来接入第三方客户端，就让它保持关闭。

不需要就关掉它。 这是大多数人在这个面板里能做的、性价比最高的一项改动。

远程登录（SSH）

这是一项完全独立的服务，走 TCP 22 端口。它提供的是命令行访问，而非图形访问。它不受 CVE-2026-65400 影响，关闭屏幕共享对它也毫无作用。

人们把这两者混为一谈，是因为它们都属于「远程访问」，也因为关掉其中一个感觉上就该把门关上了。但事实并非如此。

从终端检查：

sudo systemsetup -getremotelogin

它会报告远程登录处于开启还是关闭状态。要关闭它：

sudo systemsetup -setremotelogin off

你也可以在「共享」面板中关闭「远程登录」开关来达到同样效果。和屏幕共享一样，信息按钮允许你把访问限制到特定用户而不是所有用户，你应该这么做。

如果你经常使用 SSH，真正有意义的加固步骤是彻底禁用密码认证、改用密钥，这会消除针对它的整整一类猜测攻击。

远程管理（Apple Remote Desktop）

这是第三个开关，也是最容易引起混淆的一个。

远程管理就是 Apple Remote Desktop 代理。它提供屏幕观察与控制，此外还有软件分发、报告和远程命令执行。这是 IT 部门用来管理机队的工具。除了 5900，它还使用 3283 端口。

关键细节：在 macOS 界面中，屏幕共享与远程管理是互斥的。 你不能同时开启两者。开启远程管理会自动关闭屏幕共享，macOS 也会明确提示你。人们容易忽略的正是它的后果：如果你进入「共享」，看到屏幕共享是关的，就断定没有人能看到你的屏幕，那你可能错了。远程管理也许正开着，通过另一项服务提供着相同的能力。

所以每次都要同时检查两行。 屏幕共享关闭加上远程管理开启，不是一个加固过的配置。那是同一扇门，只是换了个把手。

远程管理的信息按钮背后也有一份细粒度权限列表，涵盖远程用户是否可以观察、控制、拷贝文件、删除项目、重启机器等等。如果远程管理是因为你的雇主管理这台 Mac 才开着的，不要直接把它关掉。先跟管理机队的人沟通，因为关闭它可能会破坏他们的管理，也可能违反你所在组织的政策。

检查你的 Mac 是否已加入 MDM

如果你不确定是否有组织在管理你的 Mac，用这条命令就能知道：

sudo profiles status -type enrollment

它会报告这台 Mac 是否通过苹果的自动设备注册加入，以及当前是否有活跃的 MDM 注册。一台你在零售渠道购买、自己设置的个人 Mac 会显示未注册。由雇主或学校发放的机器通常会显示存在活跃注册。

这一点重要有两个原因。第一，如果这台 Mac 处于受管状态，远程访问设置可能由描述文件强制指定，你改完之后可能会被重置回去。第二，如果它受管，更新本身可能由所在组织的软件更新策略控制而不是由你控制，这会改变你拿到 26.6.1 的方式。

你还可以列出已安装的配置描述文件：

sudo profiles list

它会显示已安装的内容。如果你在一台自认为是私人的机器上看到不认识的描述文件，那值得追查。

检查防火墙

macOS 自带一个应用程序防火墙，在部分配置下默认并未启用。无论这个 CVE 如何，它都值得打开。

在界面中： 系统设置 → 网络 → 防火墙，打开开关。在「选项」按钮后面，你可以控制哪些服务和应用允许接受传入连接，还可以启用隐匿模式——它会让 Mac 拒绝响应来自未授权来源的 ping 和端口扫描等探测。

从终端：

/usr/libexec/ApplicationFirewall/socketfilterfw --getglobalstate

它会报告防火墙是否开启。

有一条重要限制：macOS 应用程序防火墙不会阻挡你在「共享」中明确启用的服务。如果屏幕共享是开着的，macOS 会认为对它的传入连接是符合预期的，并放行。防火墙是一层有用的防护，但它不能替代关闭你不用的服务。如果你需要阻断某项已在「共享」中启用的服务，那应该在路由器上或用包过滤规则完成，而不是靠应用程序防火墙。

看看究竟有什么在监听

如果你想眼见为实而不是相信开关，这条命令会显示哪个进程绑定在屏幕共享端口上：

sudo lsof -i :5900

没有输出说明该端口上没有任何监听。你可以把端口换成 22 查 SSH，换成 3283 查 Apple Remote Desktop 端口。

这类审计是一个好习惯，与任何单个 CVE 都无关。我们的 Mac 安全与隐私指南 介绍了值得定期检查的更广泛设置，包括 FileVault、Gatekeeper、隐私权限，以及各项共享服务实际暴露了什么。

如果你确实需要远程访问，该如何加固

很多人有远程连接 Mac 的真实需求。家庭服务器、放在办公室的机器、你负责支持的家人的电脑。关掉这个功能对他们来说不是选项。以下是在保留功能的同时缩小暴露面的做法。

通过私有网络而非公共网络访问 Mac

最有效的单项改动，是不再把这项服务暴露给任何你无法控制的网络，而是把 Mac 和你的客户端放进同一个私有覆盖网络。

接入家庭或办公网络的 VPN 可以做到。Tailscale、WireGuard 或 ZeroTier 这类覆盖网络也可以——它们在你的设备之间建立加密网状网络，为每台设备分配一个稳定的、公网无法访问的私有地址。有了它，屏幕共享只会在一个仅你自己的设备能触达的接口上监听。咖啡馆 Wi-Fi 上的攻击者在任何实质意义上都不再与该服务邻接，因为服务并没有暴露在你们共享的那个本地接口上。

对绝大多数实际场景来说，这种做法本可以让 CVE-2026-65400 的本地网络范围失去意义，而且它对下一个漏洞同样有效。如果你在配置过程中遇到连接问题，我们的 macOS VPN 故障排查指南 涵盖了配置描述文件、DNS 和分流隧道方面常见的故障模式。

永远不要转发 5900 端口

把路由器上的 5900 端口转发到一台 Mac，等于把屏幕共享服务直接放到公网上，自动化扫描器几小时内就会发现它。5900 端口上的 VNC 是互联网上被扫描最频繁的端口之一。不要这么做。如果你已经这么做了，现在就撤销。

同样的道理适用于 Apple Remote Desktop 的 3283 和 SSH 的 22。如果你必须暴露 SSH，请换掉默认端口、禁用密码认证、改用密钥——但更好的答案依然是 VPN。

使用带明确允许列表的专用账户

不要把你日常使用的管理员账户当作远程访问账户。为它单独创建一个账户，只给必需的权限，并且只把这个账户加入屏幕共享的允许用户列表。如果远程路径被攻陷，爆炸半径就限于这个账户，而不是一个管理员会话。

给它设置一个真正强的密码。密码复用是很多远程访问事件演变成严重事故的原因。

保持允许用户列表明确并定期复查

「所有用户」很方便，但是错的。Mac 上的每个账户都会被隐式授权，包括旧账户、类似访客的账户，以及你多年前为别的事创建的服务账户。明确设定这份名单，并在有人离开或你停用某个账户时重新检查它。

不用的时候把服务关掉

如果你只是偶尔需要屏幕共享，那就用的时候打开、用完关掉。一项每月运行二十分钟的服务，和一项连续运行三年的服务，暴露风险完全不同。

如何安装 macOS Tahoe 26.6.1

这次更新和其他小版本一样，通过「软件更新」推送。

1. 先备份。Time Machine 或克隆都行，但一定要有。这是个小更新，风险很低，但规矩不变。
2. 打开系统设置，进入通用，再进入软件更新。
3. 等待检查完成。macOS Tahoe 26.6.1 应该会显示为可用更新。
4. 点击「立即更新」并输入密码。
5. 让 Mac 重启。在 Apple 芯片上，整个过程通常需要十到二十分钟，取决于机型和磁盘。
6. 重启完成后，在终端运行 sw_vers 或查看「关于本机」进行确认。你要看到的是版本 26.6.1、内部版本 25G76。

在终端里，你也可以不通过界面完成列出与安装：

softwareupdate --list

它会显示有哪些可用更新。要安装所有适用的更新：

sudo softwareupdate -i -a

如果你希望安装完成后机器自动重启，加上 --restart。

如果更新还没出现

苹果对小版本更新采用分批推送。8 月 6 日，有用户反馈 26.6.1 在部分 M4 和 M5 Mac 上尚未出现，而在其他机器上已经可用，这些情况后来都自行恢复，无需人工干预。

如果「软件更新」里什么都没显示：

• 等几个小时再看。分批推送通常需要一天才能覆盖所有人。
• 完全退出「系统设置」再重新打开，然后重新检查。软件更新面板会缓存状态，有时需要推一把。
• 在终端运行 softwareupdate --list，它会直接查询苹果服务器，有时能显示出界面尚未呈现的更新。
• 如果你的 Mac 由某个组织管理，更新可能被策略延后。sudo profiles status -type enrollment 能告诉你是否存在这种可能，若是，时间由你的 IT 团队掌握。
• 作为最后手段，苹果会发布独立安装包，Mr. Macintosh 也一贯会整理每次发布的直接下载链接。下载完整安装器可以绕过分批推送，代价是下载体积大得多。

如果安装失败

小版本更新大多能顺利安装，但常见的失败模式依然存在：可用空间不足、下载中断，或者在准备阶段卡住。我们的 macOS 更新卡住或安装失败排查指南 讲解了如何正确释放空间、清除不完整的下载，以及从停滞的安装中恢复。

一句话版本：你需要的可用空间要明显大于下载体积，因为 macOS 需要空间来展开和暂存更新。对于 2.1 GB 的增量包，留出 20 GB 可用空间是个从容的余量，并不算过分。

如果你在用 Sonoma 或 Sequoia

苹果在 2026 年 8 月 6 日把相同的修复推送给了两个仍受支持的旧版 macOS：

macOS 版本	已修复版本	内部版本号
macOS Tahoe 26	26.6.1	25G76
macOS Sequoia 15	15.7.9	24G830
macOS Sonoma 14	14.8.9	23J631

路径完全一致：系统设置 → 通用 → 软件更新 → 安装 → 重启。

关于留在旧版 macOS，有两点值得说明。第一，就这个具体问题而言，留在 Sequoia 或 Sonoma 完全没问题，只要你装上对应的补丁。你拿到的不是缩水版修复。苹果在三个版本上处理的是同一个 CVE。

第二，这只在苹果继续为你的版本提供安全更新期间成立，而它的覆盖范围大致是当前版本加上之前两个版本。Sonoma 14 已经处在这个窗口的边缘。如果你有理由留在 Sonoma，那个理由值得定期重新审视，因为总有一天会出现一个只在更新版本上修复的 CVE。

旧版本有时还会收到比当前版本更窄的修复子集，即便头条 CVE 是共享的。这次不属于这种情况，因为 26.6.1 只包含一个修复；但这正是为什么「我用的是旧版 macOS，不过我每次更新都装」这个立场，长期来看比听上去要弱。

Intel 视角

Intel Mac 和其他机器一样会拿到 26.6.1，只是增量包更小，为 898.9 MB。之所以要单独提一句，是因为它所代表的东西。

macOS 27 仅支持 Apple 芯片。Intel Mac 无法运行它，这使得 macOS Tahoe 26 成为这些机器能收到的最后一个大版本。苹果的惯例是在某个版本不再是当前版本之后，继续提供大约三年的安全更新，因此 Intel Mac 用户可以预期继续收到和这次一模一样的更新：版本号变一下，一个或几个 CVE，没有新功能。

这让 26.6.1 成为 Intel 硬件未来几年的一次有用预演。这些更新会越来越乏味，也越来越重要。不会再有新能力需要评估，所以每次唯一的问题就是要不要装，而答案会是要。我们的 Intel Mac 时代终结解读 涵盖了完整兼容性列表以及支持时间线的现实情况。

如果你把 Intel Mac 当作长期开机的机器使用，上文的审计部分尤其值得关注。老款 Mac mini 恰恰是最可能被塞在储物间里、开着屏幕共享而无人记得的机型。

关于第三方 VNC 的观察

本节属于推测，并且明确标注为推测。收录它是因为它可能对特定一小群读者有用，而不是因为它已被证实。

macOS Tahoe 26.6 在 7 月底发布后，一些用户反馈第三方 VNC 客户端无法再连接到他们的 Mac。相关反馈涉及运行在 Windows、iOS 和 Linux 上的 RealVNC 及其他客户端，其中 RealVNC 会弹出类似「密钥长度过大」的协议错误提示。在同一批反馈中，Mac 之间的屏幕共享依然正常工作，正是这个细节让这一模式变得有意思，而不只是一次泛泛的故障。

我们无法直接读到最初的论坛帖子，因此这段描述基于二手信息，请据此判断可信度。我们也不了解苹果是否就该行为发表过任何声明。

这个假设，作为假设陈述如下：26.6 可能修改了屏幕共享身份验证路径中的某些东西，从而破坏了与第三方 VNC 客户端的兼容性，而 CVE-2026-65400 可能就位于同一段代码中。一次收紧身份验证处理的改动，十天后紧接着一次针对同一组件中身份验证状态 bug 的修复，是一个有暗示性的时间序列。苹果没有公布任何把二者联系起来的信息，heise 说机制仍不明确，而有暗示性的时间序列并不是证据。

这在实践中意味着什么：

• 如果你的第三方 VNC 客户端在 26.6 之后失效了，那是一个已有其他人反馈过的已知模式。你不是个例，也大概率不是配置出了问题。
• 如果它失效了，不要指望 26.6.1 能修好。 这次更新处理的是一个安全问题。没有任何迹象表明它会恢复第三方客户端兼容性，它也可能不会。
• 如果你依赖第三方 VNC 客户端连接某台 Mac，在更新一台你不方便物理接触的机器之前，先向客户端厂商确认 macOS 26.6 和 26.6.1 的兼容性。
• 以上任何一条都不构成跳过更新的理由。 如果要在一个能用的第三方 VNC 客户端和一个已修补的身份验证绕过之间选择，请选补丁，另找连接方式。

常见问题排查

macOS Tahoe 26.6.1 没有出现在「软件更新」中

问题： 软件更新显示你的 Mac 在 26.6 上已是最新，26.6.1 遍寻不见，尽管它已在 8 月 6 日发布。发布当天有多位 M4 和 M5 Mac 用户反馈了这个情况。

解决： 这几乎总是分批推送而非故障。苹果会在数小时到数天内分批把小版本更新推送给不同机器子集。彻底退出「系统设置」再重新打开，因为软件更新面板会缓存结果。然后在终端运行 softwareupdate --list，它会直接查询苹果服务器，有时能返回界面尚未呈现的更新。如果你的 Mac 处于受管状态，运行 sudo profiles status -type enrollment 确认是否有 MDM 按策略延后更新，若是，时间表由 IT 团队掌握。8 月 6 日反馈的案例都在一天内自行恢复。如果你急需且等不了，完整独立安装器可以绕过分批推送，代价是下载体积大得多。

更新下载完成但始终装不完

问题： 下载完成，或看起来完成了，然后 Mac 就长时间停在「正在准备」或进度条不动的状态，看不到任何进展。

解决： 先给它比你觉得合理更长的时间，因为在磁盘接近写满的繁忙机器上，准备阶段确实可能耗时十五分钟以上。如果确实卡死了，检查可用空间，因为 macOS 展开和暂存安装器需要的余量远大于下载体积。重启 Mac 再试一次，这会清除不完整或损坏的下载。如果第二次仍然失败，删除缓存的更新，让它重新下载。我们的 macOS 更新卡住与失败指南 涵盖了完整流程，包括如何安全清除更新缓存，以及 Mac 反复重启进入安装失败循环时该怎么办。

更新后屏幕共享不能用了

问题： 你安装了 26.6.1，之后无法再通过屏幕共享连接到某台 Mac 或从某台 Mac 连出。

解决： 先确认到底启用了什么。打开系统设置 → 通用 → 共享，同时查看「屏幕共享」行和「远程管理」行，因为二者互斥，而一次更新或一次策略变更可能让状态和你记忆中的不一样。确认发起连接的账户在允许用户列表中，而不是依赖可能已被改动的「所有用户」。如果你是从另一台 Mac 通过「屏幕共享」或访达连接，先在本地网络上测试，以便区分问题出在服务上还是通往它的链路上。如果你是从第三方 VNC 客户端连接，请参见上文那一节，因为有用户反馈从 26.6 开始出现第三方客户端故障，该行为未经证实但确有反馈。最后，在目标 Mac 上运行 sudo lsof -i :5900，确认确实有东西在监听。

远程管理关不掉

问题： 你在「共享」面板中关闭远程管理，它却自己又打开了；或者开关是灰色的，根本无法更改。

解决： 这是受管 Mac 的典型特征。由 MDM 下发的配置描述文件可以强制启用远程管理，并在你本地改动后重新应用。运行 sudo profiles status -type enrollment 确认这台 Mac 是否存在活跃的 MDM 注册，再运行 sudo profiles list 查看安装了哪些描述文件。如果这台 Mac 属于你的雇主或学校，不要试图绕过。联系管理机队的人，因为移除管理可能违反政策，而且大概率几分钟内就会被恢复。如果这台 Mac 确实是私人的，而你发现了一个自己未授权的注册，那是一个值得上报的严重发现；对个人机器来说，最稳妥的处理是备份数据后全新安装系统。

你不确定自己的 Mac 是否被入侵过

问题： 你有一台长期开机、开着屏幕共享、连在共享网络上的 Mac，你想知道有没有人真的用这个漏洞攻击过你。

解决： 说实话：没有可靠的消费级方法能回答这个问题。苹果没有公布 CVE-2026-65400 的入侵指标，机制未公开，而一个通过屏幕共享完成身份验证的攻击者所产生的日志活动，大体上和一次合法会话没什么两样。在这里，没有证据确实不等于证据表明没有。

在明确这些局限的前提下，你仍然可以检查的东西有：打开「控制台」，查看你关心的那段时间前后的系统日志，按屏幕共享活动过滤，但要注意 macOS 的日志保留期有限，较早的记录可能已经不存在。在系统设置的「用户与群组」中检查是否有你不认识的账户。检查「共享」面板的允许用户列表中是否有你没添加过的条目。查看「登录项」和「后台项目」中是否有陌生条目。运行 sudo profiles list 检查有没有你没安装过的配置描述文件。查看路由器的已连接设备列表，如果它保留日志，也一并查看日志。

如果你有具体理由相信某台机器被他人访问过，而且它上面有敏感内容，那么唯一真正可靠的补救是全新安装 macOS，然后恢复数据而不是恢复整个系统备份，同时更改在那台机器上登录过的账户密码。这是很重的应对方式，对大多数人来说并不必要。苹果表示这个问题没有已知的被利用记录。

常见问题

如果屏幕共享是关闭的，我还需要安装 macOS Tahoe 26.6.1 吗？

需要。苹果从未说明 CVE-2026-65400 是否必须在屏幕共享开启时才能被利用，heise 也报道说这一点仍不明确。既然前提条件未知，而更新的代价只是重启一次，那就装上。不要把关闭的开关当作你安全的确证。

用最简单的话说，CVE-2026-65400 是什么？

它是 macOS 屏幕共享服务中的一个身份验证绕过漏洞。苹果的表述是，网络上的攻击者可能无需有效凭据即可通过屏幕共享的身份验证。实际含义是，同一网络上的人有可能在不知道密码的情况下拿到一个屏幕共享会话。苹果通过改进状态管理修复了它。

这个漏洞真的被利用过吗？

苹果表示没有已知的在野利用。这是苹果在没有实际攻击证据时的标准措辞，而当它知晓某个问题正被主动利用时，会明确标注出来。这里没有该标注，是有意义的信号，但并不保证从未有人用过它。

有人能利用这个漏洞从互联网攻击我的 Mac 吗？

在正常情况下不能。heise 指出，如果 Mac 位于本地网络内且路由器上没有转发相关端口，就无法从互联网发起远程屏幕共享。现实场景是攻击者已经处在你的网段上：共享的办公室 Wi-Fi、宿舍、酒店、咖啡馆，或者你自己网络中一台已被攻陷的设备。

26.6.1 增加了新功能或更新了 Safari 吗？

没有。没有任何新功能。Safari 仍是 26.6 版本，本次更新不会升级它。系统固件同样保持 18000.161.9 不变。macOS Tahoe 26.6.1 的内部版本号是 25G76，只包含一个安全修复，这也是它没有测试版种子推送、发行说明只有一行的原因。

如果我用的是 macOS Sonoma 或 Sequoia 怎么办？

苹果回移了相同的修复。请安装 macOS Sequoia 15.7.9（版本 24G830）或 macOS Sonoma 14.8.9（版本 23J631）。你获得的是同等保护，而不是缩水版本。就这个问题而言，留在旧版 macOS 没有问题，只要你及时装上对应的补丁。

结论

macOS Tahoe 26.6.1 是一个只带一条修复的小更新，而苹果发布它的方式，比发行说明本身说明的更多。没有测试版种子推送、没有新功能，加上同一天回移到 Sequoia 15.7.9 和 Sonoma 14.8.9，都指向一个想尽快在所有版本上关闭这个问题的厂商。CVE-2026-65400 让本地网络上的攻击者无需有效凭据即可通过屏幕共享的身份验证，苹果通过改进状态管理修复了它。这就是公开记录已确认的全部范围。

这份记录中的空白是「开启还是关闭」这个问题，它值得被搁在那里而不是用假设去填平。苹果没有说服务是否必须处于运行状态。heise 说不明确。屏幕共享默认关闭，这很容易让人得出「我从未暴露」的结论，而这个结论没有任何已公开材料支持。更详细的机制说法在无人佐证的情况下流传，不应被用来决定是否更新。

本周装上 26.6.1，或者 15.7.9、14.8.9。然后花十分钟进入系统设置 → 通用 → 共享，把三个远程访问开关都看一遍，而不是只看一个。确认屏幕共享和远程管理在你不需要时都是关闭的，单独检查远程登录，把所有「所有用户」的设置替换成明确名单，并打开防火墙。如果你确实需要远程访问一台 Mac，请通过 VPN 或覆盖网络连接，而不是把它暴露在机器碰巧所处的任何网络上，也永远不要转发 5900 端口。这样的配置本可以让这个 CVE 对你而言基本无关痛痒，对下一个也一样。

延伸阅读：macOS Tahoe 26.6 发布：新变化、安全修复与更新指南