海外研究团队宣布了一个问题，即 Mac 上安装的应用程序内容可以被静默替换。即使更换后，该应用程序仍将继续作为合法应用程序运行，因此不会显示任何警告。然而，这种方法之所以有效，是因为在您允许 Mac 被入侵之后是。 Apple 并未承认此问题是一个漏洞，因此决定不修复它。我们在哪里划清界限？
目次
目标是从网络获取并启动一次的应用程序。
只有有限数量的应用程序可以使用此技巧。目标是从 App Store 以外的来源获取并至少启动一次的应用程序是。 Mac App Store 中的应用程序归系统所有，因此无法使用登录用户权限重写。最重要的条件是攻击者已经能够以用户权限执行代码。
该机制本身很简单。据报道，应用程序一旦归档并重新部署，即使内容发生变化，也不会进行重新验证。在研究团队的演示中，替换后的应用程序作为合法应用程序启动，并且权限对话框按原样显示。
苹果决定无需修改的两个原因
苹果收到报告后得出结论，保护机制没有被规避。我们做出决定的基础是 Gatekeeper 的设计理念和有关访问权限的责任定位。
Gatekeeper 是 Apple 的官方安全功能，可在首次启动之前验证通过网络获取的应用程序。苹果官方安全指南解释说，首次打开下载的软件时会要求用户批准。换句话说网守监视直到第一次启动，并且不负责此后继续监控该应用程序。由于该技术是在通过初步验证后发生的，因此它位于 Apple 的保护范围之外。
另一个轴是应用程序权限管理机制（TCC）是。即使替换的应用程序显示对话框，用户最终也必须授予权限。苹果将此视为社会工程问题，而不是规避保护机制。
这个判断是苹果加强 macOS 防御的努力这与近年来攻击从利用软件缺陷转向欺骗用户本身的方向是一致的。从苹果公司的角度来看，这份报告可能属于后一类。
另一方面，研究团队反驳了这种安排。需要指出的是，由于 macOS 本身会检测更改并重新请求权限，因此检测更改的机制已经就位。如果是这种情况，则争论是只要捆绑包发生变化就应该重新验证签名。
同一研究小组之前的报告用了5个月的时间进行了修改。
同一研究团队此前发布的一份报告有助于理解苹果的底线。它与 macOS 存档实用程序有关，它允许您一次性绕过应用程序沙箱和 TCC 等保护。该问题于 2025 年 10 月报告，并在 2026 年 3 月发布的 macOS 26.4 中修复。
您可以滚动
| 之前的报告 | 这份报告 | |
|---|---|---|
| 绕过保护 | 沙箱 TCC 应用程序保护 | 无（苹果的意见） |
| 用户交互 | 几乎没有必要 | 需要权限对话框批准 |
| 苹果的回应 | 报告后5个多月更正 | 判断不需要修改 |
如果把这两个案例放在一起，你就能看到苹果的判断标准。分割线是是保护机制本身被破坏还是用户的认可通过了？这是一点。如果是前者，即使需要时间也会被修复，如果是后者，就会被视为社会工程。
这个标准本身是有道理的。然而，从用户的角度来看，是否发生损坏与是否在标准之内或之外无关。即使在之前的报告中，也花了五个多月的时间才解决这个问题。即使苹果承认存在漏洞，也不意味着它始终受到保护。
入侵途径为Homebrew和AI代理
从目前的情况来看，攻击想要成功似乎有很大的障碍。然而，研究小组引用的入侵路线绝不是独一无二的。它们的共同点是用户很难意识到他们正在做危险的事情。避开可疑站点的传统思维方式无法阻止这两种途径。
通过包管理器引入时
研究团队将通过 npm 和 Homebrew 进行的供应链攻击列为媒介之一。这是开发工具或库的分发源被污染并且代码在用户不知情的情况下执行的情况。
如果您在 Mac 上进行开发，这些命令将每天使用。日常工作流程线可以作为切入点。这似乎是本报告中真正争论的焦点。
当人工智能代理代表您执行操作时
提到的另一件事是立即注入人工智能代理。这是指使代理在读取外部文本时执行非预期命令的技术。
围绕 Apple Intelligence 的安全研究指出然而，讨论了人工智能在接近个人信息的领域工作的风险。您给予代理的控制权越多，这些路线的可能性就越大。
除了与 App Store 绑定之外，您还可以采取其他措施
最好的解决方法是仅使用 Mac App Store 中的应用程序。然而，许多主要应用程序并未在那里分发，这使得它不是一个现实的选择。
你实际可以做的就是将获取途径限制在开发商的官方网站上。避免在搜索结果中出现广告空间并通过聚合网站下载链接会更安全。使用包管理器或脚本时，最好检查分发源及其用途。
而针对这种技术最直接有效的就是如果在意外时间提出许可请求，请不要批准。这就是决定。如果熟悉的应用程序突然要求访问您的桌面或文档文件夹，请停止。此步骤是阻止某人伪装成合法应用程序的最后障碍。
只要苹果不修复它，用户就有责任保护这个屏障。