随着 AI 漏洞猎手挤爆审查队列，Apple 与 Google 的安全差距正在扩大

在 AI 漏洞猎手暴露出 Apple 漏洞受理流程的弱点后，Apple 与 Google 的安全策略进入了新阶段。据报道，机器生成的发现结果令审查能力不堪重负，Apple 因而限制了活跃提交数量。

眼前的问题并不只是误报。意大利安全公司 Bynario 的研究人员表示，他们的自动化工作流在大量发现结果中识别出一个真实的 macOS 授权漏洞。该公司最终验证出一条攻击路径，可借此以 root 权限创建文件。

Apple 于 2026 年 7 月修复了这一漏洞。然而，此事暴露出从发现漏洞到由可信人工评估之间更广泛的运营缺口。Google 多年来一直围绕 Project Zero 及其 AI 系统 Big Sleep 构建这一验证层。

这正是核心逆转。人们原本预期 AI 能帮助厂商检查更多代码，但它也让外部研究人员生成报告的速度超过厂商处理报告的速度。瓶颈已从发现转向验证、优先级划分和补丁交付。

对 Apple 而言，这种转变带来的压力不止于单个 macOS 缺陷。其安全项目必须在不阻碍合法报告的前提下，区分有价值的 AI 辅助研究与看似合理但错误的提交。Google 的做法提供了一种模式，尽管它仍高度依赖专家审查。

一个已修复的 Mac 漏洞暴露出更大的受理问题

重要变化在于，自动化发现与原本针对人工报告量设计的漏洞处理流程发生了碰撞。

Bynario 于 7 月 29 日发布了技术说明，距 Apple 发布相关更新仅两天。研究人员在 macOS Screen Sharing 中发现两个相关的授权问题，并将其归入 CVE-2026-43760。

该漏洞影响了 Virtual Network Computing（VNC）使用的一条旧版认证路径。VNC 是一种允许远程用户查看和控制另一台电脑屏幕的协议。

利用该漏洞需要满足若干条件。必须启用 Screen Sharing 或 Remote Management；还需配置旧版 VNC 密码选项，且攻击者必须掌握该密码。

这些要求使该漏洞的适用范围小于未经认证、零点击攻击，但并未削弱其重要性。VNC 密码本应只用于授权屏幕控制，而非获得特权文件系统访问权限。

研究人员发现，macOS 对原生 Apple 认证和旧版 VNC 认证的处理方式不同。原生会话会将活动关联到已识别的 macOS 用户，而旧版路径不会提供相同的用户身份信息。

当该身份缺失时，文件复制辅助程序仍保留 root 权限。因此，远程查看者可以请求受保护文件，或在特权位置创建由攻击者控制的文件。

在这篇 macOS exploit analysis 中，Bynario 描述了如何将策略文件放入受保护的配置目录。该文件可启用无需密码的管理命令，并支持演示远程 root 命令执行。

研究人员在启用 System Integrity Protection 的近期 Apple silicon 系统上测试了这一行为。该漏洞并未绕过 Apple 的内存保护机制，因为它属于授权错误，而非内存破坏利用。

这一区别很重要。现代防御措施可以让缓冲区溢出和伪造指针更难被利用，但无法阻止合法系统组件以错误身份执行本已获授权的操作。

Apple 的公告采用了更为克制的表述，称该问题可能导致访问敏感用户数据。Bynario 则认为，这一描述未能充分体现特权文件创建的完整影响。

公开说明对严重程度的判断也不同。Apple 的公告和研究人员的评估采用了不同评分与假设。这种分歧再次说明，验证不能只是接受自动化标签。

Apple 于 7 月 27 日在 macOS Tahoe 26.6 和 Sonoma 14.8.8 中修复了该问题。该公司的 security update 列出了为本次发布中修复的多项漏洞作出贡献的外部研究人员。

对用户而言，实际应对措施很直接：安装当前的 macOS 更新。无法更新的组织应禁用旧版 VNC 密码选项，或在不需要时关闭 Screen Sharing。

更大的故事始于补丁发布之前。有报告称，Bynario 的研究人员已在数周内提交数十项发现。随后，对活跃报告设置的上限阻止他们立即提交另一项可能严重的问题。

Apple 后来联系了研究人员并调查了该漏洞。这一行动促成了补丁，但它依赖于常规受理流程之外的例外。可扩展的安全项目不能依赖于在队列停止接收工作后，研究人员才获得个别关注。

为什么 AI 漏洞猎手正压垮人工审查

AI 漏洞猎手改变发现环节经济性的速度，快于它们改善验证环节经济性的速度。

传统漏洞研究需要付出高昂的人力时间成本。研究人员要研究代码库、提出假设、进行测试、排除错误线索，并撰写可复现的报告。

AI 可以压缩这一过程中的部分工作。模型能够搜索可疑模式、比较类似代码路径、生成测试用例，并提示授权假设可能失效的位置。

当系统能够产出证据时，这种规模化能力很有价值。但当代理将每个不确定的模式都转化为信心十足的报告时，成本就会迅速上升。

安全团队仍必须复现行为、确定受影响版本、评估利用条件、分配责任归属并协调修复。由模型生成的精致说明并不能减少这些义务。

Apple 自己的 reporting guidelines 反映了这种张力。该指南不鼓励冗长的 AI 生成描述，并排除缺乏适当验证的理论性 AI 发现。

这些规则是合理的。厂商需要可复现的证据，而不是数页推测性推理。然而，当一名研究人员同时提交薄弱线索和高影响发现时，报告数量限制是一种过于粗糙的控制手段。

Bynario 案例展示了 AI 生成量与 AI 辅助安全研究之间的区别。该公司表示，其系统发现了凭据不匹配问题，但人类从头到尾验证了结果。

这种验证包括负面对照。在原生认证下，受保护操作只能以普通用户权限失败；而在旧版路径下，类似操作则以 root 权限成功。

这种差异化测试远比模型的置信度评分更有价值。它证明了当一条认证路径发生变化时，安全结果也随之改变。

这一发现还经受了利用测试。研究人员从异常的权限差异出发，推进到特权文件创建，再到命令执行。每一步都为下一步提供了具体证据。

低质量报告往往缺少这条证据链。它可能识别出可疑代码，却没有展示可达性；可能描述一次崩溃，却未证明安全影响；或者假定攻击者能够控制实际上仍处于内部的数据。

生成式模型会让这类报告看起来已完成。它们可以在底层主张尚未被证明之前，就提供漏洞分类、攻击叙述和修复建议语言。

这造成了不对称的工作量。生成十份看似合理的报告所需时间，可能少于仔细证伪其中一份的时间。若报告者不验证其发现，接收方就要承担大部分成本。

因此，Apple 的 AI 安全运营面临两项相关挑战。公司需要更好的受理控制机制，也需要为持续证明工作可靠的研究人员提供通道。

信誉系统可以有所帮助。经过验证的报告历史、完整的概念验证、确定性的复现步骤，以及清晰的受影响版本数据，都应提高报告的优先级。

机器辅助分流也能比较提交内容、识别重复项并测试基本主张。然而，使用另一个模型去判断未经支持的模型输出，可能放大共同错误。

最强的方法是将自动化过滤与证伪结合起来。分流系统不应只判断报告听起来是否可信，而应主动测试那些能够证明其为假的条件。

这需要访问构建版本、日志、配置状态和受控测试环境，也需要理解报告所声称跨越的安全边界的人工审查人员。

随着生成发现结果的成本持续下降，受理挑战还将不断加剧。将每份提交一视同仁的厂商会被噪音淹没；不加区分地阻止自动化的厂商则会错过真实漏洞。

Apple 与 Google 的做法在验证层出现分化

Apple 与 Google 的差异，与其说在于是否能使用 AI 模型，不如说在于各自如何组织专家验证。

Google 于 2014 年成立 Project Zero，作为专注于严重漏洞的专业研究团队。这种制度性经验让 Google 已具备选择目标、复现发现结果和披露缺陷的既有流程。

Big Sleep 将这种安全经验与 Google DeepMind 的模型研究结合起来。该系统旨在调查软件、测试假设，并生成经过专家审查的报告。

2025 年 8 月，Google 表示 Big Sleep 已在开源项目中发现并复现了 20 个漏洞。据报道，受影响的软件包括广泛使用的媒体和图像处理组件。

由于修复工作仍在进行中，Google 没有立即披露技术细节。一名发言人还表示，每个问题在报告前都经过人类专家审查，尽管系统自主发现并复现了这些漏洞。

这一人工检查点正是 Big Sleep results 的关键部分。它并未让流程变得完全自主，却能保护维护者免于接收未经处理的模型输出。

Google Big Sleep 还在一个了解披露期限和下游依赖关系的团队中运作。其发现不会在缺乏背景信息的情况下，直接丢进无关厂商的队列。

Project Zero 的披露系统带来了另一项优势。Google 会跟踪问题何时报送、截止期限何时到期，以及受影响用户何时真正获得补丁。

其 disclosure policy 采用标准期限，同时承认上游修复与最终用户设备实际安装之间存在补丁缺口。Big Sleep 参与同一框架。

Apple 自身也拥有雄厚的安全工程资源。它维护平台加固功能、安全研究设备计划和公开悬赏流程。

Apple 的 bounty program 同样要求研究人员提供技术说明和概念验证。其较新的目标标记为证明某些利用条件已达成提供了客观方法。

这些投资意味着 Apple 并未忽视漏洞研究。这里暴露出的缺口，在于面对来自组织外部的自动化提交时，其处理能力与信任机制不足。

Google 同时掌控 AI 系统及审核其输出的专家团队。Apple 则接收来自众多独立研究人员的报告，他们使用不同的模型、提示词、工具与验证标准。

这使接收环节更加困难。Apple 无法假定外部模型代理遵循 Project Zero 的方法，也无法假定报告者在提交前已测试相关主张。

不过，Apple 对其报告渠道的设计负有责任。如果经过验证的研究人员因先前报告仍处于开放状态而无法提交严重问题，那么该系统优化的就是队列规模，而非安全影响。

成熟的计划需要多条通道。记录最少的自动化线索可以进入低优先级队列，而具备可重复证据的已展示漏洞利用则应立即获得人工关注。

Apple 还需要在不鼓励批量提交的前提下，为可信报告者提升容量。更高的配额应基于经过验证的质量，而不应只是因为有人请求更多空间。

Google 的做法也并非不会出错。其系统依赖成本高昂的专家监督，而首批公开结果尚未证明 Big Sleep 在专有平台上的表现如何。

目前同样不清楚，该系统在得出所报告的发现前，淘汰了多少候选项。缺少这一分母，外部人士无法计算其误报率或审核成本。

其中有价值的启示更为有限：当模型处于由承担责任的专家把关的证据流程中时，AI 发现能力最为有效。Apple 面临的挑战，是在开放的外部报告计划中复现这一标准。

安全取舍在于速度与信号质量

只有当厂商能在攻击者使用同样工具之前，将更多发现转化为经过验证的修复措施时，更多发现才会提升安全性。

AI 辅助漏洞发现会给披露流程的双方都带来压力。研究人员能够调查更多代码，而恶意行为者也能在同一软件中搜寻可被利用的错误。

Google 在 2026 年 5 月表示，其已阻止一起涉及 AI 辅助零日漏洞发现的犯罪行动。该公司未披露受影响的产品，也未透露攻击者据称使用的模型。

根据这份 AI attack account，该漏洞可绕过一款系统管理产品的双因素认证。Google 表示，其在造成损害前已通知厂商和执法部门。

细节仍然有限，因此该事件尚不能证明模型完成了多少工作。但它确实表明，报告处理延迟如今带来的风险更高。

在队列中等待的缺陷并非静止不变。另一支研究团队、犯罪团伙或国家支持的行动者都可能独立发现它。更快的搜索会增加这种碰撞发生的可能性。

Apple 无法通过接收每一份自动化提交来解决问题。那样会消耗审核人员的时间，并延误最具后果性的报告。

它同样无法通过压制机器辅助研究来解决问题。Bynario 漏洞表明，有效的授权缺陷可以从自动化工作流中出现，并经受严格的人类测试。

正确的取舍是选择性提速。证据充分的报告需要快速升级处理，而不完整的主张则应在提交给高级工程师之前接受成本更低的自动化质询。

一份报告应明确受影响的构建版本、所需配置、攻击者前置条件、观察到的结果、预期结果以及可重复的测试。安全影响应由证据推导，而非由模型生成的猜测得出。

对于权限问题，这可能意味着在受控操作期间记录进程身份。对于内存缺陷，则可能包括 sanitizer 跟踪记录和最小复现程序。

厂商可以围绕这些要求发布结构化提交模板。机器可读的证据将帮助自动化分诊测试报告，而不是将流畅的文字视为证明。

研究人员同样承担责任。发送数十份不确定的发现，会将验证成本转嫁给厂商，并削弱每一次后续提交的信任度。

AI 安全工具应在生成报告前包含证伪阶段。代理应搜索自己遗漏的访问控制措施，测试已修复和未修复的构建版本，并验证所声称的攻击者是否控制每一项必要输入。

对于高影响主张，人工审核必须保持强制性。审核者应独立复现问题，并检查测试环境是否引入了人为条件。

这一要求不会降低 AI 的价值。它将模型引导至规模化更有帮助的重复性调查工作，同时将责任保留给具名研究人员。

公众也应避免把漏洞数量当作排行榜。二十个被接受的缺陷，并不必然比一条经过验证的攻击链更重要。

数量可能会奖励浅层扫描和重复报告。更好的衡量指标包括验证时间、确认的严重性、补丁交付、误报负担以及用户对修复措施的采用情况。

Apple 的报告上限只涉及其中一项指标。它可以减少开放提交的数量，但无法证明最危险的报告能迅速到达正确的工程师手中。

更好的分诊将比更高的赏金更重要

AI 安全领域的下一项竞争优势，将是从机器发现到人工验证修复的可信流程。

Apple 已为高级研究提供奖励，但金钱本身无法修复拥堵的接收流程。研究人员需要确信，一项证据充分的发现会被阅读、复现并正确转交。

第一项改进应是基于证据的优先排序。可运行的概念验证、明确的前置条件和经过验证的影响，应比提交顺序更重要。

第二项应是分级访问。此前工作促成已确认修复的研究人员，可以获得更大的活跃报告额度和直接的技术升级通道。

第三项应是透明的状态反馈。长期没有实质性反馈会鼓励重复发送消息、过早披露，并造成报告是否已到达正确团队的不确定性。

Apple 的目标标记概念正指向这一方向。客观信号可减少有关可利用性的争议，并奖励展示出实质性控制能力的研究人员。

不过，标记仅覆盖已定义类别的行为。新型逻辑缺陷可能并不符合预先选择的目标，尤其是在漏洞跨越多个可信组件时。

CVE-2026-43760 说明了这种困难。每一次文件复制操作单独来看都运行正常。错误源于认证身份、辅助程序权限和文件系统访问之间的交互方式。

这类漏洞需要语义推理。语义分析考察的是系统行为是否符合其安全意图，而不只是代码是否崩溃。

AI 模型可以提供帮助，因为它们能够追踪函数和组件之间的关系。它们也可能虚构并不存在的关系，因此可执行验证至关重要。

强大的分诊平台会保留模型的推理过程，同时将其与证据分开。审核人员可以看到哪些主张已被观察到、哪些是推断得出、哪些仍未经测试。

团队可以将同一原则应用于内部工程记录。可搜索的 technical knowledge base 有助于关联过去的缺陷、设计假设、测试结果和责任归属，同时不会将生成式摘要视为权威依据。

当一份新报告与早期问题相似时，这类背景信息至关重要。系统应识别相关组件和修复措施，同时保留对原始工件的访问。

Apple 也可以在不暴露漏洞的情况下发布汇总处理数据。有用的指标包括验证时间中位数、重复率、补充信息请求，以及因缺乏支持而关闭的报告占比。

这类报告能够阐明，AI 提交主要是噪音，还是处理能力未能跟上有效研究的步伐。

Google 也应面对同样的透明度标准。仅公开成功发现而不公布审核成本，会让自动化安全研究呈现出不完整的图景。

这种比较不应演变成 Google 已解决 AI 安全问题的主张。Big Sleep 的人工审核是一项优势，但也证明了自主漏洞研究仍需要专家控制。

Apple 无需复制 Google 的组织结构也能迎头赶上。它需要一个报告系统，即使拟议发现变得大量涌现，仍能让已展示的证据保持稀缺且有价值。

三个信号将显示 Apple 是否正在追赶

未来几个月将揭示，Apple 是将此事视为暂时的队列问题，还是视为安全研究的永久性变化。

第一个信号是 Apple 对提交控制机制的调整。有意义的更新应将经过验证的研究人员和可复现的漏洞利用，与未经测试的自动化发现区分开来。

单纯提高上限还不够。它会增加数量，却不会改善报告获得关注的先后顺序。

基于证据的升级处理将强化 Apple 正在适应的判断。若持续依赖个人外联，则表明流程依然脆弱。

第二个信号是 Apple 在未来安全公告中如何对待 AI 辅助发现。明确的署名、准确的影响描述和一致的修复细节，将表明自动化不会降低一份报告的地位。

应关注类似围绕 CVE-2026-43760 的分歧。不同的严重性判断很正常，但公告与已展示漏洞利用之间无法解释的差距，会让防御者更难进行优先级排序。

更完整的描述并不要求公开武器化细节。厂商可以说明前置条件和影响，同时不披露会帮助攻击者的指引。

第三个信号是 Google Big Sleep 及类似系统在首批公开成果之外的表现。已确认的逻辑缺陷、较低的误报率和高效的补丁协调，将加强 Google 的模式。

大量低质量报告则会削弱它。如果结果依赖未公开的人力投入，却被呈现为自主发现，也同样如此。

这些信号对企业采购方很重要，因为漏洞处理会影响每一支设备队伍。当一份有效报告无法进入审核，或已发布的修复仍未安装时，安全功能的价值就十分有限。

开发者也应关注不断变化的证据标准。AI 可以帮助检查代码，但维护者将越来越要求可复现测试，才会在报告上投入时间。

安全研究人员面临同样的选择。他们可以利用模型提高提交量，也可以用模型构建更有力的实验，使每一份提交都更难被驳回。

因此，Apple 与 Google 的竞争并非比拼谁能生成最多漏洞主张，而是比拼谁能将不确定的机器输出转化为可靠的防御行动。

这场竞争已经来到普通软件团队身边。审查你的漏洞接收规则，定义升级处理所需的证据，并测试一份高影响报告能否绕过常规队列限制。如果不能，下一项有效的 AI 辅助发现可能会先暴露流程问题，然后才暴露代码问题。