谷歌让AI给自己挖出500个洞

导语

过去一周，安全圈发生了两件看似无关、实则同源的事：Google 的 AI agent PageBreak 在自家 Web 应用里挖出了 500 个漏洞；另一边，IBM 披露其 AI 工作流平台 Langflow 存在 25 个漏洞，其中两个是无需认证即可远程代码执行（RCE）的严重级缺陷。

一喜一忧，指向同一个判断：AI 正在同时成为漏洞发现的超级生产力，和企业版图上最脆的一块新地皮。 只会讲「AI 挖洞很厉害」的故事，读懂不了这轮变化。

🤖 500 个漏洞：AI 给自己挑刺

金句先行：最了解代码的，往往是写代码的那套系统本身。

场景是这样的：Google 内部跑着一个叫 PageBreak 的 AI agent，专门在自己的 Web 应用上做自动化漏洞挖掘，结果是 500 个缺陷被找了出来。这事最有意思的地方不是数量，而是背后的方法——官方表述点得很清楚：这是一个「用 AI 与确定性验证（deterministic validation）来识别缺陷与可利用性、并给出风险评估」的趋势。

拆开看，这句话包含三层：AI 负责生成候选——在哪里注入、构造什么 payload、绕过哪段逻辑；确定性验证负责裁决——这个候选是不是真的可利用，跑一遍就知道，不靠大模型「我觉得有问题」；最后输出的是风险评估，而不是一箩筐待人工分拣的扫描报告。

懂渗透的人都知道传统流程有多痛：扫描器动辄吐出上千条「疑似漏洞」，安全工程师大量时间花在证伪误报上，真正的可利用点反而淹没在噪音里。PageBreak 代表的路线，本质是把「发现」交给 AI 的发散能力，把「定罪」交还给确定性执行——幻觉被拦在了验证环节之外。

产业逻辑也随之清晰：漏洞挖掘正在从「人海 fuzz + 人工分诊」转向「agent 猜测 + 确定性验证闭环」。当巨头把这套东西跑在自己的生产应用上，说明它已经过了 PoC 阶段。对乙方安全厂商来说，这不是远期叙事，是明年的竞争基线。

⚠️ Langflow：你的 agent 平台就是攻击面

金句先行：用来搭 AI 应用的工作台，自己先成了靶子。

IBM 这次披露得相当扎实：Langflow 开源版（Langflow OSS）存在 25 个漏洞，影响范围横跨 1.0.0 至 1.12.2 的所有版本，其中两个是严重级（Critical）——无需身份认证即可远程代码执行。官方的安全公告只给出一条建议：升级到 1.12.3。值得注意的是，公告里没有列出任何缓解措施（workaround）。换句话说，没有变通捷径，不升级就是裸奔。

Langflow 是什么？一个用可视化方式构建 AI agent 和工作流的平台，支持用 Python 做深度定制。这个定位决定了它的危险系数：为了灵活，它天然要执行用户提供的代码、编排复杂的工作流。这类系统一旦存在未认证 RCE，攻击者拿到的不是一个「信息泄露点」，而是一个合法的代码执行环境——agent 能调用的 API、能读的数据、能连的内网凭证，攻击者都能顺手接管。

据不少一线安全从业者的私下观察，很多团队把 Langflow、Dify 这类 agent 搭建平台当成「开发工具」部署，权限宽松、鉴权简单、监控缺失，压根没按高危资产对待。讽刺的一幕随时可能上演：某公司用 Langflow 搭了一个自动化安全响应 agent，结果平台本身先被打了进去。

产业逻辑很直白：每一代新平台，都会重演一次「功能优先、安全靠后」的老剧本。 AI agent 平台因为「必须执行代码」的天性，把 Web 应用历史上最危险的暴露面直接搬到了业务最前沿。

一条典型的攻击链长这样：

🔍 确定性验证：AI 挖洞不是玄学

金句先行：AI 负责天马行空，验证负责铁面无私。

把两条素材放在一起看，会发现它们拼出了 AI 安全工具的真实坐标。PageBreak 的 500 个漏洞证明 AI 挖洞可行，Langflow 的两个未认证 RCE 则证明被 AI 放大攻击能力的企业，其工具链本身同样会被传统漏洞打穿。这不是二选一，而是同一枚硬币的两面。

从技术光谱上看，各类检测手段的位置大致是这样的：

右上角的组合为什么商业价值最高？因为它的产出可以直接进入修复流程。传统扫描器的产出需要人花时间过滤，人工渗透测试的天花板是专家数量，而「AI 生成候选 + 确定性验证裁决」的模式，边际成本随算力下降，产出质量却接近渗透测试——这才是 Google 愿意把它跑在自家生产应用上的原因。

当然，也别神化。确定性验证擅长的是「有明确触发路径」的漏洞，复杂业务逻辑缺陷、需要长时间上下文理解的攻击场景，短期内仍然离不开人。比较现实的产品形态是分层：AI agent 扫量，确定性引擎过滤，人工专家啃硬骨头。这个分工已经在改变安全厂商的产品设计和定价逻辑——从按扫描次数收费，走向按「已验证漏洞」收费。

🧩 供应链视角：一环失守，全链归零

金句先行：AI 时代的供应链攻击，入口是一个可视化画布。

Langflow 事件的真正杀伤力，要从供应链角度衡量。作为开源项目，它被大量企业内嵌在 AI 应用链路里：数据处理、工作流编排、agent 编排，每一层都可能跑在它的运行时之上。25 个漏洞横跨十几个版本，意味着大量存量部署长期带着已知甚至未知的洞在跑，而其中两个未认证 RCE 的利用成本极低。

对照近几年 Log4j、XZ Utils 事件的经验，开源组件的漏洞披露只是起点，真正的风险窗口在于「披露到全面修复」之间的长尾期。IBM 这次没有提供任何 workaround，等于把压力全部压给了升级动作本身——而现实中，很多生产环境的升级要走变更评审、回归测试，周级别起步。这段时间窗口，就是攻击者的窗口。

给安全团队的建议，可以落成一张问题—方案清单：

`infographic

{"type":"problemsolution","title":"AI工具链防御清单","items":[{"problem":"Agent平台被当作普通工具部署，鉴权薄弱","solution":"按高危资产品级管理：强认证、网络隔离、最小权限"},{problem":"开源AI组件版本混乱，漏洞披露后无从排查","solution":"建立AI组件资产清单，纳入SCA与补丁管理流程"},{problem":"AI挖洞产出误报多、信任度低","solution":"引入确定性验证环节，只让已验证漏洞进入修复队列"},{problem":"无workaround的Critical漏洞修复周期长","solution":"预置应急升级预案，缩短披露到上线的时间窗口"}]}

`

多说一句：如果你们团队也在用 Langflow 这类平台搭 agent，先做三件事——确认版本是否在 1.0.0 至 1.12.2 区间内、实例是否暴露在公网、升级到 1.12.3 的变更单是否已经提了。别等扫描器替你发现。

🛡️ 两个信号的合流点

金句先行：生产力的爆发点和风险的爆发点，往往是同一个点。

把两个事件并排读，能看到 2025 年之后 AI 安全的主叙事：

• 进攻侧：PageBreak 式的「AI + 确定性验证」将成为头部企业标配，漏洞发现的规模和速度上一个量级；
• 防守侧：Langflow 式的 AI 基础设施漏洞会成为高频打击目标，攻击者利用的正是企业对这类平台「重功能、轻防护」的部署惯性。

两者合流的结果是：安全团队的工作量不会因为 AI 减少排查负担而下降，反而会因为「发现更多漏洞 + 防护更多新资产」双重增长。谁能先打通「AI 发现—确定性验证—自动修复验证」的流水线，谁就在下一轮竞争中握有主动权。

小结

Google 用 500 个漏洞证明 AI 挖洞已进入生产可用，IBM 用 25 个漏洞提醒我们 AI 工具链本身就是新的攻击面。一攻一防，共同指向一个判断：未来的安全能力差距，不在「有没有用 AI」，而在「AI 的产出能否被确定性验证、AI 的底座能否被当成人质级资产守护」。接下来值得盯的是：确定性验证是否会标准化为漏洞管理的默认环节，以及 agent 平台厂商是否被迫把安全设计前置。下一批 Critical RCE，大概率还是从这类平台里长出来。