LLM 成了 Web 漏洞的传声筒，这让传统的攻击链路变得诡异了

很多人盯着 Prompt 注入本身看，觉得顶多就是让 AI 说两句脏话或者跳出角色设定，但如果把 LLM 接到后端 API 或者数据库里，它其实成了一个极其高效的“漏洞中转站”。一个很反直觉的点是：LLM 本身并不创造漏洞，它只是个传递者。但正因为它在中间起到了中介作用，很多原本被防御墙挡掉的恶意输入，经过 LLM 的“加工”后，反而能以一种被后端信任的格式传给服务器，从而触发经典的 Web 漏洞。

这种现象可以理解为 LLM 成了个“被搞糊涂的代理人”（Confused Deputy）。比如你给 AI 一个指令，它把这个指令转成了 SQL 语句传给数据库，如果后端太信任 AI 生成的内容而没做过滤，那么 LLM2SQLi 就成了现实。

根据目前的分析，这种 LLM 介导的攻击路径覆盖面极广，主要能分为这几种变体：

• LLM2SQLi / LLM2CommandInjection：攻击者通过诱导 LLM 生成包含恶意片段的查询语句或系统命令，直接击穿后端数据库或服务器。
• LLM2XSS / LLM2SSTI：利用 LLM 输出的内容被直接渲染在前端页面或模板引擎中，导致脚本执行。
• LLM2SSRF / LLM2XXE：诱导 LLM 触发后端的 HTTP 请求或 XML 解析，从而探测内网资产或读取敏感文件。
• LLM2IDOR / LLM2CSRF：通过操控模型生成的请求参数，实现越权访问或伪造用户操作。

有个叫 TicketOracle 的 Flask 实测案例很有意思，它专门测试 LLM2SSRF 在不同模型上的表现。结果发现，不同大模型被“利用”的概率完全不一样。这意味着即便应用架构一样，换个模型，漏洞被触发的概率可能就变了。这说明安全不能只靠在 Prompt 里写“你是一个安全的助手”，得从网络层、应用层和模型层同步打补丁。