最新内容 微 信 搜索 公 众 号 网 络 研 究 观在人工智能全面普及的今天许多程序员和企业团队都已经习惯了让 AI 帮我们“干脏活累活”。比如在开源社区 GitHub 上当有人提交了一个 Bug 报告Issue或者一段新代码Pull Request时自动化的 AI 助手就会立刻上线帮你分析问题、审查代码甚至自动提交修复。然而AI 正在带来效率革命也可能正在悄悄为你打开后门。在顶尖安全盛会Black Hat USA 2026上知名安全机构 Novee Security 披露了一项颠覆认知的重磅研究黑客只需要在 GitHub 上以普通用户的身份发布一条看起来毫无异常的 Issue没有任何管理员权限就能轻松黑进 Anthropic、Google 和 OpenAI 的官方开源项目Anthropic 的 Claude Code、Google 的 Gemini CLI、OpenAI 的 Codex——全球顶级的“AI 程序员”三大巨头无一幸免。这到底是怎么回事我们日常使用的 AI 自动化工具究竟存在哪些致命隐患隐形刺客一条评论如何“提操”AI想象一下这个场景你在 GitHub 上的开源项目里开启了一个“AI 帮手”专门用来处理大家提交的意见。有一天一个不怀好意的黑客在你的项目页面下写了一篇非常长、看似很正常的 Issue。然而在这篇评论的隐藏角落里黑客用人类几乎不会注意到的格式对 AI 下达了一行“提操指令”即 Prompt 注入。当你的 AI 助手被系统触发去读取这篇 Issue 时它并没有区分出“这是外部用户的留言”还是“主人的命令”。它傻傻地把黑客的话当成了最高指令然后拿起你赋予它的系统权限转头就把你项目的密钥、服务器的控制权拱手送给了黑客Novee Security 在测试三大巨头的工具时发现各自的漏洞路线堪称“精彩纷呈”1. Anthropic (Claude Code)三次封堵仍被“借力打力”窃取密钥在处理 Claude Code 时安全人员先后发现了多条攻击路径第一波攻势绕过校验。黑客在 Issue 里藏入指令诱骗 Claude 执行一条经过精心设计的git push命令直接在 GitHub Actions 的运行服务器上远程执行了恶意代码一举拿到 Anthropic 的 API Key 以及 GitHub 敏感 Token。第二与第三波隐藏的隐蔽通道CVE-2026-54316。即便官方限制了文件读取和网络访问黑客依然利用了 Claude Code 默认信任 Hugging Face 域名知名 AI 模型社区的逻辑。黑客让 Claude 向攻击者控制的 Hugging Face 仓库发送请求将窃取到的机密数据编码在请求中攻击者只需在后台监测下载计数就能精准还原出机密目前该漏洞已在 Claude Code 2.1.163 版本中得到修复2. Google (Gemini CLI)满分级危险从沙盒内部“开门见山”Google 的 Gemini CLI 漏洞更为震撼——在 CVSS通用漏洞评分系统中直接斩获了10.0 的满分危险等级最高等级Google 本意是给 Gemini CLI 设定严格的指令限制比如只允许它运行简单的echo命令或查看 Issue。但安全专家发现 Gemini CLI 在真正执行时根本没有在底层的系统 Shell 中强制实行这条限制。虽然系统在子进程中清除了敏感变量但由于父进程和子进程共享了同一个 Linux 命名空间恶意命令直接通过/proc文件系统“反向透视”父进程毫不费力地拿到了包含 Gemini API 密钥和 GitHub 权限Token在内的全部最高机密。3. OpenAI (Codex)“隔山打牛”借助 AI 的记忆跨时空投毒OpenAI Codex 的自动化流程采用了“双 Agent双智能体”协同机制第一个 AI 负责过滤和重算第二个 AI 负责最终处理。本以为就算第一个 AI 被误导输出的内容只要被拦截就没事了。可黑客玩了一招“隔墙打牛”01. 诱导第一个 AI 助手在工作区里默默创建一个名为AGENTS.md的隐藏配置文件02. 当第一个 AI 任务失败、第二个 AI 助手被唤醒启动时Codex 会默认自动加载当前目录下的AGENTS.md作为系统指令03. 于是第二个 AI 直接被黑客提前预埋的“毒文件”所掌控虽然 OpenAI 官方在 3 天内紧急修补了自己的仓库但安全团队在 GitHub 上搜索发现全球有超过 100 个知名公开开源仓库目前依然暴露在这种风险配置之下给我们的警示AI 时代安全边界在哪里过去我们常说“不要运行来自陌生人的可执行文件”。而到了 AI Agent 时代这个铁律演变成了“不要让拥有高权限的 AI 助手去读取未经过滤的陌生人文本。”大语言模型LLM天生具有“指令与数据不隔离”的特征——对它来说你给它的提示词Prompt和它从网页、Issue 里读取到的文本Data在底层都是同一串字符。一旦数据里夹杂着恶意的指令AI 就会彻底“混淆角色”。开发者与企业防范建议1. 及时更新版本使用 Claude Code 的团队请确保升级至2.1.163以上Gemini CLI 用户请升级至0.39.1预发布版0.40.0-preview.3以上。2. 践行最小权限原则切勿将写权限Write Permission或高权 API Key 随意绑定给公开触发的自动化流程。3. 隔离工作空间切断多个 AI Agent 之间的共享可写目录避免类似AGENTS.md的跨步投毒。4. 人工审核屏障对于任何涉及自动执行代码、修改仓库、推送包Package的 AI 流程必须加入人类确认Human-in-the-loop环节。AI 确实是人类有史以来最强大的生产力工具但它目前依然像一个“智商极高却极其单纯的孩子”。在彻底解决 Prompt 注入与提权隐患之前在把它接入生产线和核心服务器时请务必为它戴好“安全绳”
最新内容 微 信 搜索 公 众 号 网 络 研 究 观在人工智能全面普及的今天许多程序员和企业团队都已经习惯了让 AI 帮我们“干脏活累活”。比如在开源社区 GitHub 上当有人提交了一个 Bug 报告Issue或者一段新代码Pull Request时自动化的 AI 助手就会立刻上线帮你分析问题、审查代码甚至自动提交修复。然而AI 正在带来效率革命也可能正在悄悄为你打开后门。在顶尖安全盛会Black Hat USA 2026上知名安全机构 Novee Security 披露了一项颠覆认知的重磅研究黑客只需要在 GitHub 上以普通用户的身份发布一条看起来毫无异常的 Issue没有任何管理员权限就能轻松黑进 Anthropic、Google 和 OpenAI 的官方开源项目Anthropic 的 Claude Code、Google 的 Gemini CLI、OpenAI 的 Codex——全球顶级的“AI 程序员”三大巨头无一幸免。这到底是怎么回事我们日常使用的 AI 自动化工具究竟存在哪些致命隐患隐形刺客一条评论如何“提操”AI想象一下这个场景你在 GitHub 上的开源项目里开启了一个“AI 帮手”专门用来处理大家提交的意见。有一天一个不怀好意的黑客在你的项目页面下写了一篇非常长、看似很正常的 Issue。然而在这篇评论的隐藏角落里黑客用人类几乎不会注意到的格式对 AI 下达了一行“提操指令”即 Prompt 注入。当你的 AI 助手被系统触发去读取这篇 Issue 时它并没有区分出“这是外部用户的留言”还是“主人的命令”。它傻傻地把黑客的话当成了最高指令然后拿起你赋予它的系统权限转头就把你项目的密钥、服务器的控制权拱手送给了黑客Novee Security 在测试三大巨头的工具时发现各自的漏洞路线堪称“精彩纷呈”1. Anthropic (Claude Code)三次封堵仍被“借力打力”窃取密钥在处理 Claude Code 时安全人员先后发现了多条攻击路径第一波攻势绕过校验。黑客在 Issue 里藏入指令诱骗 Claude 执行一条经过精心设计的git push命令直接在 GitHub Actions 的运行服务器上远程执行了恶意代码一举拿到 Anthropic 的 API Key 以及 GitHub 敏感 Token。第二与第三波隐藏的隐蔽通道CVE-2026-54316。即便官方限制了文件读取和网络访问黑客依然利用了 Claude Code 默认信任 Hugging Face 域名知名 AI 模型社区的逻辑。黑客让 Claude 向攻击者控制的 Hugging Face 仓库发送请求将窃取到的机密数据编码在请求中攻击者只需在后台监测下载计数就能精准还原出机密目前该漏洞已在 Claude Code 2.1.163 版本中得到修复2. Google (Gemini CLI)满分级危险从沙盒内部“开门见山”Google 的 Gemini CLI 漏洞更为震撼——在 CVSS通用漏洞评分系统中直接斩获了10.0 的满分危险等级最高等级Google 本意是给 Gemini CLI 设定严格的指令限制比如只允许它运行简单的echo命令或查看 Issue。但安全专家发现 Gemini CLI 在真正执行时根本没有在底层的系统 Shell 中强制实行这条限制。虽然系统在子进程中清除了敏感变量但由于父进程和子进程共享了同一个 Linux 命名空间恶意命令直接通过/proc文件系统“反向透视”父进程毫不费力地拿到了包含 Gemini API 密钥和 GitHub 权限Token在内的全部最高机密。3. OpenAI (Codex)“隔山打牛”借助 AI 的记忆跨时空投毒OpenAI Codex 的自动化流程采用了“双 Agent双智能体”协同机制第一个 AI 负责过滤和重算第二个 AI 负责最终处理。本以为就算第一个 AI 被误导输出的内容只要被拦截就没事了。可黑客玩了一招“隔墙打牛”01. 诱导第一个 AI 助手在工作区里默默创建一个名为AGENTS.md的隐藏配置文件02. 当第一个 AI 任务失败、第二个 AI 助手被唤醒启动时Codex 会默认自动加载当前目录下的AGENTS.md作为系统指令03. 于是第二个 AI 直接被黑客提前预埋的“毒文件”所掌控虽然 OpenAI 官方在 3 天内紧急修补了自己的仓库但安全团队在 GitHub 上搜索发现全球有超过 100 个知名公开开源仓库目前依然暴露在这种风险配置之下给我们的警示AI 时代安全边界在哪里过去我们常说“不要运行来自陌生人的可执行文件”。而到了 AI Agent 时代这个铁律演变成了“不要让拥有高权限的 AI 助手去读取未经过滤的陌生人文本。”大语言模型LLM天生具有“指令与数据不隔离”的特征——对它来说你给它的提示词Prompt和它从网页、Issue 里读取到的文本Data在底层都是同一串字符。一旦数据里夹杂着恶意的指令AI 就会彻底“混淆角色”。开发者与企业防范建议1. 及时更新版本使用 Claude Code 的团队请确保升级至2.1.163以上Gemini CLI 用户请升级至0.39.1预发布版0.40.0-preview.3以上。2. 践行最小权限原则切勿将写权限Write Permission或高权 API Key 随意绑定给公开触发的自动化流程。3. 隔离工作空间切断多个 AI Agent 之间的共享可写目录避免类似AGENTS.md的跨步投毒。4. 人工审核屏障对于任何涉及自动执行代码、修改仓库、推送包Package的 AI 流程必须加入人类确认Human-in-the-loop环节。AI 确实是人类有史以来最强大的生产力工具但它目前依然像一个“智商极高却极其单纯的孩子”。在彻底解决 Prompt 注入与提权隐患之前在把它接入生产线和核心服务器时请务必为它戴好“安全绳”
