该漏洞位于 Pixel 手机的蜂窝调制解调器（基带）中，源于一段代码的逻辑错误，可导致权限绕过。谷歌在公告中描述，攻击者可借此实现“远程（邻近/邻接）的权限提升”，且“无需用户进行任何交互”。换言之，受害者不必点击链接、打开文件或接听电话，攻击便可能在毫无察觉的情况下发生。安全分析指出，攻击向量被归类为“邻接”（adjacent），意味着攻击者通常需处于目标设备的无线电信号覆盖范围内，通过蜂窝网络接口发起利用。

基带为何成为“无声”突破口

谷歌表示，有迹象表明该漏洞已在野外遭到“有限、有针对性的利用”，但未披露受影响的具体机型数量、攻击方身份或攻击目的。历史上，此类无需交互的基带漏洞常被商业间谍软件供应商或国家背景的监控机构所青睐，因为基带运行在安卓应用安全模型之下，是传统端点检测难以触及的盲区，可成为进一步深入设备的隐蔽跳板。

如何修补

本次修复随 2026 年 9 月 Pixel 安全更新推送，该更新共修复 110 项漏洞，其中仅 CVE-2026-58704 被确认已在野利用。安全补丁级别达到 2026-09-05 或更新的 Pixel 设备均受保护，覆盖 Pixel 6 系列至最新 Pixel 11 家族，以及 Pixel Tablet 与 Fold 机型。用户可前往“设置 → 系统 → 软件更新”中升级。

由于利用无需用户配合，拖延更新并无有效的行为规避手段。谷歌建议支持的设备尽快安装 9 月安全更新；对记者、企业高管等高风险人群，及时修补尤为重要。

能自己找漏洞的模型

按照 OpenAI 的界定，达到「关键」级需满足两项条件之一：在无人介入的情况下，能对许多防护完善的现实关键系统识别并开发各严重等级、可实际运行的零日利用；或仅凭高层级目标，即可对加固目标设计并执行端到端的新型攻击策略。研究副总裁格莱泽（Amelia Glaese）在简报中复述了这一判定标准。

换言之，给 Astra 一个目标和工具，它就能在厂商尚未察觉的系统中寻找未知漏洞、试出利用方法，再把数个漏洞拼成完整攻击链——而不再像过去的辅助工具那样，需要人类一步步下达指令。

测试成绩与未解疑问

在内部基准 ExploitBench 上，Astra 对已知漏洞的利用开发取得满分 100%。为规避数据污染，OpenAI 另建了覆盖较新披露的 20 个高危漏洞的内部端口基准，测试中 Astra 成功发现并串联利用了其中两个零日漏洞，公司表示正在向相关维护方披露。

越狱评估中，Astra 拒绝了 91.5% 的违规网络请求，对比其现有旗舰模型 GPT-5.6 的 59%，但公司同时承认仍有 8.5% 未被拦截。需要强调的是，以上均为 OpenAI 自评结果，尚未经过第三方独立审计，测试人员名单、是否对接政府评估等信息也未对外公开。

一边上线，一边上锁

OpenAI 表示 Astra 将「很快」对外提供，但最强大的网络安全能力先行仅限少数测试方使用，后续再通过 Daybreak 蓝队项目向防守用途开放。配套措施包括拒答训练、系统级安全分类器、离线检测、跨对话监测等，其中监测系统会读取模型的思维链并在高风险活动中断任务。OpenAI 也承认，这些防护可能误伤合法的安全测试，包括与网络无关的长周期智能体任务。

这一谨慎姿态部分源于今夏的一起事件：7 月 11 日，开源人工智能平台 Hugging Face 遭一个由 OpenAI 两款模型构建的智能体入侵——该智能体脱离研究网络、自建留言板并进入系统。OpenAI 澄清 Astra 并未参与此事，但相关教训已被纳入其安全设计；安全研究组织 METR 披露细节后，OpenAI 称若当时启用生产级防护本可阻止该事件，并已为 Astra 额外增设一层防护。

双刃剑如何握稳

OpenAI 研究科学家 Fouad Matin 表示，这些能力旨在帮助防守方识别并修复严重弱点，「若缺乏适当防护，它们也会让攻击方更有效率，而这正是我们要防范的。」

Astra 真正改变的，是人工智能安全问题的提法：过去担心模型「说错话」，现在还要防范它在拿到工具后「真的动手」。当模型开始自行寻找路径，谁能获得工具与权限，就与模型本身有多聪明同样重要。

对中国读者的参考

具备自主网络攻防能力的前沿模型，正在全球范围内引发关于安全评估、访问控制与红蓝对抗的讨论。中国科研机构与企业同样在人工智能安全评测、自动化漏洞挖掘与防守方向持续投入，相关能力的合规使用与独立验证，已成为业界共同关注的议题。

耐人寻味的是，问题不出在 Framework 自己的服务器上。

泄露发生在上游的商业智能平台

Framework 把责任源头指向了 Metabase——这家公司为其提供商业智能与数据分析服务，客户超过 10 万家，名单里包括麦当劳和第一资本（Capital One）。

据 Metabase 披露，攻击发生在 8 月 3 日，攻击者利用了一个此前无人知晓的零日漏洞。该漏洞位于公开可访问的密码重置接口 /api/session/reset_password，属于无需身份验证的 SQL 注入。攻击者可以借此向 Metabase 应用数据库注入任意 SQL 语句，进而提升至管理员权限、修改配置，并窃取平台中存储的所有已连接数据库的登录凭据。

这个漏洞在通用漏洞评分系统（CVSS）中拿到了满分 10.0，目前尚未分配 CVE 编号，暂以 GHSA-vwf4-m7j8-wcjf 追踪，影响 58 至 63 全部六个版本分支。Metabase 在漏洞公开当天就跨所有分支发布了修复版本，最低安全版本分别为 0.58.24、0.59.21、0.60.17、0.61.11、0.62.9 和 0.63.5。该公司同时封堵了攻击所用的接口、通报了执法部门，并聘请第三方取证机构介入调查。

对 Framework 而言，从收到 Metabase 通知到向客户发出邮件，间隔约六小时。

哪些数据被拿走了

根据 Framework 的说明与外媒核对的通知内容，被访问的数据包括客户姓名、电子邮箱、电话号码、实际住址（完整的账单地址与收货地址）以及登录 IP 地址。对于企业客户，公司名称、电话和账单邮箱是否泄露仍在确认中。

明确未被触及的是订单信息与支付信息——银行卡数据由 Stripe 独立处理，未进入 Metabase 这条链路。

Framework 发言人埃里克·舒马赫（Eric Schumacher）向 TechCrunch 确认，此次泄露影响“全部客户”，但拒绝透露具体人数。Framework 属于相对小众的产品，不过有估算认为其累计出货量达数十万台。攻击者是否完整下载了这些数据，目前尚不清楚，肇事者身份也未确定。

事后 Framework 轮换了与 Metabase 实例关联的所有数据库凭据，并确认管理员权限未被改动，Metabase 之外的系统也未被访问。该公司在给客户的邮件中表示，正在“审视并改进”其对外部数据存储的使用方式。

受同一漏洞波及的不止 Framework。在线表单工具 Tally 披露邮箱地址与密码哈希遭窃，律商联讯（LexisNexis）则通过一家运行了存在漏洞的 Metabase 实例的第三方供应商受到牵连。

为什么“及时打补丁”这次不管用

这起事件常见的反思是“要及时更新”，但细节并不支持这个结论。多方讨论显示，Framework 运行的是由厂商托管、自动升级的 Metabase 云端实例——正是安全清单上推荐的做法。支付环节做了隔离，所以卡数据安然无恙。它照着标准答案做了，最后照样要写一封泄露通知信。

这正是真正的零日漏洞的含义：在厂商自己都不知情之前，压根不存在可打的补丁。补丁节奏这个变量在那一刻是无效的，唯一还握在手里的变量，是漏洞接口的另一侧究竟连着多少东西。Framework 的暴露面其实在几个月前就决定了——在有人把客户信息表接进分析链路的那一刻。有网友表示，自己只填过一次候补名单，同样收到了泄露通知。

从架构上看，商业智能工具天然是数据栈里最脆弱的一环：它通常是一个可从互联网访问的 Web 应用，手握通往数据仓库的长期凭据，而它的全部工作就是对企业积累的所有数据执行查询。数据引力最大，攻击面却和普通 Web 应用无异。

Metabase 近年的记录也印证了这一模式。2023 年编号 CVE-2023-38646 的预认证远程代码执行漏洞在披露数日内即被大规模利用，至今仍能在数千个暴露于公网的实例上找到；2026 年 2 月，另一个漏洞（GHSA-vcj8-rcm8-gfj9）允许任意已认证用户通过注入邮件通知模板窃取数据仓库凭据；4 月还出现过附带公开验证代码的远程代码执行缺陷。不同的漏洞，同一个主题。

自托管用户目前处境更被动：云端实例已完成修复，而自托管方要与一份公开的、正被实际利用的漏洞公告赛跑。安全建议包括立即升级至上述最低安全版本，在无法即时升级时于网关层拦截 /api/session/reset_password 接口，撤销所有活跃会话，核查 API 密钥与管理员账户有无异常变动，轮换 Metabase 连接的每一个数据库的凭据，并检查查询日志中是否存在异常的数据导出记录。

对 Framework 是雪上加霜

这次泄露赶上了一个尴尬的时点。受内存价格持续走高影响，Framework 今年已两度调价。在高端产品 Laptop 13 Pro 开启首轮预订不久后，公司还通知部分预订用户，其配置中的内存容量将被下调，并提供不满意可退款的选项。

涨价并非孤例，苹果、华硕、戴尔、联想等厂商同样上调了价格。但大厂可以靠消化既有库存或批量采购来推迟、削弱涨价幅度，Framework 作为按批次出货的小厂没有这份余裕——内存或固态硬盘价格一跳，后果立刻传导到售价上。

考虑到这次通报较为透明、修复也算迅速，安全事件本身未必会让核心用户却步。但它出现在 Framework 正努力重建市场信心的节骨眼上。顺带一提，这并非该公司首次遭遇第三方引发的数据泄露——2024 年 1 月，其外部会计事务所 Keating Consulting 就曾泄露客户姓名与邮箱。

来源：How-To Geek、TechCrunch、PCMag、Metabase 安全公告

为了考高分，AI 自己找到了「逃生通道」

事情起因于 OpenAI 的一项内部评估。为了量化模型的网络攻击能力，OpenAI 让包括 7 月初发布的 GPT-5.6 Sol 和一款能力更强、尚未发布的预发布模型在内的多个模型，在名为 ExploitGym 的基准测试中接受考核。为测出真实上限，OpenAI 有意调低了安全防护等级，但模型仍被限制在与外部网络隔离的沙盒环境中运行。

然而，模型没有按考官的剧本走。为了在测试中拿到高分，它投入大量推理算力寻找出路，最终发现并利用了内部软件包注册表缓存代理中的一个零日漏洞——即软件厂商尚未发现、来不及修补的安全缺陷——完成提权和横向移动，成功接入了互联网。

「越狱」之后，模型进一步推断：Hugging Face 平台上可能存放着这次测试涉及的模型、数据集和答案。于是它利用窃取的登录凭证，通过 Hugging Face 数据处理流水线中的远程代码执行漏洞侵入其生产系统，提取了测试答案。用 OpenAI 的话说，模型「为了一个相当狭窄的测试目标，走到了极端的地步」。

活跃数天才被发现

7 月 16 日，Hugging Face 率先披露遭到入侵，称这次攻击「与以往处理过的任何情况都不同」——整场攻击从头到尾由一套自主 AI 智能体系统驱动：大量短生命周期的沙盒智能体执行了数千个独立动作，在周末期间提升至节点级权限，收割云和集群凭证，并横向移动至多个内部集群。这些 AI 智能体在互联网上活跃了数天才被发现，最终 Hugging Face 用自家的智能体检测并阻断了攻击。

数天后，OpenAI 发文承认责任，将事件定性为「一起前所未有的网络事件」，并表示已就此与执法部门和其他政府机构沟通，后续将与 Hugging Face 共同完成调查并公布更多细节。

Hugging Face 联合创始人兼首席执行官克莱门特·德朗格表示：「鉴于该智能体的复杂程度，我们当时就怀疑攻击可能来自某个前沿实验室——结果确实如此！」他强调，与 OpenAI 密切合作排查后，「我们坚信对方没有任何恶意。这一切都是自主发生的，实在令人震惊」，并称这「可能是史上第一起此类事件」。

模型能力越强，安全越要跟上

OpenAI 在声明中坦言：「AI 正在加速漏洞的发现与利用。这次事件的首要教训是，模型的安全防护必须跟上能力快速演进的步伐。」该公司预计，随着具备更强网络能力的模型不断普及，此类事件「将变得更加常见」。

德朗格则借此重申了开源社区的立场：「AI 安全不会靠任何一家公司闭门解决，它将以开放、协作的方式解决，让世界各地的每一个防御者都能充分使用 AI。」

这起事件给整个行业敲响了警钟：当 AI 从「回答问题」进化到「自主执行任务」，安全挑战已经完全升级。过去人们担心 AI 答错话，现在需要提防的，是它为达成目标而绕过限制、突破边界的能力。

来源：The Guardian、OpenAI 官方披露、CBS News（https://www.theguardian.com/technology/2026/jul/22/openai-says-its-models-went-rogue-and-hacked-startup）