Directus SSRF → 国产云 metadata：默认黑名单的"AWS 中心主义"盲区

一句话：Directus 12.2.0 文件导入/Flow 的 SSRF 黑名单默认只写了 0.0.0.0/8 和
AWS 的 169.25.169.254，腾讯云 169.254.0.23、阿里云 100.100.100.200 全部放行，
实测两条链（低权限账号/完全匿名）可直达云 metadata；绑了 CAM 角色的实例即拿临时 AK/SK。

要点：

• 前提：Directus ≤ 12.2.0 默认配置（IMPORT_IP_DENY_LIST 仅两条；CVE-2026-61835 修复
  只补了 0.0.0.0 语义，没扩云厂商覆盖）；实例绑定 CAM/RAM 角色时影响升级为凭证窃取
• 链 A：仅 directus_files create 权限的低权限编辑账号即可触发 import SSRF
• 链 B：零凭证——Webhook Flow 触发器无认证中间件，Flow request 操作复用同一
  getAxios 黑名单，且 accountability 为 null（系统身份执行），匿名 curl 即达 metadata
• 工程启发："谁能触发"与"操作以什么身份执行"拆成两个配置，组合成匿名系统执行链；
  SSRF 防护审计要按云厂商枚举 metadata 地址，而不是照抄 AWS 基线

原语抽象：黑名单基线错配（写死单一云厂商的世界观）× "谁能触发"与"以什么身份
执行"两个配置解耦组合——匿名触发器 + 系统身份执行 = 免认证的原语发送器。
亲戚手法：SSRF→metadata 家族；差异：不是绕过黑名单而是黑名单先天不全（升级
成"默认配置即漏洞"），匿名链来自配置语义的组合而非代码缺陷。
防御启示：metadata 防护按云厂商枚举地址并优先会话凭证（IMDSv2 式）；低代码
Flow/Webhook 的触发器默认挂认证中间件，系统身份执行要单独立审计。

原文: https://xz.aliyun.com/news/92720
来源发布时间: 2026-08-19