作者 | 腾讯AI编程安全-啄木鸟团队
我们是最新专注AI编程安全的啄木鸟团队 ,近日GitHub Copilot 和 Cursor 中出现可让AI“叛变”的叛变新漏洞,从手法复现 、除祈风险 、祷程建议三个角度为你讲解“AI助手叛变”之事始末。最新

你可能还没察觉到,AI已经开始“叛变”程序员了 。祷程
这不是最新危言耸听,安全厂商 Pillar Security 在一份报告中指出了AI“背叛”程序员的叛变证据。
他们表示GitHub Copilot 和 Cursor 等 AI 编程助手,亿华云除祈存在被恶意操纵投毒,祷程成为黑客 “帮凶” 的最新可能,并把安全风险散播给每一位使用了它配置文件的叛变无辜程序员 。

(Pillar Security在报告中分析的除祈黑客投毒流程)
AI发展越来越快 ,从最初的简单对话,到后来图片识别 、艺术创作,到现在的深度推理,短短两三年,人们对AI的应用愈发全面和得心应手。高防服务器但,驾驶中的汽车 ,车速越快,人对方向盘掌控力越弱。
那飞速发展中的AI呢,人类对它是否掌控依旧 ?它会一直听话,为我们所用吗 ?
我们AI编程安全团队 ,对AI助手“叛变”一风险进行了深度研究,并在沙箱环境中,复现了AI助手叛变的全过程。隐秘之下,AI助手已经偷偷撕毁了和人类的源码库安全协议。
配置文件(rule files)是AI编程助手中常用的一种规则文件,包括了高质量prompt、一些配置规范参数等,简单来说就是类似于“预设”一类的东西。以cursor为例,程序员对它提出编程要求后,只要叠加了配置文件,就可以让cursor输出更规范、更高质量的免费模板代码。
同时人人都可以编写自己的配置文件并分享 ,也选择去社区中拿别人编写的更优秀的“预设”来使用。
2. 配置文件投毒过程前文有提到,配置文件里包括了高质量prompt,并且配置文件可以在各大社区流通供程序员下载,众所周知 ,哪里有文件流通,哪里就有黑客。
在这类场景下 ,黑客把恶意提示词通过unicode不可见字符,嵌入到配置文件中正常的prompt中,服务器租用就可以创建出一份“黑化”的配置文件。
接着 ,黑客把这份已经黑化的配置文件发布到开源社区 ,有AI编程需求的程序员会进行下载 。
但他们没办法察觉到这份配置文件已经被投毒 ,因为在GitHub中查看这份文件 ,是看不出有异常的:

(通过Github编辑器查看恶意配置文件)
把配置文件下载到本地后 ,毒会自动保存在指定项目文件夹的隐藏目录中 ,也无法察觉。
但此时cursor已经加载了这份“黑化”的建站模板配置文件。

(Cursor设置页面-自动加载恶意配置文件)
就这样,被投毒的配置文件潜入到程序员的电脑中,程序员用这份有毒的配置文件进行日常代码编写,但无人察觉其中异样。
特别声明:本文仅做了投毒可行性验证 ,并没有在公开社区发布任何恶意投毒配置文件
曾经,程序员是写代码的“创造者”;如今,程序员也可能成为风险的“传播者”。
当一个被投毒的配置文件悄无声息地融入开发流程,看似一行行干净规范的代码 ,其实早已布满陷阱——你以为你在写系统,其实你在为黑客铺路。
1. XXE风险 :数据泄露的隐形炸弹XXE(XML External Entity)攻击 ,本是老掉牙的攻击方式,但配合AI配置文件的“黑化”,它的威胁再次升级 。
程序员可能只是通过AI助手生成了一段处理XML的代码,结果却引入了未经过滤的外部实体引用 。它可以访问本地文件 ,甚至直接窃取服务器敏感数据 。漏洞之门,由你亲手打开 。
2. DDoS风险:你帮别人挡子弹,也帮别人开炮当你以为AI助手帮你写的是一个接口优化脚本,实际上 ,它在你看不见的地方 ,生成了可被批量调用的HTTP请求触发器 。系统上线后 ,只需黑客一句话 ,成千上万个这样的“陷阱接口”同时发起请求,DDoS攻击便水到渠成 。
而你,不过是那个把导火索亲手安进系统的人。

有的黑客不图偷数据 、不想炸服务器 ,他们图的是CPU 。AI助手在“黑化配置文件”指引下,悄悄注入一段JS代码 。它不会破坏你的系统,也不会报警,它只在后台默默运行 ,把你的用户设备变成“矿机”。
用户觉得网页卡 ?系统响应慢 ?你以为是性能问题,其实你在替人挖矿 。
4. 用户数据泄露:AI篡改逻辑 ,窃取隐私更严重的是,AI可以修改你的表单验证逻辑 、篡改输入校验 ,把用户的输入信息通过加密通道回传黑客服务器。你写了个公司内网系统,交付给HR、财务 、老板使用 ,结果上线第一天 ,所有员工的账号密码 、身份证、工资明细就全被“同步备份”到了黑客邮箱里。
而你,依旧一无所知 。

AI助手可能帮你写了一段“高效加载外部资源”的代码,嵌入在按钮或图表加载逻辑中,看似提升用户体验,实际上是调用了黑客服务器上的木马脚本 ,一旦用户点击,即中招 。
你没有上线病毒,但你上线了病毒感染的“邀请函” 。
“工具是中立的”,但一旦掌控权旁落,中立的工具也能变成利刃 。
AI助手一旦被“策反” ,再有经验的程序员也难以靠肉眼识破代码中的“投毒”。要想自保,必须从意识 、机制 、工具三方面 ,构建完整防线 :
(1) 远离来历不明的配置文件
不轻信开源社区的“热门配置文件”,特别是未经过官方验证的。下载前 ,用文本编辑器查看所有内容,注意是否存在看不见的Unicode字符。使用Diff工具对比文件版本 ,警惕多余的prompt或加载逻辑。(2) 配置沙箱环境 ,隔离AI生成代码
在本地或云端搭建专门的测试环境,仅用于运行AI生成代码 。每段代码上线前 ,必须先在沙箱中跑过一遍 ,检测是否存在异常行为或多余网络请求 。(3) 使用静态分析工具+AI反向验证
通过自研静态分析工具和AI工具,能捕捉潜在的安全逻辑漏洞 。将AI助手生成的代码,交由另一个AI做“反向审查”,看看是否识别出不合规的部分。(4) 我们团队的能力开放中
作为专注AI编程安全的团队 ,我们正在开发针对AI助手代码的“行为分析引擎” ,可以实时检测和拦截AI生成的高危指令。目前 ,该工具正在进行内测阶段 ,未来将开放给部分合作方及高校技术团队使用。编程软件投毒事件,只是揭开了AI代码安全的冰山一角 。人类的第一次工业革命靠的是蒸汽机,这一次的AI革命 ,靠的是我们对“风险”的认知力。
当AI不再听话时 ,写代码的每一行 ,都可能是向系统投下的第一颗炸弹。
别等系统崩了 、用户数据被卖了 、公司被搞了,才开始思考 :“AI怎么能这样?”
是时候回过头问问自己:我有没有把武器交到敌人手里 ?
未来 ,期待看到更多先进的技术和理念应用到 AI 编程安全领域 ,期待更加完善的法律和监管体系出台,也期待开发者和用户的安全意识不断提升 。相信在安全各界共同努力下,能构建一个更加安全可靠的 AI 编程环境,在技术红利与风险间,为程序员们寻找到最适宜的平衡点 。