LangGraph越权读取漏洞CVE-2026-71433
LangGraph 是 LangChain 官方推出、MIT 协议开源的有状态智能体底层编排框架，搭建可循环、可中断、长期运行的 AI Agent工作流。
一、基本情况
LangGraph 高度可控、流程透明可追溯、天然适配 Agent 循环逻辑、多智能体协作，生产级断点恢复、兼容任意大模型与 LangChain。
LangGraph可以弥补 LangChain 线性链式（LCEL）无法实现循环思考、分支决策的短板，具备如数据分析助手等等思考循环的Agent。
栋科技漏洞库关注到 LangGraph 相关软件版本中存在的越权读取漏洞，该漏洞已经被追踪为CVE-2026-71433，CVSS 3.X评分为 5.3。
二、漏洞分析
CVE-2026-71433漏洞是 LangGraph 中存在的越权读取漏洞，漏洞可能导致已认证攻击者可以直接越权读取其他租户或用户的存储项。
具体来说，LangGraph Checkpoint 的 Postgres 与 SQLite 存储将分层命名空间扁平化后使用不具备分段边界语义的前缀匹配，
从而导致已认证调用者在以命名空间隔离租户且标签互为前缀或含模式元字符时调用普通搜索或命名空间列表接口。
受影响版本中，langgraph-checkpoint-postgres 与 langgraph-checkpoint-sqlite 的 3.1.1 之前版本把层级命名空间拼成点连接字符串，
并用 LIKE '<path>%' 等简单模式进行 search 与 list_namespaces 过滤；该匹配不识别点分隔的命名空间段，
且未转义标签中的 % 与 _，导致前缀相似或模式字符造成越权返回。
Postgres 与 SQLite 存储引擎会将层级命名空间拼接为以点分隔的字符串存储（例如 ("memories", "alice") 存储为 memories.alice），
并通过 LIKE '<路径>%' 匹配该字符串实现限定范围读取。
由于 LIKE 无法识别.分隔符，在限定命名空间检索、枚举命名空间时，也会命中扁平化字符串前缀一致的同级命名空间。
各类应用通常将命名空间用作租户隔离边界。
在此场景下，仅发起正常的范围读取请求，无需构造恶意输入，就有可能读取到其他命名空间下的数据。
暂无证据表明该漏洞已在真实环境中遭到利用。
1、受影响场景与系统
满足以下全部条件即存在风险：
使用了 PostgresStore/AsyncPostgresStore 或 SqliteStore/AsyncSqliteStore；
依靠命名空间实现用户、租户之间的数据隔离；
存在一类命名空间名称是另一类的前缀（例如 1 和 12、alice 和 alice2），或是命名空间名称包含下划线 _、百分号 %。
采用 UUID 这类定长标识符作为命名空间名称、且名称不含 _、% 的应用不受影响，此类命名空间不可能互为前缀。
内存存储引擎 InMemoryStore 采用分段比对命名空间的方式，不存在该漏洞。
2、漏洞共分为三种触发情形：
同级命名空间污染：
限定在 ("foo",) 命名空间读取数据时，会一并查出 ("foobar",)、("foo2",) 下的数据；
未转义通配符：
命名空间允许使用 _、%（仅.会被禁止），但这些字符直接拼接进匹配规则且未做转义，导致检索 ("user_1",) 时也能匹配到 ("userX1",)；
后缀匹配异常：
执行 list_namespaces(suffix=("alice",)) 枚举命名空间时，会错误匹配同级叶子节点 users.malice。
该问题并非 SQL 注入。
参数均以预编译绑定参数形式传入，并未直接拼接进 SQL 语句；只是传入绑定参数本身作为 LIKE 匹配模板，其中通配符没有被转义。
3、影响
保密性风险：若以命名空间作为租户、用户隔离边界，攻击者可读取目标命名空间以外其他命名空间内存储的数据。
不会影响数据完整性与服务可用性。
单点读取、写入、删除接口采用全等 = 匹配命名空间，全程不受漏洞影响，该缺陷仅存在于批量读取逻辑。
4、修复方案与缓解措施
前缀匹配逻辑改为精准匹配命名空间，或是要求后续字符必须以.分隔；对命名空间内的通配符字符进行转义；
枚举命名空间 list_namespaces 在前缀、后缀匹配时采用分段识别模式。
SQLite 环境中，层级匹配由 LIKE 改为 GLOB。
SQLite 的 LIKE 对 ASCII 字符大小写不敏感，旧逻辑会出现大小写不同的命名空间互相匹配，而单点增删改查逻辑区分大小写；
修复后检索规则和单点操作逻辑保持一致。
5、兼容性说明
在 list_namespaces 的匹配路径中，* 现在仅匹配单个命名空间分段，恢复文档约定行为。
例如 ("cache", "*", "v1") 代表「任意缓存分类且版本为 v1」，行为与内存存储引擎保持一致。
旧版本可以用 * 配合 SQL 的 % 实现跨多段匹配，该机制正是本次漏洞的成因，修复后无法再保留该特性。
如需实现任意深度匹配，可叠加前后缀条件进行逻辑与查询：
list_namespaces(prefix=["uid"], suffix=["alice"])
命名空间不存在前缀关系的业务，升级后行为无任何变化。
6、运维建议
优先使用 UUID 这类定长字符作为命名空间标识，杜绝命名空间互为前缀的情况；
若命名空间由用户自定义输入，务必在入口处做合法性校验，不要单纯依靠命名空间隔离做权限管控。
7、LangSmith 托管部署补充说明
和以往存储引擎漏洞公告不同，本次漏洞会波及托管部署环境。
LangSmith 默认配置 LANGGRAPH_STORE_BACKEND=python，底层使用存在漏洞的 AsyncPostgresStore；
配置 LANGGRAPH_STORE_BACKEND=grpc 的部署采用独立实现，也已推送对应修复补丁。
三、影响范围
LangGraph-checkpoint-postgres＜3.1.1
LangGraph-checkpoint-sqlite＜3 3.1.1
四、修复建议
LangGraph-checkpoint-postgres ≥ 3.1.1
LangGraph-checkpoint-sqlite ≥ 3 3.1.1
五、参考链接
管理员已设置登录后刷新可查看