文章总结： 本文详细记录了在Bing图像搜索功能中自主挖掘三个9.8分RCE漏洞(CVE-2026-32194等)的过程。攻击者通过精心构造的SVG文件，利用以图搜图或服务端爬虫路径，将恶意内容注入图像处理流水线，最终在WindowsServer生产环境以SYSTEM权限执行命令。核心教训是图像辅助工具(如ImageMagick)的代理行为是巨大攻击面，应严格限制其功能与出站访问。 综合评分： 100 文章分类： 漏洞分析,红队,WEB安全,安全工具,渗透测试

静默管道里的命门：Bing图像搜索 RCE 自主挖掘实录

幻泉之洲

2026年8月3日 09:14 北京

在小说阅读器读本章

去阅读

攻击者控制的图片内容，如何穿透 Bing 的“搜图”功能，在 Windows Server 生产环境拿到 SYSTEM 权限？三个 9.8 分漏洞的发现过程，没有灵光一现的 payload，只有上百次实验、逐层剥开的推理链，和一串被人当成“正常功能”的 500 错误码。

起点：一个没人会多看一眼的报错

Bing 的以图搜图功能，后端会根据你给的 URL 去抓图片。这本身是预期行为。XBOW 试着给了一个精心构造的地址，前端只返回了一个模糊的 500。

说实话，做安全研究的人看到这种响应，太容易就过去了——盲 SSRF，低危，业务需要，写报告关掉。但 XBOW 多停了一步。因为同一套请求，有时返回正常，有时报错；不同负载打过去，响应还有细微差别。这种不一致本身就是信号。它说明后端处理的并不是单一逻辑，而是存在一个负载均衡下的异构工作节点群，其中一部分节点多做了点什么。那个多做的部分，就是突破口。

用推理替代运气：把盲 SSRF 追到 ImageMagick 门口

既然前端看不到回显，怎么探明后面到底发生了什么？XBOW 的策略很简单：用外带信道。让 Bing 后端去请求一个可控的外部采集器，观察有没有 HTTP 请求过来。结果来了，User-Agent 是 bingbot/2.0。这一步证明了抓取确实发生在服务端。

但光有抓取没用。真正的问题紧接着冒出来：这些抓到的字节，后端拿它们干什么了？

最初的猜测是 XXE。SVG 和 XML 内容确实触发了更深的解析路径，返回的错误信息带有 XML 解析器的痕迹。然而外部 DTD 和 XInclude 的全部尝试均未引出外带请求，说明 XXE 这条路不通。排除一条路本身就是进展，它把范围从“任意 XML 利用”压缩到了“图像渲染链路”。

接下来是对渲染层的直接测试。普通 PNG 引用能正常返回搜图结果，而指向外带采集器的引用虽然触发了出站请求，却因为返回的是非图像内容导致渲染失败。ImageMagick 伪协议的表现则更有意思：label: 能渲染文本，xc: 能生成纯色图，vid: 也能产生可识别的图像结果；但是 text:、caption:、pango: 全挂，直接读文件系统路径的尝试也全挂。这说明后端跑着一套 ImageMagick 或兼容协议栈，而且部分 coder 被显式启用，部分被禁用；更关键的是，像素管道里确实藏着可以执行行为的代理路径，只是目前策略还没完全锁死。

到此，整个后端的图像处理骨架被拼凑出来了：可用的伪协议集合、禁用的路径、输入如何影响搜索结果重定向，全都有据可查。不同实验不再孤立，它们互相印证。没有任何单个测试结果能拍板定论，但数十个结果指向同一个结论时，说服力就不是谁的一厢情愿了。

从 SVG 到 SYSTEM：两条攻击通路

图像辅助工具是它们的交汇点。以图搜图上传的 SVG，到达后端转换流水线，精心设计的 SVG 可以触达允许代理行为的解码器，最终在光栅化过程中触发命令执行。SSRF 在这里只是一个传输工具，把攻击者控制的字节送到不安全的图像处理 worker。真正的漏洞边界在 worker 本身。

XBOW 最终确认了两个 Bing CVE 和第三个相关漏洞，并全部拿到生产环境下的命令执行证据。

CVE-2026-32194：通过以图搜图上传路径，将攻击者控制的 SVG 注入图像处理流水线，在工作节点上实现命令注入。

CVE-2026-32191：服务器端爬虫抓取了外部托管的恶意 SVG，同样进入同一套转化管道，触发远程代码执行。

CVE-2026-21536：微软设备定价项目中，不受限的文件上传导致服务端可直接执行上传的文件，漏洞成因类似，只是换了一个“辅助组件”。

三者都没有要求认证、cookie 或任何特权账户。攻击面完全来自那些接受用户内容、又将其传递给底层转换工具的公开接口。

执行环境是 Windows Server 2022 Datacenter，以 NT AUTHORITY\SYSTEM 跑在生产节点上。而且不是某台配错的主机——相同的利用行为在多个宿主、网络范围的后端 worker 上复现，说明这是图像处理层架构级别的缺陷。

第一轮验证时，XBOW 先发了 Linux 风格的 id 命令，外带采集器收到了 uid=0 和 gid=0。但后续用同样的 payload 打过去，返回来的却是 systeminfo 和 whoami /all 的输出。Bing 的图片处理集群是异构的，Linux 和 Windows worker 并行存在。最初写的验证脚本只认 Linux 输出格式，差点把真正的 Windows 命令执行当“失败”跳过。这点很值得琢磨：如果你的验证逻辑假定环境是同构的，你会漏掉真实的冲击。

Payload 拆解：复杂的不是构造，是到达构造之前的路

最终的利用 SVG 本身并不花哨。一个 base64 编码的 SVG 包含三部分：合法的 SVG 标签头、能触达代理转换路径的嵌入式图像引用、以及一条通过管道前缀传递的系统命令，将其输出打到 XBOW 的外带采集器上。

直接上传路径的请求大致长这样：

SVG_B64=”$(base64 -w0 exploit.svg)” curl -s -o /dev/null -w ‘%{http_code}’ \ -F “imageBin=${SVG_B64}” \ “https://www.bing.com/images/kblob”

爬虫路径则简单发起一个搜图请求，imgurl 指向外部托管的 SVG，Bing 后端以 bingbot/2.0 抓取后交由其图像转换层处理，命令执行结果同样通过 curl 打回外带端点。

把 Payload 放到本地实验室，只要手动开启 ImageMagick 里相同的危险代理行为，用最小 SVG 就能复现这一漏洞类。生产环境的利用，是在这个结构基础上，调整了外带地址和命令而已。核心始终是：攻击者控制的图像内容，穿越了应用层认为“只是图片”的假象，在下游转换器眼里变成了一行可执行指令。

图像处理为什么总出事

这个问题不是新问题。ImageTragick 距今快十年了，GitLab 的 ExifTool RCE 也是同类的失败——应用把上传的文件当作“普通图片”去剥离元数据，底层工具却因为内容识别直接把文件丢进了不该暴露的解析器。

根本原因在于，应用开发者把图像辅助工具当成管道设施。但 ImageMagick、ExifTool、Ghostscript 这些库，承载了几十年的格式兼容、协议支持、外调 shell 行为，它们不是简单的“缩小尺寸”“生成缩略图”。只要你不主动缩小它们的解析范围，它们就什么都敢接。SVG 不是像素，是 XML。它可以说形状，也可以说“去这里取另外一张图”，还可以把那个引用写成 |command——然后代理机制就帮你执行了。

防守思路应当完全不同。你要假设每个图像解析器、元数据剥离器、光栅化工具都是攻击面。对不受信的上传或服务端抓取通道，禁用调用 shell 的代理行为（包括基于管道的代理），锁定 policy.xml 和 delegates.xml，格式白名单收缩到必要项，高风险格式如 SVG、MVG、EPS 一律不放行，除非真的需要且运行在严格隔离环境中。此外，限制出站网络访问，防止命令输出流到外部。

技术后视镜：三个教训

辅助调用即边界。任何调了外部命令、解析器链、协议处理器的管道，都可能是输入到你系统的第二条路径。

出口控制与入口同样重要。服务端抓取要向客户端永远只开放白名单，做重定向控制，防止内网 SSRF 打到元数据端点。盲 SSRF 变成 RCE 的桥梁，往往就是因为出口能抓到攻击者可控的内容。

验证逻辑要匹配实际生产环境的异构性。如果你只预期 Linux 输出、只观察一种响应形状，异构集群里另一类主机的执行证据就可能被你当成误报丢掉。Bing 的利用事实上同时打穿了 Linux 和 Windows worker，但第一个版本的验证脚本却差点放过了后者。

这三个 CVE 不需要新漏洞类。命令注入在图像辅助工具里存在多年。不一样的是，识别它们所需要的耐心逐层下挖，在现代云服务的复杂管道前变得前所未有的关键。500 错误码，抓取行为，渲染器的不一致表现——单看哪一步都不起眼。但把每一步当成下一个实验的证据，一直追问到 SYSTEM shell 出现，这件事本身，才是真正的发现。

一点后话

整个过程里，没有一个决定性的幸运 payload。只有迫近假说的实验、被排除的路径、越来越小的搜索空间，以及最后暴露出来的那套代理管道。很多人问，一个自动化系统怎么做到在众多死胡同里坚持不前功尽弃的？这涉及 XBOW 推理机制的设计原则——我们另文再谈。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：幻泉之洲 《静默管道里的命门：Bing图像搜索 RCE 自主挖掘实录》