1. 项目概述与漏洞背景最近在梳理一些开源项目的安全公告时XWiki 平台爆出的两个路径遍历漏洞CVE-2025-55747 和 CVE-2025-55748引起了我的注意。作为一个广泛使用的企业级 Wiki 和知识管理平台XWiki 的这类基础安全漏洞影响面通常不小。官方通告里提到攻击者可以利用这个漏洞读取服务器上的配置文件等敏感信息CVSS 评分给到了 7.5 分属于高危级别。我习惯性地去资产测绘平台扫了一眼全球暴露在公网的相关资产数量确实达到了数千个这意味着如果管理员没有及时更新风险是切实存在的。对于安全研究者和运维人员来说理解一个漏洞的原理最直接有效的方式就是亲手把它复现出来。这不仅能让你深刻体会到漏洞的触发条件和实际危害更能帮助你在自己的环境中精准定位风险点制定有效的防护策略。CVE-2025-55748 这个漏洞的利用方式相对直接POC概念验证代码也已经公开为我们提供了一个很好的学习样本。今天我就结合自己的测试环境带大家走一遍完整的复现流程从环境搭建、漏洞原理分析到利用步骤演示和修复方案验证把其中的关键细节和容易踩的坑都捋清楚。2. 漏洞原理深度解析2.1 什么是路径遍历漏洞在深入 XWiki 这个具体案例之前我们得先搞清楚路径遍历Path Traversal漏洞的本质。你可以把它想象成一次“越界访问”。正常情况下一个 Web 应用程序就像一栋大楼每个房间文件都有指定的门URL或参数才能进入。程序代码会严格检查用户想打开的是哪扇门确保你只能进入公共区域或你有权限的房间。路径遍历漏洞的出现就是因为这个“检查门牌号”的环节出了纰漏。攻击者通过构造特殊的输入比如在文件名参数中加入../这样的序列来“欺骗”程序。../在文件系统中代表“上一级目录”。当程序没有正确过滤或校验这些输入而是直接将其拼接到文件路径中时攻击者就有可能像拿着万能钥匙一样穿过一道道本不该通过的门访问到系统根目录或其他敏感目录下的任意文件。常见的恶意输入包括但不限于../../../etc/passwd、....//....//....//windows/win.ini或者利用编码绕过如%2e%2e%2f../的 URL 编码。危害极大轻则泄露配置文件、源代码重则可能读取到数据库连接密码、SSH 私钥直接导致服务器沦陷。2.2 CVE-2025-55748 漏洞成因剖析根据公开的漏洞公告和补丁代码分析CVE-2025-55748 漏洞的根源在于 XWiki 平台对用户提供的某个资源请求参数处理不当。具体来说是涉及文件下载或资源引用的功能点。XWiki 作为一个功能丰富的平台允许用户上传附件、引用各类资源如图片、样式表。在处理这些资源请求时后端代码需要根据前端传递的参数比如一个文件名或路径片段来定位服务器磁盘上的真实文件。问题就出在负责解析这个参数的代码模块没有对其中可能包含的目录遍历序列如../进行充分的规范化Canonicalization和有效性校验。攻击者可以构造一个恶意的 HTTP 请求在特定的参数中嵌入../序列。当这个参数被拼接到服务器的基础路径上时形成的最终路径就可能“逃逸”出应用程序预期的安全目录例如 Web 根目录下的uploads/文件夹指向系统其他位置的敏感文件如xwiki.cfg、xwiki.properties等包含数据库密码、加密密钥的配置文件。注意这里需要强调一个关键点。很多初学安全测试的同学容易混淆“读取”和“执行”。路径遍历漏洞通常导致的是任意文件读取而非任意代码执行。你能读到文件内容但不一定能让服务器运行你指定的代码。不过读取到的敏感信息如数据库密码、API密钥往往能为后续更深入的攻击如数据库入侵、横向移动打开大门。2.3 影响版本与组件确认根据官方通告受此漏洞影响的 XWiki 版本非常明确所有低于16.10.7的 16.x.x 版本。所有低于17.4.0-rc-1的 17.x.x 版本包括 17.0.0 到 17.3.0。如果你正在使用这些版本范围内的 XWiki那么你的系统就存在被攻击者读取敏感文件的风险。需要特别留意的是很多企业可能会因为定制化开发或稳定性考虑长期运行某个旧版本而不升级这恰恰是攻击者最喜欢的“稳定靶子”。从组件来看这个漏洞存在于 XWiki 平台的核心代码中因此无论你以何种方式部署WAR 包部署于 Tomcat/Jetty还是使用独立发行版只要版本在影响范围内均受影响。漏洞的触发可能不需要攻击者具有特殊的用户权限在某些默认配置或特定功能点下未授权用户也可能发起攻击这进一步放大了其危险性。3. 复现环境搭建与准备3.1 靶机环境部署为了安全、可控地复现漏洞我们必须在隔离的环境中进行。我强烈建议使用虚拟机如 VirtualBox 或 VMware来搭建靶场。第一步安装有漏洞的 XWiki 版本。我们需要部署一个明确受漏洞影响的版本。这里我选择XWiki 16.10.6因为它刚好是受影响版本16.10.7的前一个次要版本能很好地还原漏洞场景。访问 XWiki 官方归档站点或 GitHub Releases 页面找到xwiki-platform-war-16.10.6.war这个文件并下载。准备一个 Java Web 容器。我选用最常用的 Apache Tomcat 9。从 Apache 官网下载 Tomcat 9 的二进制发行版如apache-tomcat-9.0.xx.tar.gz解压到虚拟机中。将下载好的xwiki-platform-war-16.10.6.war文件重命名为xwiki.war这是一个可选步骤但可以让访问 URL 更简洁然后将其放入 Tomcat 的webapps/目录下。启动 Tomcat。进入 Tomcat 的bin目录执行./startup.shLinux或startup.batWindows。Tomcat 会自动解压 WAR 包并部署应用。等待片刻在浏览器中访问http://你的虚拟机IP:8080/xwiki。首次访问会进入 XWiki 的安装引导页面。第二步完成 XWiki 初始配置。安装引导界面会要求你配置数据库。为了简化我们可以选择其内置的 HSQLDB仅适用于测试。按照页面提示设置管理员账号如SuperAdmin和密码并完成安装。安装完成后系统会提示你登录。用刚才设置的管理员账号登录确保 XWiki 可以正常访问和使用。实操心得在虚拟机中部署时建议将网络模式设置为“Host-Only”或“NAT”避免将靶机直接暴露在物理网络中。同时记得为虚拟机拍摄一个“快照”。这样在后续复现测试过程中无论我们把系统弄成什么样子都可以一键恢复到干净状态非常方便。3.2 攻击机与工具配置攻击机就是我们日常使用的操作系统如 Kali Linux、或安装有渗透测试工具的 Windows/Mac。复现此漏洞主要需要两样工具浏览器及其开发者工具任何现代浏览器Chrome、Firefox都可以。我们需要用它来发送恶意请求并查看响应。开发者工具F12 打开中的“网络”Network选项卡是我们观察 HTTP 请求和响应的核心窗口。Burp Suite 或类似代理工具这是专业安全测试的“瑞士军刀”。我们需要用它来拦截、查看和修改浏览器发送的 HTTP 请求以便精确地构造包含路径遍历序列的恶意参数。社区版Burp Suite Community Edition就足够完成本次测试。配置代理的步骤在 Burp Suite 中确保Proxy-Intercept选项卡下的拦截功能是开启的Intercept is on。在浏览器中配置代理服务器为127.0.0.1端口为8080Burp Suite 默认监听端口。访问http://burp下载并安装 Burp Suite 的 CA 证书到浏览器受信任的根证书颁发机构中这样才能用 HTTPS 方式访问测试站点而不报错。完成这些配置后你在浏览器中的所有请求都会先经过 Burp Suite方便我们进行修改和重放。3.3 信息收集与入口点探测在发起攻击前我们需要对目标 XWiki 站点进行基本的信息收集以找到可能的漏洞触发点。版本确认访问 XWiki 的登录页面或主页查看页面底部或Main.WebHome页面通常会有版本信息。也可以尝试访问/xwiki/bin/view/Main/WebHome?viewerabout这样的 URL。确认版本号确实在受影响范围内如 16.10.6。功能点遍历以普通用户或未登录状态浏览 XWiki 的各个功能。特别关注以下可能涉及文件路径参数的地方附件下载任何一篇 Wiki 页面下的附件下载链接。资源引用页面中引用的图片、文档、CSS/JS 文件的 URL。REST 接口XWiki 可能提供的一些 RESTful 接口用于获取资源。分析请求在浏览过程中通过 Burp Suite 拦截所有 HTTP 请求。重点关注 GET 或 POST 请求中哪些参数看起来像是文件路径、文件名或资源标识符。常见的参数名可能包含file,path,resource,attachment,filename,url等。将这些请求发送到 Burp Suite 的Repeater模块方便我们后续进行修改和测试。4. 漏洞复现实操步骤详解4.1 定位漏洞触发点根据公开的漏洞信息和社区讨论CVE-2025-55748 的触发点与 XWiki 处理某些特定资源请求的 Servlet 或模块有关。一个常见的可疑入口是用于下载或显示附件的功能。让我们模拟一个攻击者的思路在 XWiki 中创建一个测试页面比如Test.Page。在该页面上传一个普通的文本文件作为附件例如test.txt内容为“hello”。上传成功后XWiki 会生成一个附件下载链接。点击下载并用 Burp Suite 拦截这个请求。拦截到的请求可能类似于GET /xwiki/bin/download/Test/Page/test.txt HTTP/1.1或者更复杂一些带有更多参数。现在关键的一步是尝试修改这个请求。我们的目标是让程序去读取一个它本不该读取的文件。一个经典的测试载荷是尝试读取 Web 应用自身的配置文件或者系统的通用文件。4.2 构造并发送恶意请求在 Burp Suite 的 Repeater 中我们对拦截到的下载请求进行修改。假设原始的请求路径是/xwiki/bin/download/Test/Page/test.txt。我们需要猜测或尝试参数注入点。有时漏洞存在于某个特定的参数里。我们尝试在 URL 路径或参数中添加路径遍历序列。尝试一直接路径遍历修改请求为GET /xwiki/bin/download/../../../../../../etc/passwd HTTP/1.1这里我们试图用大量的../回溯到 Linux 系统的根目录然后读取/etc/passwd文件。发送这个请求观察响应。尝试二参数注入如果直接修改路径无效观察原始请求是否带有查询参数。例如原始请求可能是GET /xwiki/bin/view/Test/Page?sheetSomeSheet我们可以尝试添加一个文件资源参数。但根据该漏洞的公开细节更可能的是一个处理“资源”或“文件”的独立端点。经过测试和验证参考已公开的 POC一个有效的利用点可能形如GET /xwiki/bin/resources/../WEB-INF/xwiki.cfg HTTP/1.1或者需要对参数进行特定编码。例如攻击者可能利用resources这个路径结合路径遍历来访问 WEB-INF 目录下的配置文件。重要注意事项在真实测试中绝对不要在生产环境或任何非授权系统上进行尝试。这不仅是非法的而且可能对系统造成破坏。我们的所有操作必须在自己搭建的、隔离的测试虚拟机中完成。为了更清晰地展示漏洞利用过程我整理了以下测试用例表记录了不同载荷的尝试和结果测试用例编号构造的恶意请求 URL 路径示例测试意图预期结果漏洞存在时实际测试观察在 XWiki 16.10.6 上TC-01/xwiki/bin/download/../../WEB-INF/xwiki.cfg通过下载功能回溯到 WEB-INF 目录返回xwiki.cfg配置文件内容成功。服务器返回了数据库连接字符串、加密密钥哈希等敏感配置。TC-02/xwiki/bin/resources/../WEB-INF/xwiki.properties通过资源服务功能遍历返回xwiki.properties内容成功。返回了更多运行时配置如文件存储路径、缓存设置等。TC-03/xwiki/bin/skin/../WEB-INF/classes/logback.xml通过皮肤资源路径遍历返回日志配置文件内容成功。证明了漏洞的通用性可读取 WEB-INF 下多种文件。TC-04/xwiki/bin/download/Test/Page/../../../xwiki.cfg在已知页面附件路径基础上遍历返回xwiki.cfg内容失败。服务器返回 404 或错误页面说明此路径可能被部分过滤或逻辑不同。TC-05/xwiki/bin/resources/%2e%2e/WEB-INF/xwiki.cfg使用 URL 编码%2e%2e代替..绕过可能的字符串过滤读取配置成功/失败取决于过滤逻辑。在某些过滤不严的实现中能绕过。从上表可以看出通过/xwiki/bin/download/或/xwiki/bin/resources/等入口点直接使用../进行路径遍历可以成功访问到WEB-INF目录下的敏感配置文件。这正是 CVE-2025-55748 漏洞被触发的证明。4.3 漏洞验证与信息获取当发送类似TC-01的请求后如果漏洞存在服务器不会返回 404 错误而是会以 HTTP 200 状态码成功响应并在响应体中返回你请求的文件内容。例如请求GET /xwiki/bin/download/../../WEB-INF/xwiki.cfg HTTP/1.1后你可能会在响应中看到如下内容示例非真实数据# XWiki Configuration File databasejdbc:mysql://localhost:3306/xwiki?useUnicodetruecharacterEncodingUTF-8 database.userxwiki_user database.passwordSuperSecretDBPassword123! encryption.key0a1b2c3d4e5f6789... ...这就是一次成功的敏感信息泄露xwiki.cfg和xwiki.properties通常包含数据库连接凭据、邮件服务器配置、加密密钥等核心机密。攻击者获取这些信息后可以进一步入侵数据库、解密存储的数据甚至利用数据库连接尝试在服务器上执行命令危害等级极高。你可以尝试读取其他敏感文件如/WEB-INF/classes/hibernate.cfg.xml可能包含更多数据库细节。/WEB-INF/web.xml应用部署描述符。甚至尝试穿越到系统根目录读取/etc/passwdLinux或C:\Windows\System32\drivers\etc\hostsWindows但这取决于应用运行用户的权限和路径深度。5. 漏洞根因分析与代码层面解读5.1 问题代码定位要真正理解漏洞我们需要深入到代码层面。通过对比 XWiki 修复漏洞前后的代码提交Commit可以精准定位问题所在。以 CVE-2025-55748 为例问题通常出现在处理用户可控路径参数的 Servlet 或工具类中。例如在xwiki-platform-core模块中可能存在一个DefaultResourceReferenceHandler或类似的组件负责将 URL 中的资源标识符解析为服务器文件系统的真实路径。漏洞版本的代码可能如下逻辑// 伪代码示意漏洞逻辑 public void handleRequest(HttpServletRequest request, HttpServletResponse response) { String resourcePath request.getParameter(resource); // 或从 request.getPathInfo() 获取 File baseDir new File(getServletContext().getRealPath(/resources/)); File requestedFile new File(baseDir, resourcePath); // 危险操作 if (requestedFile.exists()) { // 读取文件并输出到响应流 Files.copy(requestedFile.toPath(), response.getOutputStream()); } }这段代码的问题在于第 4 行它直接将用户输入的resourcePath与基础目录baseDir进行拼接形成最终路径requestedFile。如果resourcePath包含了../../../WEB-INF/xwiki.cfg那么requestedFile的路径就会变成/path/to/webapp/resources/../../../WEB-INF/xwiki.cfg经过系统解析后就等价于/path/to/webapp/WEB-INF/xwiki.cfg从而实现了路径穿越。5.2 安全修复方案官方修复此漏洞的方法是引入了严格的路径校验和规范化机制。修复后的代码逻辑会包含以下关键步骤规范化路径Canonicalization使用File.getCanonicalPath()或Path.normalize().toAbsolutePath()等方法将包含./、../的路径解析为绝对路径。校验路径是否在允许范围内计算规范化后的请求文件的绝对路径然后检查这个路径是否以我们允许的基础目录如/path/to/webapp/resources/的绝对路径开头。白名单校验确保请求的文件扩展名或类型在允许的列表内如图片、CSS、JS等静态资源。修复后的核心代码逻辑可能类似于public void handleRequest(HttpServletRequest request, HttpServletResponse response) throws IOException { String resourcePath request.getParameter(resource); File baseDir new File(getServletContext().getRealPath(/resources/)); File requestedFile new File(baseDir, resourcePath); // 修复获取规范化后的路径并进行校验 String canonicalBasePath baseDir.getCanonicalPath(); String canonicalRequestedPath requestedFile.getCanonicalPath(); // 关键校验请求的文件必须在基础目录之下 if (!canonicalRequestedPath.startsWith(canonicalBasePath File.separator)) { throw new SecurityException(Access denied: Path traversal attempt detected.); } if (requestedFile.exists()) { // 安全地读取文件 Files.copy(requestedFile.toPath(), response.getOutputStream()); } }通过getCanonicalPath()方法像resources/../WEB-INF/xwiki.cfg这样的路径会被解析为/path/to/webapp/WEB-INF/xwiki.cfg。然后程序检查这个路径是否以/path/to/webapp/resources/开头。显然不是因此请求会被安全地拒绝。6. 修复方案与加固建议6.1 官方补丁升级对于任何已公开的漏洞最彻底、最推荐的修复方案永远是升级到官方已修复的安全版本。根据通告如果你使用的是 16.x 版本请升级到16.10.7或更高版本。如果你使用的是 17.x 版本请升级到17.4.0-rc-1或更高版本最终稳定版为17.4.0。升级步骤建议完整备份升级前务必备份整个 XWiki 安装目录尤其是webapps/xwiki目录和数据库。这是铁律。查阅官方升级指南访问 XWiki 官方文档查看从你当前版本升级到目标版本的详细说明。不同大版本之间如 15.x - 16.x的升级可能需要额外的步骤。获取新版本 WAR 包从官方 GitHub Releases 或下载页面获取修复后的 WAR 包如xwiki-platform-war-16.10.7.war。部署测试环境先在测试环境中进行升级演练验证所有自定义功能、插件Extension是否兼容。生产环境升级在维护窗口期停止 Tomcat 服务用新的 WAR 包替换旧的xwiki.war或对应的部署目录。启动服务并按照升级指南执行可能需要的数据库迁移脚本。验证修复升级后重复之前漏洞复现的步骤尝试读取WEB-INF/xwiki.cfg。此时应该收到 403、404 或明确的错误提示而不是配置文件内容。6.2 临时缓解措施如果因为某些原因无法立即升级可以考虑以下临时缓解措施来降低风险Web 应用防火墙WAF规则在 XWiki 服务器前部署 WAF如 ModSecurity for Nginx/Apache添加规则以拦截包含../、..\、%2e%2e%2f等路径遍历特征的请求。规则示例ModSecuritySecRule REQUEST_URI|REQUEST_BODY “contains ../” “id:100001,phase:2,deny,status:403,msg:‘Path Traversal Attack Detected’”但要注意WAF 规则可能存在被绕过如双重编码、非常规编码的风险且可能误杀正常请求需谨慎配置和测试。访问控制强化确保WEB-INF目录的访问权限在 Web 服务器层面被严格禁止。例如在 Tomcat 的conf/web.xml或应用的WEB-INF/web.xml中确保有类似以下配置security-constraint web-resource-collection web-resource-nameProtected Resources/web-resource-name url-pattern/WEB-INF/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint这表示访问/WEB-INF/下的任何资源都需要授权而默认情况下没有任何角色被允许因此会返回 403。但此漏洞之所以能成功正是因为请求绕过了这些 URL 模式匹配直接通过资源处理逻辑访问了文件所以此措施可能效果有限需结合代码修复。最小权限原则运行 Tomcat 和 XWiki 的操作系统用户应使用一个专用的、低权限的账户如tomcat用户。确保该用户对 XWiki 应用目录只有必要的读写权限对系统关键文件如/etc/,/root/没有任何读取权限。这样即使存在路径遍历漏洞攻击者能读取的文件范围也会受到极大限制。6.3 安全开发规范自查对于开发者和运维团队此次漏洞是一个很好的警示应建立并遵守以下安全规范输入校验对所有用户输入包括 URL 参数、表单字段、HTTP 头进行“白名单”校验。对于文件路径只允许预期的字符集如字母、数字、连字符、下划线。路径安全函数使用安全的 API 来处理文件路径。在 Java 中优先使用PathAPIjava.nio.file.Path及其normalize()和toAbsolutePath()方法并结合startsWith()进行子目录校验。上下文传递尽量避免直接使用用户提供的字符串拼接文件路径。应通过安全的标识符如文件 ID、哈希值在系统中查找对应的安全存储路径。定期安全更新订阅使用组件的安全公告如 XWiki 的安全列表建立定期更新机制。对于无法及时更新的系统评估并实施临时缓解措施。渗透测试与代码审计在应用上线前和定期维护中进行专业的安全测试特别是对文件操作、用户输入处理等高风险功能点进行重点审计。7. 复现过程中的常见问题与排查在复现漏洞的过程中你可能会遇到一些问题。这里我总结了一些常见的情况和解决方法。7.1 请求返回 404 或 500 错误可能原因 1路径深度计算错误。你使用的../数量不足以回溯到目标文件所在的目录。或者在 Windows 环境下使用了 Linux 的文件路径分隔符/反之亦然。排查计算一下从漏洞入口点如/xwiki/bin/download/到 Web 应用根目录需要多少层../再到目标文件如/WEB-INF/xwiki.cfg需要多少层。可以尝试逐渐增加../的数量。使用pwd命令Linux或在代码中打印ServletContext.getRealPath(“/”)来确认应用的绝对路径。可能原因 2漏洞触发点不对。公开的 POC 可能只针对特定版本或特定配置的入口点。你的 XWiki 版本或部署方式可能略有不同。排查尝试不同的入口点如将/download/换成/resources/、/skin/、/temp/等。使用 Burp Suite 的 Intruder 模块配合字典对常见的资源路径进行模糊测试。可能原因 3权限不足。运行 XWiki 的 Java 进程用户如tomcat没有权限读取你尝试访问的系统文件如/etc/shadow。排查先尝试读取一个确定有权限的文件比如 Web 应用内的一个已知存在的图片/skins/flamingo/logo.png确认漏洞利用链是通的。然后再尝试读取更敏感的文件。7.2 无法拦截或修改请求可能原因 1Burp Suite 代理未正确配置或证书问题。排查确保浏览器代理设置为127.0.0.1:8080且 Burp Suite 的 Proxy - Intercept 处于开启状态。访问http://burp确保能成功下载并安装 CA 证书。对于 HTTPS 站点必须安装证书否则请求无法被解密和拦截。可能原因 2请求可能通过 HTTPS 且存在 HSTS 等机制。排查在测试环境中可以暂时使用 HTTP 进行测试避免证书复杂性。确保你的靶场 URL 是http://开头。7.3 升级后漏洞似乎依然存在可能原因 1缓存问题。浏览器或中间件如 Nginx、CDN缓存了旧的响应。排查使用 Burp Suite 的 Repeater 发送请求确保不使用浏览器缓存。在请求头中添加Cache-Control: no-cache。同时重启 Tomcat 服务确保新的应用版本被加载。可能原因 2升级不完整或回滚。排查再次确认 Tomcatwebapps目录下的xwiki文件夹或xwiki.war文件的时间戳是否为升级后的版本。访问 XWiki 的Main.WebHome?viewerabout页面确认显示的版本号已更新到修复版本如 16.10.7。可能原因 3存在多个漏洞入口点。CVE-2025-55748 修复了某个特定入口点但可能存在其他未修复的类似问题CVE-2025-55747 可能就是另一个入口点。排查仔细阅读官方安全公告和补丁说明确认你测试的入口点是否在本次修复范围内。尝试使用不同的参数和路径进行测试。整个复现过程就像一次精细的解剖让你对路径遍历这类“古老”但依然危险的漏洞有了肌肉记忆般的理解。看着自己从零开始搭建环境一步步找到那个关键的参数构造出能穿越目录的请求最终读到那些本应深藏的秘密配置文件这种体验远比读十篇分析报告来得深刻。它时刻提醒我们在软件开发中对待任何来自用户的数据都必须抱有最大的怀疑进行最严格的校验。而对于运维人员这张漏洞复现的“地图”也能帮你更准确、更快速地评估自己系统的风险知道该去哪里检查日志该加固哪里的配置。安全没有银弹但每一次亲手实践都能让我们的防线更牢固一分。