文章总结： 这篇论文提出了ChainFuzzer，一个用于发现大语言模型（LLM）智能体中工作流级多工具漏洞的灰盒模糊测试框架。它通过自动提取工具间的数据流依赖、生成稳定的攻击提示词并验证漏洞，解决了传统单工具测试无法捕捉组合型攻击风险的问题。在20个主流开源LLM智能体应用上的评估显示，该方法共发现365个独特漏洞，其中82.74%需要跨越多个工具才能触发，证明了其在检测复杂安全风险方面的有效性，并为防御提供了输入约束、显式状态管理等建议。 综合评分： 95 文章分类： AI安全,漏洞分析,安全工具,解决方案,技术标准

【论文速读】|ChainFuzzer：LLM智能体中工作流级多工具漏洞的灰盒模糊测试

原创

知识分享者 知识分享者

安全极客

2026年3月19日 17:35 北京

基本信息

原文标题：ChainFuzzer: Greybox Fuzzing for Workflow-Level Multi-Tool Vulnerabilities in LLM Agents

原文作者：Jiangrong Wu, Zitong Yao, Yuhong Nan, Zibin Zheng

作者单位：中山大学，广东珠海

关键词：LLM 智能体安全、多工具漏洞、灰盒模糊测试、工具链、提示词注入、污点分析

原文链接：https://arxiv.org/abs/2603.12614

开源代码：暂无

论文要点

论文简介：随着大语言模型（LLM）被广泛部署为工具增强型智能体，其安全边界正在从模型本身扩展到由多个工具组成的复杂工作流。传统安全测试往往聚焦于单工具或单步骤的调用分析，而忽略了多工具组合带来的跨越式攻击路径。这篇论文正是瞄准了这一盲区——研究人员来自中山大学，提出了 ChainFuzzer，一个专为发现 LLM 智能体中”工作流级多工具漏洞”而设计的灰盒模糊测试框架。该系统能够自动提取工具间的数据流依赖，生成可稳定复现的攻击 Prompt，并在绕过 LLM 原生防护机制的前提下验证漏洞的可利用性，最终生成包含触发 Prompt、工具调用轨迹和副作用证据的完整 PoC（概念验证）报告。论文在 20 个主流开源 LLM 智能体应用上进行了大规模评估，共发现 365 个独特漏洞，其中 82.74% 需要跨越多个工具才能触发，表明单工具测试方法在实际部署环境中存在严重漏报风险。

研究目的：本研究旨在系统性揭示工具增强型 LLM 智能体中的工作流级安全漏洞。当一个智能体调用多个工具完成复杂任务时，某一工具的输出可能在后续步骤中作为另一工具的输入，形成跨工具的数据传播链路。攻击者可以通过污染早期工具的输出内容，使恶意载荷沿数据流传播至下游的高危操作（如命令执行、SQL 注入、服务器端请求伪造等），从而触发安全漏洞。现有工作多局限于单工具测试或单跳路径分析，无法有效捕获这类长链路、多步骤的组合型攻击。ChainFuzzer 的目标是弥补这一空白，为开发者提供可操作的漏洞证据，帮助诊断和修复工具链层面的设计缺陷。

研究贡献：本论文做出了三项核心贡献。

第一，研究团队首次系统性地识别并刻画了 LLM 智能体中的多工具漏洞类型，明确界定了攻击者影响的内容如何跨越工具边界传播并最终抵达高危操作的完整路径，为该领域提供了清晰的威胁模型。

第二，研究团队开发了 ChainFuzzer 灰盒测试框架，将三个核心模块——基于 Sink 的工具链提取、追踪驱动的提示词求解（Trace-guided Prompt Solving，TPS）以及感知防护机制的模糊测试——有机融合，实现了对多工具漏洞的可审计、可复现验证。

第三，论文在 20 个涵盖不同框架和部署场景的主流开源 LLM 智能体应用上进行了大规模评估，ChainFuzzer 在 19/20 个应用中共发现 365 个独特漏洞，以每百万 Token 发现 3.02 个漏洞的效率实现了高性价比的自动化安全测试。

背景与问题动机

在人工智能应用日益复杂的今天，LLM 智能体早已不满足于简单的问答交互，而是演变为能够调用网页搜索、文件系统、数据库、代码执行器等外部工具来自主完成复杂任务的自动化系统。一个典型的工作流可能如此运转：智能体接收用户请求，先通过 web_search 查找相关代码仓库，再通过 download 下载目标文件，接着用 write_file 将内容保存到本地，最后调用 run 命令执行代码——整个过程通过工具链的串联一气呵成。

然而，这种多工具协作模式在大幅扩展智能体能力的同时，也同步扩大了系统的攻击面。论文将核心威胁概括为”多工具漏洞”：当一个工具产生的数据被持久化（写入文件、存入数据库、写入缓存等），并在后续步骤中作为另一工具的输入重新被读取和使用时，攻击者若能污染早期工具的输出内容，恶意载荷便可沿着这条数据流传播链路，最终抵达具有高危副作用的操作——命令注入（CMDi）、代码执行注入（CODEi）、服务器端请求伪造（SSRF）、服务器端模板注入（SSTI）以及 SQL 注入（SQLi）。

更为隐蔽的是，这类漏洞往往只有在多工具协同执行的完整场景中才会显现。单工具测试可能会对每个工具单独评估并认为其安全，却完全无法捕捉到工具之间通过中间产物（URLs、文件、数据库记录）形成的跨步骤依赖链路所带来的组合型风险。研究人员在对现有安全研究文献进行梳理后发现，尽管单工具或单跳测试已有一定积累，但针对工作流级多工具漏洞的系统性发现方法几乎是一片空白，这正是 ChainFuzzer 要填补的研究缺口。

相关工作

在 LLM 系统漏洞研究方面，学界已积累了一定成果，但多集中于模型层面的安全性，例如训练数据提取、成员推断攻击、模型逆向以及越狱攻击。随着智能体框架开始大量调用外部工具，研究焦点逐渐转向执行时漏洞，涵盖直接与间接提示词注入、恶意插件利用以及通过工具调用触发的下游效应（如命令执行、SSRF、数据泄露）。近期工作还关注了 MCP（Model Context Protocol）工具生态系统中的寄生工具链攻击，揭示了内容摄取、隐私访问和出站通信工具组合使用可能导致的非预期隐私泄露。然而，这些工作大多仍局限于孤立的攻击场景或单步行为分析，缺乏一套系统性的工作流级漏洞发现与验证方法论。

在传统软件漏洞发现领域，模糊测试（Fuzzing）是一种成熟的自动化安全测试技术。覆盖率引导模糊测试、语法感知模糊测试以及符号/混合执行辅助的混合模糊测试都已在 Web 应用、系统软件、移动应用和 IoT 平台上取得了丰富成果。污点分析则是确认攻击者控制数据是否能够到达敏感操作的核心手段。ChainFuzzer 正是将这些经典思路迁移并适配到工具增强型智能体的特殊场景中——在这个场景下，漏洞往往来自多个工具的组合交互，而非单一 API 调用，这对工具链图的自动构建、可执行 Prompt 的生成以及防护机制下的载荷绕过都提出了全新挑战。

ChainFuzzer设计

ChainFuzzer 的整体工作流由三个相互衔接的模块构成，分别负责”发现可利用路径→生成可执行 Prompt→验证漏洞可利用性”的端到端闭环。

模块A：工具链提取（Chain Extraction）

这一模块的目标是从目标智能体的工具集中，找出存在 Sink（高危操作终点）的工具及能够向其传递攻击者影响内容的上游工具链。首先，ChainFuzzer 通过将每个工具的源代码与预定义的 Sink API 目录（涵盖命令执行、代码执行、网络请求、模板渲染和数据库操作五类）进行匹配，同时应用严格的后向数据流分析，确认 Sink 调用点的参数确实可被工具的输入参数影响，从而标识出”Sink 工具”。接下来，系统从每个 Sink 工具出发，向上追溯能够通过直接参数传递或间接中间产物（文件、数据库记录、检索索引等）向其提供数据的上游工具序列，构建候选工具链图。为过滤语义上不合理的工具组合，ChainFuzzer 引入 LLM 作为语义过滤器，判断候选链是否构成一个合理的用户任务执行流程。最终，在 20 个应用的 998 个工具中，系统识别出 199 个 Sink 工具，构建了 2388 条候选工具链，边精度达 96.49%，严格链精度达 91.50%。

模块B：工具链提示词生成（Trace-guided Prompt Solving，TPS）

即使找到了正确的候选工具链，也难以保证智能体会按预期顺序执行——LLM 本质上是非确定性的执行器，微小的 Prompt 变化就可能导致不同的计划选择、工具调用顺序甚至运行时失败。TPS 模块通过迭代反馈修复机制解决这一挑战：ChainFuzzer 以当前 Prompt 驱动智能体运行，通过插桩记录完整的执行轨迹（包含每步的思考过程、调用的工具、传入的参数、返回值及执行状态），然后由 LLM 约束生成器对比实际轨迹与目标链，生成描述失败原因的语义约束集合（涵盖缺失前置条件、参数绑定错误、格式不匹配、权限确认门控以及规划器绕路等类型），最后由 Prompt 求解器在受限的局部编辑空间内修订 Prompt 以满足这些约束，整个过程迭代至智能体能连续 5 次成功执行目标链为止。实验表明，TPS 将链可达率从 27.05% 提升至 95.45%（提升 68.40%），稳定 Prompt 比例从 9.50% 提升至 92.50%（提升 83.00%）。

模块C：模糊测试驱动的漏洞验证（Fuzzing-Driven Vulnerability Validation）

在链路可达且 Prompt 稳定之后，这一模块负责验证恶意载荷能否在真实防护机制下触发 Sink 处的高危副作用。注入点的选择基于目标链中第一个工具的数据来源类型：若第一个工具直接接收用户提供的内容，则测试用户来源注入（恶意载荷嵌入 Prompt 并通过工具参数传播）；若工具链涉及外部内容（如网页检索、文件读取、数据库查询），则测试环境来源注入（载荷注入工具返回值或外部资源中）。载荷类型根据 Sink 类型参数化：CMDi 使用 shell 命令字符串、CODEi 使用可执行代码片段、SSRF 使用内网目标 URL、SQLi 使用查询逻辑片段、SSTI 使用模板引擎表达式。当直接载荷被 LLM 原生防护机制拦截或削弱时，ChainFuzzer 对载荷进行变异——包括将载荷分片成多个看似无害的片段后期重组、对载荷进行编码（如 Base64）后依赖下游解释恢复、以及在保持工具所需语法的前提下扰动格式。这种变异策略将整体载荷触发率从 18.20% 大幅提升至 88.60%（提升 70.4%），对防护机制最敏感的 CMDi 和 CODEi 类型提升尤为显著（分别提升 76% 和 75%）。

实验评估

数据集与实验环境：研究团队从 GitHub 上按星数排名筛选出 20 个主流开源 LLM 智能体应用，要求每个应用至少拥有 2000 个 Star 且支持多工具工作流。数据集涵盖了 AutoGPT（182k stars）、LangChain（127k stars）、RAGFlow（73.3k stars）、MetaGPT（64.2k stars）、OpenClaw（198k stars）等业界广泛使用的框架，共 998 个工具，横跨不同技术栈和部署模式。实验将 GPT-5.1 作为智能体嵌入的目标 LLM，以提供最接近实际部署的测试环境；ChainFuzzer 本身的 LLM 相关模块（链提取、TPS、变异）则由 GPT-4o 驱动，以提供保守的性能下界。所有实验在配备 Apple M4 Max CPU 和 36GB RAM 的本地设备上运行。

总体结果（RQ1）：在对 20 个智能体应用的全量评估中，ChainFuzzer 识别出 199 个 Sink 工具，构建 2388 条候选工具链，生成 2213 个稳定可执行 Prompt，最终在 19/20 个应用中确认 365 个独特漏洞。其中，302 个（82.74%）需要多工具执行才能触发，仅 63 个属于单工具问题，多工具漏洞的发现量是单工具的 4.79 倍，有力证明了现有单工具测试方法在实际场景中严重低估了安全风险。从注入来源看，225 个（61.64%）由用户来源注入触发，140 个（38.36%）由环境来源注入触发。从 Sink 类型看，CMDi（121 个）和 SSRF（97 个）是最常见的漏洞类型，其中 SSRF 更多源自环境注入（外部内容中嵌入的 URL），而 CMDi 则更多源自用户来源注入（用户直接控制执行参数）。整个评估耗时 68 小时，消耗 120.80M Tokens，平均每个应用首次发现漏洞仅需 0.32 小时，综合效率达 3.02 个漏洞/1M Tokens。

消融实验（RQ3）：为量化各模块的贡献，研究团队进行了系统性消融实验。去除 ChainExtraction 后漏洞数从 365 骤降至 63（-302），覆盖的 Sink 类型从 5 种减少至 3 种，这充分说明绝大多数发现需要多工具组合才能实现，链提取是暴露跨工具数据流路径的关键前提。去除 TPS 后漏洞数降至 96（-269），表明许多提取到的工具链若没有经过 Prompt 稳定化处理，实际上无法被智能体稳定执行。去除变异策略后漏洞数降至 132（-233），但 Sink 类型覆盖依然保持 5 种，说明变异主要作用在于增加已可达 Sink 类型下的可确认实例数量，而非打开全新的漏洞类别。三个模块缺一不可，相互补充。

讨论与局限性

局限性：ChainFuzzer 存在两点局限。其一是漏洞可复现性依赖运行时环境——网络出口策略、沙箱权限和凭证可用性都可能影响某些链路的可执行性和 Sink 效果的可观测性，例如 SSRF 链路在出站请求被拦截或目标端点需要 Token 鉴权时可能无法触发。其二是系统在多个模块中依赖 LLM 推理，模型幻觉或能力局限可能阻止任意模块达到 100% 的准确率；研究团队在实验中使用 GPT-4o 以提供保守下界，若换用推理能力更强、幻觉率更低的新一代模型，ChainFuzzer 的整体效能预计会进一步提升。

防御建议：基于实验发现，论文提出了三项工程层面的缓解措施。第一，在 Sink 侧添加输入约束——危险工具不应接受自由格式字符串；例如对于 CMDi，将 run(cmd) 替换为固定命令模板加参数白名单验证，对于 SSRF，只允许请求预定义允许列表中的主机名和 URL 协议。第二，使跨工具状态显式且受控——值只能通过带来源元数据（生产工具、模式类型、来源标签）的类型化结构对象在工具间流转，下游工具只消费其声明字段，从而在维持正常多工具工作流的同时，防止非预期的数据复用（例如从网页抓取的字符串被隐式复用为 shell 命令）。第三，在调用 Sink 前实施轻量级数据流感知检查——标记来自用户输入或不可信外部内容的值，当此类值被用作 SQL 查询或模板字符串时，强制要求参数化或转义处理。

结论

这篇论文聚焦于现代多工具 LLM 智能体中一个此前被严重忽视的安全维度：工作流级漏洞。与孤立的单工具攻击不同，这类漏洞的形成需要多个工具在一次完整任务执行中协同触发，攻击者影响的内容通过文件、数据库记录、检索文档等中间产物在工具间传播，最终引爆高危操作。ChainFuzzer 构建了一套从工具链发现到漏洞验证的完整自动化测试范式，三个核心模块各司其职：链提取确定多工具 Sink 可达性、TPS 确定链路的可执行性与可复现性、变异机制则在防护机制下最大化漏洞确认率。在 20 个主流开源智能体应用上的大规模评估，不仅证明了多工具漏洞的普遍性（82.74% 的发现需要跨工具执行），也验证了 ChainFuzzer 的实用性和高效性。随着 LLM 智能体被越来越广泛地部署在企业级自动化场景中，工具链层面的安全审计将成为不可或缺的安全工程实践，而 ChainFuzzer 所提出的方法论为这一方向提供了重要的先行基础。

-End-

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：安全极客 知识分享者 知识分享者《【论文速读】|ChainFuzzer：LLM智能体中工作流级多工具漏洞的灰盒模糊测试》