复旦白泽战队 10月29日 21:10
智能体应用安全研究:漏洞现状、成因与开发者困境
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

复旦大学研究深入剖析了智能体应用的安全现状,发现其漏洞普遍且严重,CVSS平均分高达7.89,74.1%为高危或致命级。研究指出,注入型漏洞,特别是代码注入,是智能体应用中最普遍且危害最大的漏洞类型。漏洞根源多与大模型输出未经过滤直接传递给敏感工具、RAG模块处理不当以及对不可信外部资源过度依赖有关。开发者在修复漏洞时面临安全与功能间的艰难权衡,如Langflow、LlamaIndex等项目开发者就因难以设计可靠防护、功能影响等问题而犹豫。缓解策略包括安全警示、功能下线、规则过滤等,但近半数漏洞未被有效修复,缓解有效性仅为73%,暴露出当前缓解措施的不足。

🚨 **严峻的漏洞态势与主要威胁:** 智能体应用面临着普遍且严重的漏洞问题,平均CVSS评分高达7.89,超过七成被评为高危或致命。其中,注入型漏洞,尤其是代码、命令和SQL注入,是危害最严重的类型,代码注入更是智能体应用中分布最广、最危险的漏洞。这严重阻碍了智能体应用的规模化落地。

🛠️ **多样的漏洞根因与开发者权衡:** 智能体应用中的独特漏洞根因主要集中在工具模块集成不当、大模型输出未过滤直接传递给工具、RAG模块处理多样化数据时忽视安全隐患,以及对不可信外部资源的依赖。开发者在修复这些漏洞时,常需要在保障安全与维持功能之间做出艰难的权衡,例如担心修复代码执行漏洞会影响智能体正常功能。

⚖️ **缓解策略的挑战与有效性困境:** 开发者普遍采取了安全警示、功能下线、规则过滤等多种缓解策略,其中“规则过滤或检查”因成本效益高而最为常见。然而,研究发现近一半的漏洞未被正确缓解,即使采取了实质性措施,缓解有效性也仅为73%。这主要归因于弱缓解措施的过度依赖、过滤规则易被绕过,以及将安全责任转移给用户配置等问题。

💡 **未来发展方向与责任划分:** 智能体的开放式设计模糊了漏洞与正常功能的边界,需要政府与行业合作制定标准,明确安全内涵与主体责任。开发者应转向开发功能明确、边界清晰的细粒度工具,并重视配置安全,开发辅助工具帮助用户生成兼顾安全与功能的配置建议,同时对高风险设置进行告警。

原创 申卓祥,黄宗安 2025-10-29 13:45 上海

近日,复旦大学系统软件与安全实验室的最新研究对智能体应用当前的漏洞现状、漏洞根因以及开发者的缓解实践进行了系统性地评测调研,揭示了智能体应用当前漏洞态势的严峻性,以及开发者在漏洞缓解过程中对于安全和功能的艰难权衡。

前言

近年来,各种各样的智能体应用蓬勃发展,与此同时也曝出了大量的漏洞和安全问题。但是到目前为止,人们对于智能体应用的漏洞及其缓解策略的特点还缺乏深入的理解。近日,复旦大学系统软件与安全实验室的最新研究《Security Debt in LLM Agent Applications: A Measurement Study of Vulnerabilities and Mitigation Trade-offs》对智能体应用当前的漏洞现状、漏洞根因以及开发者的缓解实践进行了系统性地评测调研,揭示了智能体应用当前漏洞态势的严峻性,以及开发者在漏洞缓解过程中对于安全和功能的艰难权衡。论文已被软件工程领域著名学术会议ASE 2025(International Conference on Automated Software Engineering,CCF-A)录用(点击“阅读原文”可获取论文PDF)。

Part.1

智能体应用的漏洞现状

我们收集了GitHub上评分最高的50个智能体应用的所有公开漏洞,并将它们分成了14个漏洞类型。根据我们的评测,智能体漏洞的CVSS平均分高达7.89,且有74.1%的漏洞被评为高危和致命级,说明智能体漏洞态势严峻,这将严重阻碍智能体应用的大规模落地推广。

另外,我们还从每个漏洞类型的视角评估了漏洞分布和严重性,我们发现注入型漏洞(代码/命令/SQL)是智能体应用中危害最严重的漏洞类型。尤其是代码注入,既是智能体应用中分布最广泛的漏洞类型,也是最严重的漏洞类型,具有极高的研究价值。

Part.2

智能体应用的典型漏洞根因

在本文中,我们聚焦于仅出现在智能体上下文中的独特漏洞根因,旨在理解其新型利用方式。我们依据当前主流的软件工程实现,将智能体划分为7个功能模块,并按漏洞触发位置对漏洞机理进行分类,共归纳出16类漏洞根因。其中,工具模块是漏洞触发最多的部分,原因在于智能体集成的工具常涉及敏感操作,如代码执行、命令运行、网页爬取和文件读写等,若执行不当可能引发严重安全问题。

大模型输出未经有效过滤便直接传递至工具,是智能体应用中最常见的漏洞根因。以LlamaIndex的NLSQLRetriever模块(CVE-2024-23751)为例,该模块通过提示词模板将自然语言查询转换为SQL语句,但生成的SQL未经进一步过滤即传入数据库执行。若攻击者通过提示词注入诱导模型输出恶意删除语句,将破坏数据库完整性。

由于大模型输出缺乏安全保证,攻击者可利用提示词注入等手段诱导其生成恶意载荷,并进一步传入敏感工具内部,控制工具执行恶意操作。这是智能体应用中极具代表性的一类攻击向量。

RAG模块在构建知识库时需处理来源多样、格式不一的数据,开发者易忽略其中的安全隐患。以LangChain的SitemapLoader为例(相关漏洞:CVE-2023-46229、CVE-2024-2965),该模块通过解析sitemap.xml获取网页导引信息,但攻击者可篡改此文件,引发SSRF与DoS风险。若sitemap.xml被插入内网地址,智能体可能通过SSRF将内部资料导入知识库,导致信息泄露;此外,网站地图允许嵌套引用,恶意构造的递归指向可引发无限循环,造成服务拒绝(DoS)。

智能体应用的高效运行非常依赖外部资源,然而其来源并不可信。攻击者不需要与智能体应用主动交互,只需要将恶意的攻击载荷部署在外部资源中,等待智能体主动请求这些资源。针对智能体应用的这种被动、间接的攻击方式给审计和取证带来了新的难题。

Part.3

开发者对漏洞的态度

我们对开发者社区处理新型漏洞的态度进行了调研,并将其分为四类:无反应、有反应但无实质措施、低优先级缓解(处理超60天)及高优先级缓解(处理≤60天)。结果显示,超过60%的漏洞被列为高优先级缓解,平均缓解时间为30.3天,表明多数开发者愿意承认并积极修复漏洞。 然而,仍有近三成漏洞未获实质性修复。为此,我们收集了开发者的反馈,得到了一些有意思的发现:Langflow开发者认为,代码执行工具难以设计可靠防护来应对各种攻击绕过,安全责任应在部署系统的管理员而非开发者,管理员须确保访问用户的可信;LlamaIndex开发者指出,Text-to-SQL功能本身就一定会使SQL语句外部可控,开发者拒绝承认存在SQL注入漏洞,并取消了相关赏金计划,认为数据库安全应由使用者通过权限管理保障;MetaGPT开发者则担忧,修复代码执行漏洞可能影响智能体正常功能,强调需在安全与可用性之间权衡。综上,缺乏可靠修复方案、安全与功能的平衡争议以及安全责任归属分歧,是开发者在缓解智能体漏洞时的三大主要顾虑。

Part.4

开发者采取的漏洞缓解策略及其有效性

我们对开发者的漏洞缓解策略进行了归纳,总结为以下六类:

安全警示在文档或运行界面中提示风险。

迁移实验包:将有风险的模块移至实验包,声明不保障其安全性。

功能下线:直接移除存在风险的功能。

规则过滤或检查:通过黑白名单识别或无害化恶意载荷。

隔离环境将执行环境与物理系统隔离,限制影响范围。

替换最佳的实现方式:重构代码,从设计层面消除安全问题。

开发者常对同一漏洞采取多种策略。其中,“规则过滤或检查”最为常见,因其实现代价低、安全收益较高,被视为性价比较高的选择。然而,从安全研究的角度看,这些缓解措施是否真正有效?我们通过统计发现:智能体应用中近一半漏洞未被正确缓解;即使在已采取实质措施的案例中,缓解有效性也仅为73%。这反映出当前漏洞缓解整体效果仍不理想。

缓解效果不佳的主要原因包括:过多依赖“安全警示”“迁移实验包”等弱缓解措施以及所设置的过滤规则容易被绕过。此外,存在一种特殊缓解状态:开发者提供配置接口,将安全规则的定义权交给用户。尽管我们将此类情况暂归为“正确缓解”,但这实质是将安全责任转移至部署阶段。用户是否具备足够安全意识进行正确配置,仍需打上一个问号。

Part.5

开发者缓解漏洞面临的两难困境

开发者并非不知道自身缓解措施的不完善。以LangChain的PALChain模块为例,其困境颇具代表性。该模块通过执行大模型返回的Python代码进行逻辑推理,最初因无任何安全限制,被曝出可执行恶意系统命令(CVE-2023-36258)。开发者随后采用AST过滤,限制危险包导入与方法调用。然而,该防护先后被__import__()绕过(CVE-2023-44467)及利用Python自省机制间接引用敏感包的方式突破(CVE-2023-27444)。开发者虽不断将新攻击模式加入黑名单,但最终不得不承认:即便持续修补,仍无法确保彻底安全。

开发者面临两难:若采用黑名单规则,未来可能不断出现新绕过方式;若改用白名单,又会限制智能体的功能,损害其开放性的核心价值由于开放式功能模块难以明确定义漏洞与正常功能的边界,开发者在安全与功能之间难以取舍。在此现实下,社区形成了一些当前可接受的安全实践:

迁移实验包将有安全问题但缺乏共识缓解方案的模块移至实验包,由用户自行评估风险后使用,如LangChain、LlamaIndex等项目已采用此方式。

提供容器化部署选项提供容器选项以隔离代码执行环境,即便规则被绕过,也可控制影响范围,但该方式存在性能开销与场景适配等局限。

提供更灵活的安全配置接口将安全规则配置权交给用户,适应不同需求,但前提是用户具备足够安全意识并能正确配置。

这些实践虽各有不足,却是当前多方可接受的折中方案。未来仍需推动更优安全方案的探索与共识形成。

Part.6

启示

智能体的开放式设计哲学让软件漏洞与正常功能的边界变得模糊这一根本矛盾在于:为提升竞争力,智能体需被赋予更强能力与更高权限;而安全原则要求最小权限和风险控制,任何新增权限都会扩大攻击面。目前如何在安全与功能间权衡尚无共识,需政府与行业合作制定标准,明确各场景安全内涵与主体责任。开发者应避免设计过于通用的工具(如通用代码执行),转而开发功能明确、边界清晰的细粒度工具,便于后期实施精准权限控制。

资源管理的复杂性显著扩大了智能体应用的攻击面。特别是随着MCP等技术的兴起,功能模块进一步解耦,资源管理更趋复杂。未来需开发资源测绘方法与工具,系统梳理潜在攻击入口,以支持针对性测试与漏洞检测。

容器化虽为当前有效实践,但存在局限:多租户场景下资源限制导致隔离不足;不适用于需持久化修改系统的场景(如Text-to-SQL、端侧Computer-use智能体);容器的权限分配仍面临安全与功能的取舍。因此容器并非终极方案,需持续探索更优解。

需重视智能体应用在实际部署中的配置安全。开发者将配置权限下放给用户,实则转移了安全责任。为避免用户因安全意识不足导致配置风险,应开发辅助工具,根据使用需求生成兼顾安全与功能的配置建议,并对高风险设置及时告警。

作者介绍

申卓祥,复旦大学22级博士生,导师为张源教授和戴嘉润副研究员。主要研究方向为智能体应用生态安全。

供稿:申卓祥

排版:黄宗安

责编:邬梦莹

审核:戴嘉润、洪赓、张琬琪、林楚乔

复旦白泽战队

一个有情怀的安全团队

还没有关注复旦白泽战队?

公众号、知乎、微博搜索:复旦白泽战队也能找到我们哦~

阅读原文

跳转微信打开

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

智能体应用 AI Agent Security 漏洞研究 软件工程 复旦大学 安全与功能权衡 Vulnerability Research Software Engineering Fudan University Security-Functionality Trade-off
相关文章