双冒号打穿Atlassian全家桶：预认证任意文件读取9.3分(CVE-2026-21589附PoC)

赤霄攻防实验室
赤霄攻防实验室

赤霄攻防实验室

2026年10月9日 17:10
河北

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

▲

TL;DR 四行速览
① 是什么：Atlassian 八款自建（Data Center）产品共用的 webresource 静态资源库存在预认证路径遍历，双冒号序列会被还原成斜杠，未授权读取 webapp 根目录任意已知路径文件，CVSS 4.0 高达 9.3；
② 影响谁：Jira、JSM、Confluence、Bitbucket、Bamboo、Crowd、Crucible、Fisheye 的全部旧版本，仅 Confluence 公网实例就以十万到七十万量级计，云版已自动修复无需操作；
③ 怎么修：升级到各产品修复版（Jira 9.12.40/10.3.26/11.3.12、Confluence 9.2.26/10.2.19 等），临时措施是 WAF/Tomcat RewriteValve 拦截双点+分隔符组合并排查访问日志；
④ 看点：细节公开后数小时就出现在野利用，而官方修复只加了一个路径规范化函数——我们在本地对 6.0.7 与 6.0.8 两个版本做了全量反编译 diff，并实测了判定通道与三态 PoC。

10 月 5 日，Atlassian 以带外方式发布了一份覆盖八款产品的安全通告，编号 CVE-2026-21589，定级 Critical。和以往单产品漏洞不同，这次中招的是从 Jira、Confluence 到 Bitbucket、Crowd 的整条自建产品线，而且不分新老——官方明确写了「修复版本之前的所有版本均受影响」，包括已经停止维护的 EOL 版本。一款共享组件的缺陷，一次性打开了八扇门。

更值得警惕的是时间线：通告发布次日，watchTowr Labs 公开了完整的技术分析与检测工件；再过一天，Previdian 的遥测就确认攻击者在野利用这个漏洞。从「补丁可用」到「攻击者上手」，中间只隔了几个小时。这篇文章我们把根因、利用链、修复差异和自查方法一次讲清。

一、漏洞档案：一条 GET 请求换一个文件

▲ CVE-2026-21589 漏洞档案卡（赤霄攻防实验室整理）

这个漏洞的本质是「任意文件读取」：攻击者不需要任何账号，向受影响实例发送一条特制 GET 请求，就能读取 Web 应用根目录（webapp）内任意已知路径的文件——包括正常情况下被 Servlet 容器严格保护的 WEB-INF 目录。唯一的限制是攻击者必须事先知道文件名和路径，不能列目录。但 Atlassian 自家产品的文件布局是公开且固定的，这个限制几乎不构成门槛。

读取范围被限制在 webapp 上下文之内，不能直接跳出应用读 /etc/passwd，这也是它没有拿到 9.8/10.0 满分的原因。但 WEB-INF 里有什么，用过 Java 应用的人都知道：部署描述符、集成配置、数据库连接参数。这类文件一旦泄露，后续攻击链就会自己展开——下文会讲 watchTowr 已经演示过的完整链路。

二、官方通告与修复版本

▲ Atlassian 官方安全通告（含 WAF 临时缓解规则）

官方通告给出了各产品的修复版本矩阵，覆盖仍在维护的多个大版本分支，便于不方便跨大版本升级的团队就近打补丁：

▲ 八款产品修复版本表（修复版之前所有版本均受影响）

如果不能立即升级，Atlassian 给了三类临时缓解：WAF/反向代理规则、Tomcat RewriteValve 规则（Confluence、JSM、Jira、Bamboo、Crowd）、Bitbucket 专用的 urlrewrite.xml 规则。拦截目标都是同一个正则族——URL 解码后（最多两层）出现的「两个点紧邻分隔符」组合，其中分隔符包括斜杠、反斜杠和这次的主角「双冒号」。官方同时强调：这些规则是有限的缓解，不能替代升级；有条件的话，直接把暴露在互联网的实例收进内网。

三、根因：一个为「转义斜杠」而生的小函数

八款产品同时中招，说明缺陷不在某条业务代码里，而在它们共享的 atlassian-plugins-webresource 库——负责所有产品前端静态资源（JS/CSS）的下载路由。watchTowr 对比漏洞版与修复版后发现，问题出在这个库里一个本意用于 URL 转义的工具函数上。

▲ watchTowr 分析：Router 类中的转义函数与资源路由（图源 watchTowr Labs）

看这段代码就明白了：库的设计者为了避免斜杠进入路由参数，实现了 escapeSlashes 与 unescapeSlashes 一对函数——入库前把「/」替换成「::」，出库后再替换回来。静态资源路由收到用户可控的 resourceName 后会调用 unescape 还原，然后交给资源工厂拼路径、读文件。问题在于，还原发生在路径校验之前：攻击者把穿越序列写成「..::..::..」，校验阶段看到的是无害的字符串，还原之后就成了「../../../..」。所有针对传统「../」的过滤，在这条转义通道面前全部失效。

▲ 构造好的读取请求与 web.xml 回显（图源 watchTowr Labs）

watchTowr 给出了三个产品的现成路由：Jira 走 color-picker 插件资源路径，Confluence 走 dashboard-actions 插件，Bitbucket 因 web.xml 被单独封堵改读 urlrewrite.xml。请求发出去，WEB-INF/web.xml 的内容就直接回来了——这是 Servlet 规范里明令禁止外部访问的文件。

四、本地验证：修复其实只加了一个函数

▲ 6.0.7 与 6.0.8 反编译全量 diff：唯一实质改动是新增 isInDirectory 校验

为了确认根因，我们从 Atlassian 官方 Maven 仓库拉取了漏洞版 6.0.7 与修复版 6.0.8 的 JAR，做全量反编译对比。结果非常干净：除了重编译噪音，两个版本唯一的实质差异在 ResourceFactory 的 createResourceWithRelativePath 方法——修复版在拼接路径前新增了一个私有静态方法 isInDirectory，先把资源目录与请求路径统一反斜杠、规范化（normalize），再用 startsWith 判断请求路径是否仍在资源目录内，不在就直接返回 null。整个修复只有十几行，却把所有形态的穿越（包括单点、双点、编码变体）一次性挡住。

这个 diff 也从侧面印证了 watchTowr 的分析方向：漏洞不在路由层，而在资源工厂最终拼路径的那一步。顺带一提，被修复的方法上还挂着 @Deprecated 注解——一个标记了废弃的方法，撑起了八款产品的静态资源服务，也撑出了这个 9.3 分的洞。

五、真正的杀伤力：从文件读取到 Jira 管理员

▲ Crowd 集成场景下的完整攻击链（watchTowr 已公开演示）

单独的文件读取听起来像「高危里的温和派」，但 Atlassian 官方通告里有一句提示：「某些配置下，webapp 目录内可能存在提升风险的敏感文件」。watchTowr 顺着这句话找到了答案：当 Jira 按官方文档与 Crowd（Atlassian 的集中式身份管理/SSO 产品）集成时，集成配置文件 crowd.properties 就落在 WEB-INF/classes/ 下，里面是应用名、Crowd 服务地址，以及连接 Crowd 的 application.password——明文。

拿到这份凭据，攻击者就可以直接调用 Crowd 的 REST 接口：先创建一个新用户，再把这个用户加进 jira-administrators 组。两步操作完成之后，攻击者手里就是一个货真价实的 Jira 管理员账号——从「读一个文件」到「接管身份中枢」，中间不需要任何额外漏洞。对于把 Jira/Confluence 当代码仓库与知识库用的团队，这意味着源代码、内部文档、CI 配置的一并失守。watchTowr 将整条链做成了单文件 Python PoC，并公开了面向 Jira/Confluence/Bitbucket 的检测工件生成器——这既是防御方的自查工具，也是攻击方的现成弹药，第二天在野利用出现并不意外。

六、自查与处置建议

给运维和安全团队的行动清单，按优先级排列：

1. 盘点暴露面：fofa/shodan 里搜自建 Jira/Confluence/Bitbucket 的特征，确认哪些实例暴露公网。八款产品全部旧版本都在射程内，EOL 版本同样中招。
2. 立即升级：对照上文修复版本表就近升级；EOL 版本没有补丁，必须迁移到受支持分支。
3. 排查入侵痕迹：对访问日志做最多两层 URL 解码后，搜索「两个点紧邻 /、反斜杠或双冒号」的请求模式；重点核对 200 状态的 download/resources 路径请求。若与 Crowd 集成，立刻轮换 crowd.properties 里的应用密码，并检查 Crowd 用户与 jira-administrators 组成员是否有异常新增。
4. 临时缓解：无法立即升级时，按官方通告配置 WAF/Tomcat RewriteValve/urlrewrite.xml 规则，并尽量将实例从公网收回。
5. 云版用户：Atlassian Cloud 已自动修复，无需操作，但自建混合部署里的 DC 组件仍需自查。

七、我们做了什么：源码级验证与三态 PoC

本实验室完成了两层验证。其一，源码级：拉取官方 Maven 仓库的 webresource 6.0.7/6.0.8 两个 JAR 全量反编译 diff，独立确认修复点为新增的 isInDirectory 规范化校验，与 watchTowr 公开分析一致。其二，工具化：编写了非破坏性验证脚本（指纹识别 → 多产品路由探测 → 读取产品自带部署描述符做无害判定 → 输出 VULNERABLE / PATCHED / UNKNOWN 三态结论），本地三态逻辑测试全部通过，并对 Atlassian 官方站点实测了判定通道（穿越请求被已修复的实例以 403 拒绝，基线路由正常响应，通道行为符合预期）。脚本未对任何未授权目标发起测试。

几点写作时的如实标注：本篇是源码级验证 + 远端判定通道实测，没有搭建完整 Jira+Crowd 环境做端到端利用链复现（链路本身引用 watchTowr 已公开的演示）；PoC 判定依赖的三个产品路由均来自公开分析，未覆盖全部八款产品的路由差异。

参考链接

1. Atlassian 官方通告：confluence.atlassian.com/security/cve-2026-21589-arbitrary-file-access-vulnerability-impacts-multiple-products-1870495748.html
2. watchTowr Labs 技术分析：labs.watchtowr.com/you-wont-hear-about-these-even-in-myths-atlassian-jira-confluence-and-more-pre-auth-arbitrary-file-read-cve-2026-21589
3. Previdian 在野利用遥测：previdian.com/CVE-2026-21589
4. watchTowr 检测工件生成器：github.com/watchtowrlabs/watchTowr-vs-Atlassian-CVE-2026-21589
5. 本实验室验证 PoC（三态判定，非破坏性）：github.com/Rubby2001/CVE-POCS/tree/main/CVE-2026-21589

本文为漏洞防御研究，分析对象为已公开披露且厂商已修复的漏洞；引用的利用细节仅用于防御检测。请在授权范围内使用文中提到的任何工具。觉得有用的话，点个「在看」或转发给负责 Jira/Confluence 运维的同事——这个洞的修复窗口，真的不长。