最近几周，我跟几位 Mac 管理员聊天时，大家都在讨论 Netskope Threat Labs 发布的一份关于 macOS ClickFix 新攻击活动的报告。这个攻击手法既聪明又可怕，属于典型的社会工程学攻击，它也清楚地说明了为什么传统的 90 天软件更新延迟机制该被淘汰了——不管是 Apple 自己动手，还是 IT 部门来改。
ClickFix 攻击是怎么回事
ClickFix 的套路是诱骗用户把恶意脚本复制粘贴到 Terminal 里运行。他们常用假的 CAPTCHA 验证页面或假的浏览器更新提示来骗人。用户一旦粘贴并执行脚本，就会弹出一个 AppleScript 对话框，看起来跟 macOS 原生系统提示一模一样。
这个提示会不断要求输入用户密码，而且没有关闭按钮，只能一直点下去。密码一旦被拿到，恶意软件就会偷走整个 macOS 钥匙串数据库，还会顺手抓取 Safari、Chrome 等浏览器里的实时会话 cookie。偷到实时会话 cookie 是最致命的，因为它能让攻击者直接绕过多因素认证。
为什么更新延迟现在成了隐患
Apple 已经在针对这类攻击做出反击。在 macOS Sequoia 和 macOS Tahoe 26.4 版本里，Apple 加入了原生的 Terminal 安全警告功能。当用户试图从不受信任的来源往 Terminal 里粘贴危险命令时，这个功能会及时提醒用户，从而有效阻止 ClickFix 攻击。
这也让我想到了核心问题。过去，Apple 允许 IT 管理员通过设备管理平台把 macOS 更新延迟最多 90 天。很多年里，这都被视为 IT 行业的标准做法，能让团队有时间测试内部应用、检查兼容性，确保全公司设备平稳升级。
但现在 AI 时代威胁变化太快，三个月的延迟已经跟不上节奏了。如果你的公司还在把更新延迟到最长 90 天，那用户就会错过操作系统层面的关键防护，比如新的 Terminal 粘贴警告。整整三个月时间，员工都暴露在社会工程学攻击之下，而这些攻击本来只需及时更新系统就能轻松挡住。
我们的看法
也许 Apple 该重新考虑管理框架，把软件更新最大延迟时间从 90 天正式缩短到 30-45 天。现实情况是，如果某个企业软件供应商在新 macOS 版本发布后 30 天内还没适配好，那问题出在供应商身上，而不是 Apple。
就算 Apple 继续保留 90 天的选项，IT 团队也应该主动收紧内部政策。把最大延迟控制在 30 天，既能留出足够时间测试应用兼容性，又能及时保护公司数据免受新威胁攻击。让整个设备群暴露整整一个季度，代价实在太大了。
