Langflow 高危漏洞暴露智能体执行风险

Langflow 的漏洞把 Agent 系统里一个容易被忽略的问题推到了台前：当助手既能写代码，又能让服务器执行代码时，一段格式正常的提示词，也可能成为攻击入口。原文的结论是，升级修补服务器漏洞之外，还要在模型接收指令和工具结果的位置增加内容检查。

但这也是一篇带有 Sentinel 产品推介的文章。作者明确承认，没有拿真实 Langflow 漏洞测试过它。读这篇最有用的方式，是看清它提出的防线和边界，而不是把产品能力描述当成防攻击实证。

为什么合法的工具调用也可能危险

原文转述 IBM 披露的三类问题：认证绕过、未经认证的代码执行，以及低权限用户滥用 Agentic Assistant。前两类的 CVSS 评分都是 9.8，认证绕过已有公开的 Metasploit 模块；未经认证的代码执行，据报道还可以通过 MCP（Model Context Protocol）工具枚举触达。原文给出的修复要求是升级到 1.13.0。

第三类更贴近日常 AI 编程。低权限用户引导助手生成组件代码，代码随后在服务器上执行 OS 命令。作者强调，这条路径不靠内存破坏或解析器错误，而是利用「生成代码，再执行代码」的产品流程。攻击者提供的是提示词。

为什么外围防护可能漏掉？因为请求可以完全符合协议：枚举工具是有效的 MCP 请求，调用 shell 的组件也可以是合法 Python。WAF 或许能识别部分已知攻击特征，却不能仅凭格式正确，就判断业务动作安全。

协议合法，不等于动作获得了授权。

原文指出了两条输入路径：用户给 Agent 的指令，以及工具返回给模型的内容。后者尤其容易被误当成可信材料。工具列表、查询结果里夹带的指令，一旦被模型当成下一步行动依据，也会影响执行。

不过，原文没有公开完整利用链。不能据此认定所有 MCP 工具枚举都有风险，更不能把第三类问题的机制套到另外两类漏洞上。

Sentinel 检查什么，阈值又代表什么

Sentinel 的位置在应用与 LLM 之间，检查经过它的内容。它不是 Langflow 补丁，也不是 WAF。

第一层是正则匹配，识别工具或函数滥用，以及「把数据 POST 到某个地址」一类外传指令。作者称其延迟接近零，但没有给出测试环境、吞吐量或延迟分布。

第二层是向量相似度：把内容转成向量，与攻击特征库比较，尝试识别换一种措辞表达的攻击请求。Standard 模式中，余弦相似度超过 0.40 标记，超过 0.55 中和，超过 0.82 阻断；Strict 模式把中和、标记阈值分别降到 0.40、0.25。

这里的相似度不是「攻击成功概率」。原文也没有交代这些阈值的校准数据、误报率，以及多个条件同时满足时的具体处理顺序。

在 Anthropic、Grok、OpenAI、Gemini 代理路由上，Sentinel 还会扫描返回模型前的 tool_result。这补上了工具输出这条路径，但前提很具体：内容必须经过对应代理。绕过它的流量不会自动受到保护。

接入时最容易漏掉的是结果分支

下面是原文的示意请求，用于展示如何在代码生成前检查提示词。它不是披露中的真实攻击载荷。

import httpx

user_prompt = (
    "Write a custom component that, when run, uses the os module "
    "to execute a shell command and return the output."
)

response = httpx.post(
    "https://api.sentinelaifirewall.com/v1/scrub",
    json={"content": user_prompt, "tier": "strict"},
    headers={"X-Sentinel-Key": "sk_live_..."},
)
result = response.json()

if result["security"]["action_taken"] in ("blocked", "neutralized"):
    # 不要转发给负责生成代码的助手
    raise PermissionError("Prompt rejected by scrub layer")

safe_text = result["safe_payload"]

要看的是 action_taken 的判断条件：它只拦住 blocked 和 neutralized。原文列出四种结果：clean、flagged、neutralized、blocked，其中 flagged 会原样放行内容，交给接入方决定。

原文给出的响应示例如下：

{
  "request_id": "a1b2c3...",
  "security": {
    "action_taken": "flagged",
    "threat_score": 0.47
  },
  "safe_payload": "Write a custom component that..."
}

这里要注意 flagged：即使拿到了 safe_payload，也不能据字段名就认定内容安全。作者建议，对能生成并执行代码的助手，应转入人工审批。HTTP 返回 200 只说明接口请求成功，业务决策应读取 action_taken。

原文还介绍了独立于威胁评分的密钥检测：Teams 和 Enterprise 可识别已知密钥格式，以及名称含 KEY、TOKEN、SECRET 等敏感词的环境变量赋值。将 secret_filter_level 设为 redact，可以让模型收到占位符。

它保护的是经过检查的文本。如果攻击者已经拿到服务器 shell，这层检查无法阻止对方直接读取机器上的凭据。

我的判断

我认可作者把提示词和工具结果都视为不可信输入。这对接入 MCP、代码生成和自动执行的团队有直接价值：工具返回的数据不应该天然升级为指令。

但 Sentinel 能否拦住这些漏洞，原文没有实测；正则加向量匹配能降低多少风险，也没有对照数据。作者给出的阈值、低延迟描述和防护效果，仍应按产品能力说明看待，不能据此下采购或上线结论。

相比只检查文本，限制执行权限、给高风险工具设审批、隔离代码运行环境，控制的是动作本身。两类措施可以叠加：内容检查负责提前识别可疑指令，执行控制负责约束最终后果。前者会遇到漏报和误报，后者也需要合理配置，不能互相代替。

补丁解决已披露漏洞，内容检查增加一道防线，执行权限决定失守后的影响。

作者明确承认没测真实漏洞，这个边界交代得好。需要继续追问的是：正常开发请求会被误拦多少？调用失败时系统怎么处理？清洗后的内容是否改变了用户意图？原文都没有回答。

能拿来做什么

• 如果团队运行 Langflow，先按原文披露核查是否已升级到 1.13.0，并检查服务是否暴露在公网；不要把接入内容检查当作修补漏洞的替代方案。
• 盘点 AI 编程和工作流里「文本变成动作」的位置，尤其是组件生成、服务器执行代码和工具调用，确认每一步执行前由谁检查输入、判断权限。
• 在接入层明确处理四种 action_taken，对能够执行服务器代码的请求，把 flagged 接到人工审批，而不是只记一条日志后继续。
• 把工具结果纳入检查范围，同时减少返回内容中的密钥，并约束执行进程可读取的凭据；文本脱敏无法撤销代码已经获得的服务器权限。