基础说明

漏洞代号：Friendly Fire（友军误伤）
研究发布：AI Now Institute
漏洞类型：AI语义认知缺陷、文档型Prompt注入、AI供应链投毒
影响范围：Claude Code Auto-Mode、OpenAI Codex Auto-Review、Claude Sonnet 4.6/5、Opus 4.8、GPT-5.5
漏洞特征：无CVE、厂商三次补丁全部绕过、零源码篡改、纯文档投毒、全模型通用Payload

前言

作为长期负责企业技术架构、研发流程与安全体系的负责人，我非常清楚国内绝大多数团队的AI安全现状：大家都在疯狂上AI自动化提效，却几乎没人建立对应的AI对抗安全思维。

传统安全建设，是防守外部黑客突破边界；AI安全建设，是防守工具自身犯错、自身被利用、自身主动引敌入境。这是完全两套逻辑。

本次 Friendly Fire 攻击，是迄今为止最具备行业颠覆性的AI安全事件。它没有利用系统漏洞，没有缓冲区溢出，没有权限提升，没有恶意源码。攻击者仅仅修改开源项目的 README.md 说明文档，写入一段看似正常的运维操作指引，就能让行业主流AI代码审查Agent自动信任、自动下载、自动执行恶意脚本，最终落地伪装二进制后门，完成完整入侵链路。

更关键的事实是：Anthropic 在半年时间内连续发布三次安全补丁，专门封堵配置文件注入风险，结果全部被这篇文档绕过。

这意味着一件所有技术负责人必须重视的事：当前厂商的安全修复体系，完全跟不上新型AI攻击的迭代逻辑。

市面上绝大多数解读停留在漏洞通报层面，只说现象、不说本质，只讲风险、不给落地方法。本文我从企业治理第一性原理出发，穿透表层漏洞现象，重构AI代码审查的安全边界，用对抗式审查思维复盘全线失守原因，给到可直接部署的检测脚本、流程规范、沙箱策略、监控规则、长期治理体系，全部为实战落地内容。

一、第一性原理拆解：漏洞本质不是Bug，是AI安全范式崩塌

所有传统研发安全、供应链安全、代码安全，都建立在一条亘古不变的底层规则上：静态文档不具备攻击性，只有可执行文件、代码、配置文件可以产生风险。

这是十几年安全行业的底层共识，也是所有扫描工具、防火墙、代码审计平台、CI安全校验的设计基准。

README、INSTALL、GUIDE 这类文件，在传统安全体系中属于纯说明载体，仅用于人工阅读参考，不参与程序运行、不参与编译构建、不触发系统指令。所以所有安全设备默认放行，所有企业审计流程直接忽略。

但AI Agent的诞生，直接推翻了这条底层规则。

AI代码审查工具的核心价值，就是替代人工阅读项目、理解项目、优化项目、运维项目。人工工程师在阅读文档时，会区分“建议性描述”和“强制性命令”，会判断陌生脚本、陌生下载、陌生编译操作的风险，具备天然风控判断力。

但AI没有。

AI只会基于语义相似度、场景匹配度、项目上下文逻辑，执行它认为“合理、合规、有助于项目优化”的操作。AI会完全跟随文档指引完成整套运维动作，不会区分这段文字是“开发者备注”还是“攻击者陷阱”。

第一性原理剥离所有表象，最终漏洞本质只有一句话：
传统安全以文件类型判定风险，AI安全以语义内容判定行为，两者底层逻辑完全冲突，造成系统性防御真空。

厂商之前修复的，是配置文件注入、代码字段注入这类“已知风险”。而本次攻击，是文档语义诱导这类“未知风险场景”。补丁打在了旧漏洞上，新漏洞完全空白，这就是三次补丁全部失效的核心原因。

二、全链路攻击复盘：可视化流程与架构拆解

2.1 攻击时序流程图

2.2 攻击分层架构图

看完两张图，所有技术管理者应该能直观感受到本次攻击的恐怖性。

整条攻击链路没有任何违规操作，所有动作都是AI自动化工作流的标准行为。AI自动优化项目、自动跟随官方指引、自动补全运维流程、自动构建编译环境，这些原本用来提升研发效率的正向功能，全部被攻击者转化为入侵通道。

过去的攻击，需要突破安全规则；现在的AI攻击，直接利用安全工具的能力本身完成入侵。

三、对抗式审查复盘：企业全线失守的核心原因

做安全治理，最忌讳被动跟风漏洞预警。真正的对抗思维，是站在攻击者视角，反向推倒企业所有薄弱点。我结合多年企业安全架构经验，总结出国内团队普遍存在的三类致命问题。

第一，安全规则静态固化，完全滞后AI能力迭代。

企业安全策略、代码审计规则、AI防护机制，全部是静态规则库。厂商更新补丁、企业更新策略，永远滞后攻击手法。AI的语义理解范围越来越广，能读懂的文档越来越多，能执行的操作越来越复杂，但企业的风控边界始终停留在“只审代码、不审文档”的旧时代。

第二，过度依赖自动化，彻底砍掉人工风控屏障。

绝大多数中小团队、互联网团队、外包研发团队，为了压缩人力成本、提升迭代速度，全开AI自动模式。自动审查、自动修复、自动补全、自动执行、自动构建。AI拥有完整的研发操作权限，但团队没有给AI配置对应的风险约束机制。

等同于让一个“能力无限、没有判断力”的新人全权接管研发流水线，不出问题只是运气，出问题是必然。

第三，环境无隔离，单点风险直接全域击穿。

绝大多数企业的开发、测试、AI审计、预发环境全部互通，没有严格的网络隔离、权限隔离、文件隔离。AI审计一旦被诱导执行恶意代码，攻击者可以直接横向移动，遍历目录、窃取源码、抓取密钥、植入持久化后门，整个研发体系彻底沦陷。

对抗式审查的核心结论很明确：本次漏洞不是单点工具缺陷，是企业AI安全治理体系的全面缺失。

四、真实落地风险：不止单点入侵，是供应链系统性危机

抛开行业空话，我从企业经营和研发安全角度，梳理本次漏洞的实质性危害，每一条都是可以直接落地感知的风险。

首先是开源供应链无声污染。
攻击者不需要修改项目任何源码，仅修改说明文档即可完成投毒。开源平台的自动化审计工具不会检测文档风险，普通开发者引入依赖也不会细读每一行README指令。一旦投毒版本被迭代更新、被其他项目依赖，会形成链式传播，批量污染上下游项目。

其次是AI权限层级过高，危害远大于普通账号。
人工开发者的操作会受到日志审计、权限限制、操作约束，而AI Agent为了保证自动化效率，通常被授予目录遍历、文件读写、脚本执行、外网请求、编译打包的完整权限。一旦被劫持，攻击者获得的是研发环境的高阶权限，破坏力远超普通入侵。

再者是攻击行为完全隐匿，无法常规溯源。
传统恶意程序会产生异常进程、异常网络请求、异常文件特征，而本次攻击载荷伪装成常规Go编译文件，行为属于正常项目构建操作。安全告警平台、杀毒引擎、行为监测工具全部不会触发告警，攻击可以长期潜伏、持续控权。

最后是现有防御体系彻底失效。
无论是企业自建代码审计平台、第三方安全SaaS、还是厂商最新AI安全补丁，全部无法识别文档语义诱导攻击。企业投入的安全成本完全失效，形成裸奔式研发环境。

五、实战工具：README投毒专项检测脚本（生产可用、一键扫描）

为了让所有团队可以快速自查、闭环风险，我针对性编写专项检测脚本，精准匹配 Friendly Fire 攻击核心特征，适配全平台研发环境，可本地运行、可接入CI/CD、可批量扫描存量项目。

完整可复制检测脚本

#!/usr/bin/env python3# Friendly Fire AI攻击专项自查工具# 适配README文档投毒、AI代码审查绕过风险检测# 作者：企业技术安全实战版本importosimportreimportsys# 精准匹配本次攻击核心特征库ATTACK_RULES=[r"security\.sh",r"wget\s+http.*\.sh",r"curl\s+http.*\.sh",r"bash\s+[\.\/].*",r"sh\s+[\.\/].*",r"go\s+build",r"\.bin",r"下载.*脚本",r"执行.*shell"]# 高风险文档覆盖清单SCAN_TARGET=["README.md","INSTALL.md","USAGE.md","GUIDE.md","INSTALL"]defscan_file(path):risks=[]try:withopen(path,"r",encoding="utf-8",errors="ignore")asf:lines=f.readlines()forline_num,line_textinenumerate(lines,1):forruleinATTACK_RULES:ifre.search(rule,line_text,re.IGNORECASE):risks.append({"file":path,"line":line_num,"content":line_text.strip()})exceptException:passreturnrisksdefscan_project(root_dir):all_risk=[]forroot,_,filesinos.walk(root_dir):forfilenameinfiles:iffilenameinSCAN_TARGET:full_path=os.path.join(root,filename)all_risk.extend(scan_file(full_path))returnall_riskif__name__=="__main__":scan_path=sys.argv[1]iflen(sys.argv)>1elseos.getcwd()print("===== AI Friendly Fire 文档投毒专项扫描 =====")result=scan_project(scan_path)ifresult:print(f"【风险告警】共检测到{len(result)}处高危文档指令")foriteminresult:print(f"\n文件路径：{item['file']}")print(f"风险行号：{item['line']}")print(f"风险内容：{item['content']}")sys.exit(1)else:print("【扫描完成】未发现README投毒风险")sys.exit(0)

使用方式

1. 将代码保存为ai_risk_scan.py
2. 进入项目根目录执行：python3 ai_risk_scan.py ./
3. 检出风险立即人工复核，删除陌生脚本下载、执行类指引
4. 可直接接入CI/CD，代码提交自动拦截高危文档

六、企业全维度落地防御体系（紧急+中期+长期）

我以企业治理视角，分层给出可直接落地的加固方案，不玩概念、不堆理论，全部为可落地配置。

6.1 紧急加固（当日落地）

第一，全网关闭AI自动执行权限。所有Claude Code、OpenAI Codex及自研AI审查工具，统一关闭自动命令执行、自动脚本运行、自动外网下载功能，所有高危操作强制人工审核。
第二，全量项目批量扫描。使用上方脚本完成所有业务项目、开源依赖、私有组件的文档风险排查。
第三，临时风控兜底。禁止AI在未授信开源代码库中执行任何系统级命令与编译操作。

6.2 中期加固（7天闭环）

搭建独立AI审计沙箱，与开发、测试、生产环境完全隔离，禁止跨环境文件传输与端口互通。
配置沙箱网络白名单，仅允许内部代码仓库域名访问，拦截所有陌生外网资源下载行为。
新增AI行为监控规则：所有由说明文档触发的指令执行、脚本下载、二进制编译行为一律拦截告警。
CI/CD流水线接入专项扫描脚本，实现提交即检测、风险即拦截。

6.3 长期架构重构（AI安全体系升级）

建立AI文件权限分级机制：业务代码可读、可分析、可修复；说明文档仅可读、不可生成执行动作、不可触发运维逻辑。
重构AI语义信任体系，区分“项目源码行为”和“文档建议行为”，从模型底层修复认知缺陷。
建立对抗式AI安全审计机制，每月主动模拟Prompt注入、文档投毒、语义诱导攻击，主动挖掘未知风险。

七、行业深度总结：AI安全已经进入对抗式时代

Friendly Fire 攻击带给行业的启示，远不止一个漏洞修复那么简单。

它标志着AI安全从被动补丁时代，彻底迈入主动对抗时代。

过去安全防守的是外部入侵者，未来安全防守的是工具本身。AI越智能、自动化越强，攻击面就越大。厂商的补丁永远滞后攻击手法，企业如果持续依赖官方修复，永远处于被动挨打状态。

所有技术团队必须建立一条核心准则：AI自动化能力的每一次扩容，都必须配套对应的安全约束扩容。只追求提效、忽略风控的AI研发体系，一定会成为企业最大的安全隐患。

八、互动讨论

1. 你的团队目前是否开启了AI代码审查的自动执行权限？
2. 你认为企业AI安全应该依赖厂商补丁，还是自建对抗式审查体系？