Skip to content
ToLO Knowledge Base

Public CVE Case Studies

本节只使用公开来源中的已披露信息,例如 NVD、MITRE、GHSA、厂商 advisory 和项目 release note。

案例复盘的目标是训练 ToLO 判断,而不是复现攻击。每个案例都应被压缩成同一个分析模板:S_LLM source、传播转换、危险 sink、缺失或新增的 C_SAFE guard。这样不同项目、不同 CVE、不同 CWE 才能放在同一张图里比较。

这一页的结构

  1. 先修概念:CVE 不等于学习结论
  2. 已收录案例清单
  3. 收录标准
  4. 案例页模板
  5. 版本口径核验规则
  6. 读完检查

先修概念:CVE 不等于学习结论

CVE 记录的是一个公开披露的安全问题。它会告诉你:

  • 项目、组件、版本
  • 影响(impact summary)
  • 参考链接(NVD / GHSA / 厂商 advisory / commit)
  • 分配的 CWE

但它不一定会按 ToLO 的方式解释 source、sink 和 sanitizer。例如:

  • NVD 给一个 LangChain 漏洞分配 CWE-94(Code Injection),但 description 可能只写”prompt injection allows attackers to execute arbitrary code”,没有指出source 是 S_LLM^framework 这个本质。
  • GHSA 可能写”add allow_dangerous_requests flag”,但没有解释这是 C_SAFE^capability 的 explicit-approval 变体。

所以本站读 CVE 时要做二次整理:把官方事实保留下来,把分析语言转换成 ToLO 的学习框架。若公开来源没有足够信息,就标 pending,不强行归类。

已收录案例

按 sink 子类组织:

ToLO-Exec(代码执行)

CVE项目一句话状态
CVE-2023-29374LangChain LLMMathChainLLM 生成数学表达式进入 PythonREPL / execpending
CVE-2023-36258LangChain PALChainProgram-Aided LM 生成 Python 代码后执行pending
CVE-2023-39631LangChain numexpr 变体LLM 表达式进入 numexpr.evaluatepending
CVE-2024-5826Vanna AI vanna.ask可视化路径执行 LLM 生成 Plotly 代码pending

ToLO-SQL(数据库查询)

CVE项目一句话状态
CVE-2024-8309LangChain GraphCypherQAChainLLM 生成 Cypher 查询进入图数据库pending

其他子类(待补充)

ToLO-Path / ToLO-SSRF / ToLO-Shell / ToLO-Deser / ToLO-Template 等子类的案例待持续收录。当前样本明显偏向 Exec / SQL,这是因为:

  1. PoC 容易演示 —— 这些子类直接 RCE,容易拿到 CVE。
  2. 静默修复多 —— Path / SSRF / Template 类问题经常没有 CVE 编号,只在 release note 里隐性修复。
  3. 教学价值的可核验门槛 —— 我们只收录有完整公开 advisory + commit 链的案例。

收录标准

案例进入本站前需要满足三个条件:

  1. 公开可核验:有 NVD、MITRE、GHSA、vendor advisory、project security advisory 或 release note 中至少一个公开来源。
  2. 路径与 LLM 输出有关:能说明 LLM output、agent action、tool args、parser result 或 workflow state 如何影响敏感操作。如果只是普通 HTTP 输入注入,不属于 ToLO 案例。
  3. 不提供攻击指令:复盘内容只描述边界、模式和修复思路,不提供可直接攻击真实服务的步骤。

若公开来源只说明”存在 RCE / SQL injection”,无法定位到 LLM output、agent action、tool args 或 parser result,则暂不写入 ToLO 案例。可以放入待核验清单,但不要把它硬归类。

案例页模板

每个案例页应包含:

段内容
public_sourcesNVD / MITRE / GHSA / advisory / PR / commit 链接,未核验前标 pending
affected_versions受影响版本(可能多个来源不一致)
fixed_in修复版本(可能多个来源不一致)
影响组件受影响模块、版本范围和相关功能
ToLO 路径source / transform / sink / guard 四列
教学骨架简化教学代码(不可直接复现)
修复方式上游如何收紧验证、隔离、默认配置或权限
研究启发它支持或挑战 taxonomy 中的哪一类

写案例页时避免两种过度:

  • ❌ 把 advisory 原文大段复制进站点(版权 + 教学价值低)。
  • ❌ 为了证明 ToLO 而补写未公开细节(不可核验)。

本站只做教育性摘要和模式化分析,所有细节都应能回链到公开来源。

版本口径核验规则

NVD、GHSA、release note 和 commit 经常不一致。处理规则:

情景处理
NVD 写 ”< 0.0.236”,GHSA 写 ”< 0.0.247”frontmatter 里保留两者,正文说明差异,verification: pending
NVD 提到 fixed_in,GHSA 未提以 NVD 为准,但脚注备 GHSA 缺该字段
commit hash 已查到,但未对应到具体 tagfixed_in: unknown,正文用”commit X 之后”
advisory 写了 CWE,但 description 与 CWE 不符以 advisory CWE 为主,正文说明 mismatch

冲突时保留差异,不强行选择。这是研究诚信的基础。

重点看什么(再展开)

  • 版本口径:NVD、GHSA、release note 和 commit 可能不一致。冲突时保留差异,标 pending。
  • source 证据:公开来源是否明确说明 LLM 生成内容、模型输出、agent action 或 tool argument 参与。
  • sink 证据:是否能对应到七子类之一,或者确实需要扩展 taxonomy。
  • 修复语义:上游是移除 sink、加 allowlist、加 capability、调依赖版本,还是只加 warning?
  • 残余风险:修复是否依赖调用方配置?例如数据库最小权限、显式 enable dangerous request?
  • 可重现性:复盘是否避免提供可直接攻击真实服务的步骤?

推荐阅读顺序

先读三个 ToLO-Exec 案例:LLMMathChain → PALChain → numexpr。它们能帮助理解”LLM 生成表达式 / 代码”为什么需要执行边界。

再读 Vanna AI 和 GraphCypherQAChain。它们展示了数据分析、可视化、图数据库问答这类高层功能如何把 LLM 输出送入执行或查询 sink。

读完后回到 ToLO 五类防御模式,对照每个案例的修复是否属于 schema、allowlist、parameterized、safe-codec 或 capability。

读完检查

一个案例是否适合本站,至少要能回答:

  • ✅ 公开来源是否存在?
  • ✅ LLM output 或 LLM-influenceable 数据是否参与?
  • ✅ sink 是否属于七类之一或值得扩展?
  • ✅ 页面是否避免提供可直接复现真实服务攻击的步骤?
  • ✅ 版本口径是否标 pending 或明确说明差异?

下一步阅读