基于大语言模型的智能合约自动化漏洞注入

Automated Vulnerability Injection in Smart Contracts Using Large Language Models

arXiv: 2609.02624v1

论文信息

标题: Automated Vulnerability Injection in Smart Contracts Using Large Language Models

作者: Luca Migliaccio, Roberto Natella, Naghmeh Ivaki, et al.

发布日期: 2026-09-02

arXiv ID: 2609.02624v1

PDF 链接: 下载 PDF

3 分钟速览

  • 研究问题：这篇论文要解决智能合约漏洞检测工具评估中带已知漏洞标签的数据集稀缺、难以手工扩展的问题。
  • 核心方法：用两个开源大语言模型（LLM）分别完成 “漏洞可注入性评估” 和 “漏洞注入”，再经过编译执行、注入核查、业务逻辑保持、漏洞确认四步验证。
  • 关键结果：在 14 个真实合约、49 个 OpenSCV 漏洞类型下，去重后的 193 个候选合约只有 32 个通过全部验证，生存率 16.58%。
  • 主要局限：验证主要依赖单名人工评估者；评估准确率只在 108 个决策样本上测得；静态分析工具在 legacy Solidity 代码上大量失败；注入多样性有限。
  • 适合读者：智能合约安全、漏洞检测工具评估、LLM 应用于安全测试或数据集构建的研究与工程人员。

论文背景和研究动机

智能合约一旦部署到区块链上就不可篡改，源码漏洞可能被直接利用并造成经济损失。因此，开发者需要依赖自动化检测工具作为上线前的保障。然而，评估这些工具需要带真实漏洞标签的数据集，而现有数据集通常规模小、手工维护、覆盖漏洞类型有限，难以扩展。

论文指出，软件故障注入在传统系统评估中已被用于生成已知缺陷，但在智能合约领域仍不成熟。已有方法如 SolidiFI、MuSe、SGDL 等多使用固定模式或模板，覆盖漏洞类型少，且缺少对 “业务逻辑是否被破坏” 的系统验证。作者试图利用 LLM 的代码理解和生成能力，在真实 Solidity 合约中进行局部修改，构造带确定漏洞标签的变体，以缓解数据集稀缺问题。

核心方法和技术细节

该方法分为三个阶段。

准备阶段：从 SmartBugs 的 sb-wild 子集中筛选出 14 个无已知漏洞的真实合约，覆盖迁移、代币、银行、捐赠、彩票、支付阈值、基金管理等多种应用类型。模型选择上，评估模型使用 Qwen2.5-Coder 14B，注入模型使用 Meta-Llama-3 8B，两者均以量化方式运行在有限显存环境中（见论文第 IV-A 节）。目标漏洞类型为 OpenSCV 分类体系中带 SWC 编号的 49 种。

评估与注入阶段：评估模型对每个 “合约—漏洞类型” 对判断是否可注入，重复 10 次，并将可注入分数定义为

score(v,c)=true_count(v,c)n×100score(v,c)=\frac{true\_count(v,c)}{n}\times100

只有分数超过 50% 的漏洞类型进入注入阶段。49 种类型中有 25 种至少在一个合约上达到阈值。注入模型在每个通过评估的对上重复生成 10 次，提示中包含漏洞描述、约束和 Safe/Vulnerable 代码示例，要求只修改一个函数、不新增状态变量或函数，并用 // VULN HERE 标记修改行。生成 997 个候选，去重后剩余 193 个，约 80% 的原始生成是重复输出（见论文第 IV-B3 节）。

验证阶段：候选合约依次通过四步过滤：A. 编译执行；B. 注入验证，人工检查是否满足约束、确实注入目标漏洞；C. 业务逻辑验证，判断漏洞之外是否引入非预期的控制流或功能改变；D. 漏洞确认，确认缺陷在合约语境中语义有意义且可被利用。最终 150 个通过编译执行，89 个通过注入验证，44 个通过业务逻辑验证，32 个通过漏洞确认，生存率 16.58%（见表 IV）。

创新点和贡献

与已有漏洞注入工作相比，论文的主要区别在于：用 LLM 直接在原合约代码中进行局部修改，而不是插入固定片段或依赖 AST 模板；目标漏洞类型扩展到 49 种；验证管道明确包含业务逻辑保持检查。论文还实际使用验证后的数据集评估了三个静态分析工具，展示了数据集的用途。

贡献可归纳为四点：一是提出带四步验证的 LLM 漏洞注入方法；二是通过案例研究刻画影响注入成功的因素；三是展示该数据集可用于分析静态分析工具的覆盖特征；四是总结模型非确定性、验证瓶颈、注入多样性和 legacy 工具限制等实践教训。这些贡献在工程上是对现有智能合约漏洞数据集构建路径的补充，但论文并未声称全面优于既有方法。

实验结果分析

评估阶段的手工抽样验证中，LLM 在 108 个决策样本上达到 75.9% 的准确率，95% Wilson 置信区间约为 [67.3%, 83.2%]；精确率高（95.5%），但召回率较低（73.6%），即误报少、漏报多。作者认为这种保守倾向对管道是有利的，因为误报会把不现实的漏洞类型送入注入阶段。

注入与验证阶段，997 个原始生成去重后仅 193 个，多样性收敛明显。32 个最终通过验证的合约集中在较简单的合约和 Checking 类缺陷上。论文将 25 种通过评估的漏洞类型按缺陷分类，Checking 类占 11 种，且在验证中存活率最高；Algorithm/Method 等更结构性的类型存活率较低（图 14）。在合约复杂度上，低代码行数、低圈复杂度的合约存活率明显更高，业务逻辑验证是最大瓶颈（图 13）。作者推测，复杂控制流使在不影响其他行为的前提下注入漏洞更难。

在静态分析工具比较中，32 个验证后合约里有 13 个因 legacy Solidity 版本导致工具失败，只剩 19 个可分析。在该可分析子集上，Slither 精度 1.000、召回 57.9%；Solhint 精度 0.857、召回 70.6%；Remix 精度 0.786、召回 0.688（表 VI）。仅 9 种注入漏洞类型被至少一个工具检测到，说明工具覆盖互补但不完整。这些结果是基于 19 个合约的小样本观察，论文也将其定位为探索性而非工具排名。

实践建议

从论文的实践教训出发，构建类似漏洞数据集时有几点值得注意。

第一，可注入性评估应作为过滤步骤，而不是成功保证。即使评估分数高，后续验证仍可能因业务逻辑破坏而失败。中间检查点比单纯优化注入提示更有价值。

第二，业务逻辑验证是最大成本点，也是最适合自动化的环节。论文建议通过差分测试比较原合约和注入合约在非脆弱路径上的行为，减少人工检查负担。漏洞确认和约束合规检查较难自动完成，可先尝试 LLM 辅助审查。

第三，数据集的缺陷类型分布会偏斜。本文中 Checking 类漏洞最适合局部注入，因此最终数据集更多覆盖该类。这意味着用该数据集评估工具时，不能把结论直接外推到 Algorithm/Method 等更结构的缺陷类。

第四，增加生成次数对多样性提升有限。LLM 在固定约束下容易收敛到相似输出，论文的 997 次生成去重后仅剩 193 个候选。作者将温度变化、提示扰动和多模型集成列为未来方向，但尚未在本工作中验证其效果。

第五，评估真实合约时需要考虑 legacy Solidity 兼容性。论文中 13 个验证后合约无法被静态分析工具处理，错误同样出现在原版合约上，说明这是工具对旧语法和旧编译器的固有限制，而不是注入方法导致的问题。