路径遍历漏洞自查：怎么从访问日志里找出已经被人扫过的痕迹

最近 Atlassian 披露了 CVE-2026-21589，一个影响八个 Data Center 产品的路径遍历漏洞，CVSS 9.3。未认证攻击者可以读取 Web 应用根目录下的特定文件（前提是知道确切文件名和路径，不能列目录）。

这类漏洞的排查思路是通用的，值得记下来。

漏洞本身 Atlassian 的描述是：攻击者无需登录，可以读取 Web 应用根目录中的特定文件。受影响产品覆盖 Confluence、Jira Software、Jira Service Management、Bamboo、Crowd、Bitbucket、Crucible、Fisheye 的 Data Center 版。

官方明确说了：无法确认你的实例是否已经受到影响。所以自查是必须的。

临时缓解 官方给了三条拦截规则，都是阻断 URL 中「..」紧邻「/」「\」或「::」的请求，包括 URL 编码形式：

• 八个产品通用：在 WAF 或反向代理上加规则。
• Confluence/Jira/Bamboo/Crowd：加 Tomcat RewriteValve 规则，每个节点都要装，装完重启。
• Bitbucket：在 urlrewrite.xml 加规则，每个节点、mirror、mirror-farm 节点都要加，然后重启。
• Crucible/Fisheye：只有 WAF 这一条路。

官方强调这些缓解是有限的，不能替代打补丁。

日志怎么查 Atlassian 给了两种方法：

1. 对每个请求行做最多两次 URL 解码，然后找「..」紧邻「/」「\」或「::」的模式。
2. 直接对原始日志行跑官方给的阻断模式。

实际操作中的几个坑

• 要解码多次。攻击者会用双重甚至三重编码绕过单次解码的检测，%252e%252e 解一次是 %2e%2e，解两次才是 ..
• 注意大小写和变体。不同 Web 服务器对 URL 规范化的处理不同， IIS 和 Tomcat 的行为就有差异。
• 区分成功和失败。这是官方没给答案、但真正重要的部分。日志里看到 404 的扫描请求和看到 200 的成功读取，处置级别完全不同。所以查的时候一定要带上状态码一起过滤。
• 时间范围要拉长。漏洞可能在你打补丁之前很久就被利用了，只查最近一周是不够的。

一条通用建议 把这类检测做成定期任务，而不是出事才跑。每周自动扫一次访问日志，把命中的异常模式推到安全频道。成本很低，但能显著缩短发现时间。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

双重编码一定要解码两次再匹配，%252e 解一次还是 %2e。另外过滤时要带上状态码，404 的扫描请求和 200 的成功读取处置级别完全不同。

补充一点实操：光靠在日志里搜 .. 基本抓不到人，现在扫描器都走双重 URL 编码，日志里留下的是看着正常的路径。我们的办法是把规范化之后的路径单独打一个字段记进日志，再对带 ..、%2e、反斜杠的请求做聚合，命中量突然涨就告警。静态资源目录的日志建议单独存，不然误报能淹死人。

日志排查这招我们也在用，补充一个细节：光搜上级目录符号不够，编码过的和双重编码的也要一起匹配，最好再按状态码过滤，返回成功但路径异常的才值得人工看。告警阈值设成同一 IP 短时间多次命中，误报能降一大半。