[业内新闻动态] [【转载】] Google 删除了 3 个 ADK AI 工作流;此前恶意 GitHub Issue 可触发高权限 AI 代理

#1
google.gif

Google 已经从它的 Agent Development Kit Python 代码库中删除了三个 AI 代理工作流。安全公司 Pillar Security 披露,一个公开的 GitHub Issue 就能诱导负责问题分类的 AI 代理,进一步触发拥有更高权限的自动修复代理。

研究人员指出,攻击者可以通过输入提示词,从而诱导公开运行的 AI 代理以 adk-bot 身份发布 /adk-issue-fix 指令。由于该机器人账号本身拥有仓库协作者权限,因此其评论能够通过仅允许仓库所有者、成员或协作者执行的权限检查,从而启动高权限修复工作流。换句话说,攻击者通过利用受信任的机器人身份,绕过了原有的权限控制机制。

Pillar Security 进一步演示了如何在持续集成运行环境中执行任意代码,并成功获取机器人账号使用的访问权限。研究人员还发现,该高权限工作流的运行环境中同时保存了 Google API 密钥以及 Google Cloud 服务账号凭证。不过,他们强调,这些攻击仅仅只是概念上的验证,目前没有证据表明漏洞已遭到真实攻击利用,也没有迹象显示 ADK Python 的正式发布版本会受到影响。

研究人员表示,GitHub 仓库的自动化工作流是主要的问题所在,而非对外发布的 ADK Python 软件包本身。针对采用类似自动化流程的代码仓库,Pillar 建议为不同机器人使用独立身份、进一步收紧访问令牌和工具权限范围,并采用无法被外部输入伪造的授权机制。

整个攻击链始于公开的 issue-analyze.yml 工作流。每当有人创建新的 GitHub Issue 时,该工作流都会自动执行,使用 ADK_GCP_SA_KEY 完成身份验证,并将 ADK_TRIAGE_AGENT 和 GOOGLE_API_KEY 提供给 Google 的 Antigravity 编码代理分析 Issue,随后再以机器人账号将分析结果自动发布到评论区。

另一条名为 issue-fix.yml 的工作流则负责监听 /adk-issue-fix 指令,并限制只有仓库所有者、成员或协作者才能操作。然而,这一权限检查只验证了指令发布者的身份,却没有判断该受信任账号是否已经受到外部输入操控,因此成为了整个攻击链中的关键漏洞。

高权限工作流拥有对 Issue、仓库内容以及合并请求的写入权限。虽然 GitHub 自动生成的 GITHUB_TOKEN 权限受到限制,但实际执行任务时使用的是 ADK_TRIAGE_AGENT 的访问令牌,其具体权限范围并未公开。工作流会利用该令牌检出代码、登录 Google Cloud,并在环境变量中加载访问令牌和 API 密钥来运行 AI 代理。整个自动化流程原本用于修改代码、创建 adk-bot 的代码分支、推送变更并自动发起合并请求。Pillar 指出,机器人于 6 月 4 日在 GitHub 上创建的合并请求,也证明这套自动化机制当时确实处于正常运行状态。

6a70809f2c071c0335958d4c_Two Chains, one identity failure.png

虽然 CI 运行环境禁止使用 Shell 元字符,并仅允许执行以 gh 或 git 开头的命令,但是脚本同时启用了 CapabilitiesConfig()。根据 Google Antigravity SDK 文档,这项配置会开启包括文件写入在内的全部工具性能。因此,AI 代理仍然可以先写入恶意载荷,再利用允许执行的 Git 命令,结合自定义 Hook 路径完成代码执行。

Git 官方文档也指出,Hook 本质上就是可执行程序,而 core.hooksPath 配置允许 Git 将 Hook 指向其他目录。因此,即使命令白名单限制了可执行命令,只要仍允许写入文件并执行 Git,就依然存在实现任意代码执行的途径。目前公开资料尚无法确认,被获取的访问令牌是否拥有直接向主分支推送代码的权限。Pillar 表示,Google 告知其该服务账号仅拥有专门用于 GitHub 管理项目中的 Vertex AI 权限,但是否还拥有更广泛的云端权限并未公开。根据公开报告,目前能够确认的是攻击者可以在 CI 运行环境中执行代码并接触到相关凭证,但这些凭证最终能够访问哪些代码仓库或 Google Cloud 资源,依旧无法从公开信息中得到确定。

报告还披露了一条更早发现的攻击路径,该路径可借助具有高权限的 Gemini 工作流伪造代码审查记录。不过,即使成功利用这一攻击链,最终仍需仓库维护者手动合并代码,因此无法完全实现自动化攻击。

Google 在删除相关工作流的提交说明中表示,这些工作流会使用拥有较高仓库权限的凭证,从而处理来自 Issue 和合并请求的不受信任内容,因此存在安全风险。Google 随后删除了 issue-analyze.yml、issue-fix.yml 和 pr-analyze.yml 三个工作流文件。该修复提交的元数据显示,其作者日期为 2026 年 6 月 9 日。

Pillar Security 表示,截至 7 月 2 日,相关工作流已从仓库中移除;Google 则于 7 月 21 日确认该安全问题已经完成修复。
2026-09-17
#2

这个洞挺有意思的,本质上就是信任边界崩塌。

Issue是公开的,谁都能提交内容,但你把这段外部输入直接喂给AI agent跑代码,等于把枪递到别人手上。GitHub那边权限检查只认"是不是bot发的",不认"bot这次是不是被人操控了",这道gap就是整个攻击链的油门。

最骚的是CapabilitiesConfig()这东西——开全工具集+命令白名单本来想收紧攻击面,但文件写入+git命令的组合本身就是一条完整的代码执行路径。Hook能指向任意目录这事搞过git hooks的都懂,理论上白名单里的gh/git命令完全能配合写入操作完成RCE。

至于凭证那部分,CI环境里塞着Google API Key和GCP SA Key,跑的还是高权限agent——不管SA本身权限多细粒度,攻击者能在你那台机器上跑代码这件事本身就已经很被动了。环境变量里的token对攻击者来说就是现成的。

建议谈不上,说两个实战中容易踩的坑吧:AI工作流处理外部输入时,别光过滤prompt本身,整个触发链路都要做输入来源验证;再有就是凭证不要进CI运行时环境,实在要用的话走secret动态注入,别直接写死在环境变量里。