企业内网的Jira能被人未登录读走配置文件，排障顺序别搞反

原创

tcode
tcode

字节脉搏实验室

2026年10月9日 12:34
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

补丁发布才一天，蜜罐里就出现了探测请求

自建的项目管理和团队知识库，平时都被当成不对外发布的内部工具，可这一次不用登录、不用用户交互，一条请求就能把服务器上的配置文件读走。十月五日周一，协作与开发平台厂商为这个漏洞发布了安全公告，官方给出的严重度评分是九点三，口径是任意文件访问。十月六日，一家攻击面研究团队公布了技术分析，把利用链路完整写了出来。同一天晚间，一家威胁情报厂商公开表示，蜜罐网络里已经开始出现针对这个漏洞的攻击尝试，并附上一份攻击来源地址清单。

这里要分清两件事。蜜罐里出现扫描和探测请求，说明攻击者已经拿到并开始跑这个漏洞，不等于已经有真实企业被确认失陷。到十月八日，国内应急响应团队的风险通告仍把在野利用状态标注为未发现，同时把验证代码和技术细节都标成已公开。未发现不等于没有发生，只说明公开渠道还没有确认的受害样本。对排障的人来说，这个区别很实用：你现在要防的是马上会被扫到，而不是已经被人进来。

受影响的是用户自己部署的版本，不是厂商的云端服务。代码托管、团队知识库、项目管理、工单服务、持续集成、统一身份认证、代码审查等产品线都在范围内，只要能访问到实例，攻击者就能读取应用根目录下的指定文件。国内应急响应团队给出的影响量级是十万级；研究团队则提到，仅用一次公开搜索就能找到接近七十万套团队知识库实例。这两个数字口径不同，不能直接相加，但足以说明这不是一个可以慢慢排队修补的小问题。

问题不在读一个文件，而在读到了什么

根因出在一个被多款产品共用的组件上。研究团队对比修复前后的代码发现，这个共享组件会把两个连续冒号替换成斜杠，而应用服务器的路径规范化检查认得的是斜杠之后的形态。攻击者于是可以构造一条看起来正常的资源请求，让应用把本该受保护的文件当成静态资源返回。国内应急响应团队的描述更具体：这是资源路由器在双重解码之后，又把两个连续冒号逆转义成斜杠，从而绕过了应用服务器的规范化检查。

落地到请求长什么样，可以记住一个特征：路径里同时出现两个点（表示上级目录）和连续两个冒号，或者出现被重复编码的正斜杠与冒号。研究团队给出的验证请求，是在项目管理产品的颜色选择器资源路径后面接上一串由两个点、两个冒号和目录名拼成的序列，最终读到的就是通常被多重机制保护的服务器应用配置目录下的文件；团队知识库和代码托管只是换了前面的资源路由，读的文件分别是各自的应用配置和重写规则。

单个文件读取本来不算致命，麻烦的是受保护目录下恰好放着几个文件名固定的敏感文件。研究团队给出的路径是，统一身份认证产品的配置文件就放在受保护目录里，里面以明文保存了应用名称和应用密码。拿到这份凭据以后，攻击者可以直接调用身份认证接口搜索用户、创建新账号，再把新账号加进管理员组，等于把整套平台的管理员权限一起交出去。它把读一个文件直接换算成了接管整个系统，中间不再需要别的漏洞。

这里要如实说明边界。厂商明确写过，利用需要事先知道目标文件的确切名称和相对路径，这个漏洞不允许枚举或列出目录内容，所以它不等于随便就能拖库。研究团队也确认，暂时跳不出应用服务器自身的范围去读系统其它目录。但常见配置文件的名称是公开且固定的，不需要枚举并不能当成安全；只要对方知道一个文件名，剩下的就是发一条请求。另外，统一身份认证产品支持配置来源地址白名单，配了的实例被直接利用的难度会明显上升，但有的单位做了、有的没做，不能当默认前提。

排障先分岔，再决定动手顺序

第一步不是升级，而是分类。先确认这套实例是自己部署还是买的云端服务，云端不在这条漏洞的影响范围里；再确认它能不能从公网或者不可信网络访问。判断分岔很直接：能从公网打开的，按正在被扫描来处理；只能在办公网访问的，也不等于安全，因为内网横向移动之后同样够得着。

第二步核对版本。这条漏洞的下限比很多人想的更靠前，官方为每条产品线分别给出了修复版本号。以团队知识库为例，修复线落在九点二点二六和十点二点二点八和十点五点一，下限追到四点六；统一身份认证产品是六点三点七、七点零点三、七点一点七和七点二点四，下限追到二点一一。项目管理、工单、持续集成以及代码审查产品线同理。很多单位会发现自己的版本号看起来不算旧，却仍然落在受影响区间里，判断时要把下限和上限一起看。

第三步问一句：这套实例有没有接统一身份认证。接了的最危险，因为泄露的凭据直接指向身份系统，攻击者可以一步拿到管理员。没有接的也不能放松，数据库连接串、接口令牌和部署目录里的私钥同样在泄漏范围内。还有一个容易被漏掉的点，代码审查这类老旧工具常常是几年前装的，早就不在维护清单上，很可能既没打补丁，也没人知道它对外可达。

处置顺序与可以验证的判断

处置建议按这个顺序做，理由是先收暴露面，再修版本，最后处理已经发生的损失。

第一，收敛访问面。来不及升级的实例，先把公网入口摘掉，或者只在受控来源地址上开放。这一步不能消除漏洞，但能立刻降低被扫中的概率。

第二，升级到官方给出的修复版本。这是唯一能从根上解决的动作，临时限制来源地址只能算缓兵之计。

第三，轮换凭据。把统一身份认证的应用密码、数据库连接串、接口令牌和部署目录里的私钥当作已经可能泄露来更换，而不是只改服务器的登录密码。

第四，回看日志与账号。厂商建议从访问日志的请求行里寻找入侵痕迹，并给出一条可直接落地的匹配特征：请求行里同时出现上级目录和连续冒号，并且返回了成功状态；研究团队也提供了检测脚本。可以核验的判断有这么几处：身份认证接口的搜索用户、新建用户、加入分组这三个调用，在日志里有没有和正常运维时间对不上的记录；系统里出现不认识的新账号，或者有人被加入了管理员组；敏感配置文件的最后修改时间有没有异常变化。

一个可以直接问出口的诊断问题是：我们一共有多少套自建的项目管理和知识库平台能从公网打开，其中哪些接了统一身份认证，哪些是老版本但已经没人维护。盘这层资产，可以拿域名与证书清单、配置管理库和监控覆盖清单三份记录去对；如果这个问题都答不上来，要补的就不只是补丁，还有资产台账。

来源

1. 奇安信 CERT（安全内参转载）：《Atlassian多款产品任意文件读取漏洞(CVE-2026-21589)安全风险通告》；发布时间：2026-10-08；时区：北京时间（UTC+8）；URL：https://www.secrss.com/articles/94504 ；厂商通告转载，支撑漏洞编号 QVD-2026-75562 与 CVE-2026-21589、公开时间 2026-10-05、CVSS 4.0 评分 9.3、影响量级十万级、在野利用状态“未发现”、PoC/EXP/技术细节已公开、各产品线修复版本与受影响区间下限，以及双重 URL 解码加连续冒号逆转义导致绕过规范化检查的根因描述。

2. watchTowr Labs：《You Will Not Hear About These, Even In Myths (Atlassian Jira, Confluence (and more) Pre-Auth Arbitrary File Read CVE-2026-21589)》；发布时间：2026-10-06；时区：UTC；URL：https://labs.watchtowr.com/you-wont-hear-about-these-even-in-myths-atlassian-jira-confluence-and-more-pre-auth-arbitrary-file-read-cve-2026-21589/ ；一手研究，支撑共享组件修复前后对比、连续冒号转换绕过路径规范化、Jira/Confluence/Bitbucket 的请求形态、Crowd 配置文件明文保存应用名称与应用密码、经身份认证接口搜索用户/创建账号/加入管理员组的完整链路、无法跳出应用服务器自身范围，以及 Crowd 来源地址白名单这一适用边界。

3. 郑州市网络安全协会：《针对Atlassian严重漏洞CVE-2026-21589的利用尝试已经开始》；发布时间：2026-10-08 08:38；时区：北京时间（UTC+8）；URL：https://www.zzwa.org.cn/11137/ ；转述研究团队分析与蜜罐观测，支撑十月六日晚间已出现利用尝试、攻击来源地址清单，以及无法列举目录、需知道精确文件名的边界表述。

4. Atlassian 安全板块（CVE-2026-21589 公告入口）：发布时间：2026-10-05；时区：UTC；URL：https://confluence.atlassian.com/security ；厂商一手公告入口，支撑该漏洞被确认为任意文件访问并已发布修复版本。