如果你最近在用 LangChain 或 LangGraph 搭 AI Agent、工作流编排，或者内部问答系统，这条安全新闻最好别略过。

The Hacker News 在 2026 年 3 月 27 日 报道，Cyera 研究团队披露了 3 个会直接碰到企业敏感数据的漏洞。它们分别指向三种完全不同的数据暴露路径：

• 读主机文件
• 取环境变量里的密钥
• 翻 checkpoint 数据库里的历史记录

这三个洞放在一起看，危险不只是“某个库有 bug”，而是它们刚好踩在 AI 应用里最敏感的那几层基础设施上。LangChain 和 LangGraph 本身就是很多 Agent、RAG 系统和自动化工作流的中间层，一旦这些位置出问题，影响往往不会只停留在一个接口报错，而是可能直接外溢到：

• Docker 配置
• 云平台凭证
• 模型 API Key
• 历史对话数据
• 内部 prompt 模板
• CI/CD 配置和部署信息

按 The Hacker News 援引的数据，截至 2026 年 3 月下旬，LangChain、LangChain-Core 和 LangGraph 在 PyPI 上最近一周的下载量分别超过 5200 万、2300 万和 900 万。这意味着它们已经不是“小众 AI 框架”，而是很多团队默认会接进去的基础依赖。

说明：本文的新闻背景和整体风险描述，主要参考 The Hacker News 与 Cyera 的研究文章；具体受影响版本、修复版本和利用条件，以 LangChain / LangGraph 官方 GitHub 安全公告为准。

先把最关键的信息看完

这次涉及的 3 个漏洞可以先用下面这张表记住：

如果你对细节暂时没兴趣，只想知道现在该干什么，那最短答案就是：

• 升级相关包到已修复版本
• 检查有没有把不可信输入直接喂给 load_prompt_from_config()、load()、loads() 或 checkpoint 查询过滤器
• 把环境变量、checkpoint 历史和 prompt 配置都当成高敏感面重新审一遍

为什么这件事会比普通库漏洞更麻烦

AI 框架的危险点，往往不在“模型会不会胡说”，而在它们会不会碰到太多真实数据。

Cyera 这次的说法很直接：LangChain 这类框架承接的不是抽象文本，而是企业最真实的“管道”数据，包括：

• 环境变量中的密钥
• 持久化在 checkpoint 中的对话和状态
• 存在配置文件里的 prompt、样例和内部文档
• 给模型调用准备的云平台凭证

也就是说，这些漏洞打到的不是 UI 层，而是 AI 应用的数据中枢。

所以你会发现，这三类问题其实都不是 AI 特有的新型漏洞，而是大家很熟悉的老安全问题：

• 路径遍历
• 反序列化 / 序列化注入
• SQL 注入

真正值得警惕的地方在于，AI 应用把这些老问题重新带回来了，而且往往带着更多机密数据一起回来。

1. CVE-2026-34070：Prompt Loading 路径遍历，可读主机敏感文件

这是这次最容易理解的一类问题。

LangChain 官方公告写得很清楚：langchain_core.prompts.loading 里的多个函数，会从反序列化后的配置字典里读取路径，然后直接去磁盘上拿文件，但没有正确校验绝对路径注入或 .. 路径遍历。

受影响的主要是这些场景：

• load_prompt()
• load_prompt_from_config()
• 以及相关 prompt 类上的 .save() 旧接口

如果应用把用户可控的 prompt 配置对象传进去，攻击者就可以通过这些字段去读文件：

• template_path
• suffix_path
• prefix_path
• examples
• example_prompt_path

LangChain 官方给出的影响范围也很直白。虽然它只允许读特定扩展名，但这些扩展名本身就已经够危险了：

• .txt
• .json
• .yaml
• .yml

换句话说，攻击者未必能把整个磁盘都拖走，但完全可能拿到这类现实里最常见的敏感文件：

• ~/.docker/config.json
• ~/.azure/accessTokens.json
• Kubernetes 配置或 manifest
• CI/CD workflow 配置
• 应用自己的 YAML / JSON 配置
• 内部 prompt 文本文件

这里有个值得注意的细节。

Cyera 在研究里把这组接口描述成面向开发者可见的 prompt loading 能力；而 LangChain 官方 advisory 则把它们定义成已过时的 legacy API，并明确说将被废弃，推荐迁移到 langchain_core.load 里的 dumpd / dumps / load / loads。
更稳妥的理解是：不管这些接口在历史上算不算“主路”，只要你的项目里还在用，而且输入又受外部影响，就有真实风险。

这条漏洞的修复版本是：

• langchain-core >= 1.2.22

2. CVE-2025-68664：序列化注入，可把用户数据伪装成 LangChain 对象

这条是三者里最值得认真看的一个，因为它的 CVSS 达到了 9.3，而且官方定级是 Critical。

问题出在 LangChain 的 dumps() 和 dumpd()。

LangChain 内部会用特殊结构去标记“这是一个合法的可反序列化对象”。其中一个关键标识就是字典里的 lc 键。漏洞在于：

• 当用户可控数据里带着这种结构时
• dumps() / dumpd() 没有正确把它转义掉
• 后续再经过 load() / loads() 反序列化
• 这段原本只是普通用户输入的数据，就会被当成真正的 LangChain 对象来处理

官方公告列出的危险点有两层。

第一层，是环境变量泄露。

在旧默认行为下，load() / loads() 的 secrets_from_env 是 True。这意味着攻击者如果构造出特定对象结构，就可能让反序列化过程去读取环境变量里的值，例如：

• OPENAI_API_KEY
• 其他模型密钥
• 云平台访问令牌

第二层，是在受信命名空间里实例化带副作用的类。

虽然官方说这里仍受信任命名空间限制，不是随便什么任意类都能实例化，但如果某些类在 __init__ 里本来就会做网络请求、文件操作或其他副作用动作，依然可能把风险进一步放大。

更麻烦的是，这类问题不一定非要“用户直接上传恶意对象”才会触发。官方特别点名了一类常见攻击路径：

• additional_kwargs
• response_metadata
• 其他由 LLM 输出带回来的字段

也就是说，只要你的应用把 LLM 响应里的某些字段继续走序列化 / 反序列化流程，那提示词注入就可能成为这条漏洞的上游入口。

LangChain 官方列出的高风险使用场景包括：

• astream_events(version="v1")
• Runnable.astream_log()
• RunnableWithMessageHistory
• InMemoryVectorStore.load()
• hub.pull 加载不可信 manifest
• 直接对不可信数据调用 load() / loads()

修复动作不只是打补丁，还包括默认行为收紧：

• allowed_objects="core" 的 allowlist 限制
• secrets_from_env 默认从 True 改为 False
• 默认阻止 Jinja2 模板初始化

这条漏洞的修复版本是：

• langchain-core 0.3.81
• langchain-core 1.2.5

3. CVE-2025-67644：LangGraph SQLite checkpoint 查询可被 SQL 注入

第三条漏洞不在 LangChain 主体，而在 langgraph-checkpoint-sqlite。

问题点同样很经典：值做了参数化，但键名没校验。

LangGraph 的 SQLite checkpoint 实现里，有一段逻辑会把 metadata filter 的 key 直接拼进 SQL 语句。官方公告说明，攻击者如果能控制这些 filter key，就能操纵查询条件，进而执行任意 SQL 查询。

这里最容易踩坑的，不是内部写死的 filter，而是这种自定义服务：

• 你自己搭了个 LangGraph 服务
• 用的是 SqliteSaver 作为 checkpointer
• 对外暴露了 get_state_history() 之类的历史查询接口
• 还允许客户端传入 metadata filter 的字段名

这时风险就出来了。

官方给的示例很典型：如果用户能控制 filter_field，那原本应该只是过滤 metadata 的地方，就可能被构造成恒真条件，直接绕过预期的数据隔离逻辑。

不过这里也有个重要边界，官方明确写了：

• LangSmith Deployment Customers 不受影响

原因是 LangSmith 部署里不允许自定义 checkpointer，所以走不到这个漏洞路径。

也就是说，这条问题更像是自托管或自定义服务部署的安全债，不是所有用 LangGraph 的人都会无差别中招。

这条漏洞的修复版本是：

• langgraph-checkpoint-sqlite 3.0.1

不是所有 LangChain 用户都一样危险

看完三个漏洞之后，很容易产生一种感觉：那是不是只要项目里有 LangChain / LangGraph 就等于危险？

其实没那么简单。

更准确地说，真正决定风险大小的，是你有没有把“不可信输入”接进这些危险路径。

下面这些模式才是重点排查对象：

• 把用户可控 JSON 直接传给 load_prompt_from_config()
• 接收外部 prompt 模板或共享 prompt 配置
• 对 LLM 返回的 additional_kwargs、response_metadata 等字段继续做反序列化
• 使用 astream_events(version="v1") 或旧流式日志路径
• 自己暴露 checkpoint 历史查询接口，并允许外部传 filter key
• 把环境变量、Docker 配置、云凭证和 AI 服务都塞在同一运行环境里

如果你的项目根本没有这些路径，那风险会小很多。

但如果你正好命中其中两三项，那这次就不该只当“依赖更新提醒”看，而更像一次应该进入正式整改流程的安全事件。

现在该怎么处理

如果你是项目维护者，比较实际的处理顺序可以是这样：

1. 先升级

• langchain-core 升到 >= 1.2.22
• 至少确保序列化相关版本不低于 0.3.81 或 1.2.5
• langgraph-checkpoint-sqlite 升到 3.0.1

2. 再查代码路径

重点搜这些调用点：

rg "load_prompt_from_config|load_prompt|dumps\\(|dumpd\\(|load\\(|loads\\(|get_state_history|SqliteSaver" .

3. 把“不可信输入”重新画边界

特别是这几类输入：

• 用户上传或共享的 prompt 配置
• LLM 返回结构中的附加字段
• 前端传上来的 filter key
• 外部系统同步过来的历史对象、缓存和 manifest

4. 重新评估运行环境里的秘密信息

如果应用进程里本来就挂着：

• 模型 API Key
• Docker 登录信息
• 云平台 access token
• CI/CD secrets
• 私有知识库配置

那这次就不只是“升个版本”，而应该顺手做一次凭证轮换和访问边界检查。

我对这件事的一个判断

这条新闻真正值得注意的地方，不只是 LangChain / LangGraph 自己出了三个漏洞，而是它再次提醒了一件事：

AI 基础设施并不会自动避开传统安全问题。

很多团队聊 AI 风险时，注意力还放在幻觉、提示词注入、模型越权这些“看起来更像 AI 的问题”上。但现实里更容易把系统打穿的，依然可能是老三样：

• 路径遍历
• 序列化注入
• SQL 注入

只不过这一次，这些老问题挂在了 AI 框架上，于是它们碰到的就不只是普通业务数据，而是 prompt、对话历史、云凭证和模型密钥。

这也是为什么这类问题的修复，不能只停留在“把依赖升级一下”。
更重要的是重新回答两个问题：

• 哪些输入是外部可控的？
• 哪些组件其实已经碰到了你最敏感的数据？

如果这两个边界没画清楚，类似的问题以后还会换个名字再来一次。

参考链接

• The Hacker News：LangChain, LangGraph Flaws Expose Files, Secrets, Databases in Widely Used AI Frameworks
• Cyera Research：LangDrained: 3 Paths to Your Data Through LangChain, the World’s Most Popular AI Framework
• GitHub Advisory：CVE-2026-34070 / Path traversal in legacy load_prompt functions in langchain-core
• GitHub Advisory：CVE-2025-68664 / LangChain serialization injection vulnerability enables secret extraction in dumps/loads APIs
• GitHub Advisory：CVE-2025-67644 / SQL injection via metadata filter key in SQLite checkpointer list method

关于

关注我获取更多资讯

📢 公众号

💬 个人号