CVE-2026-21589 lets an unauthenticated attacker read files from the web root of self-managed Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible and Fisheye. If you run any of them, upgrade to a fixed release now, check your access logs back to early October, and rotate credentials stored in configuration files if a read may have succeeded. CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 15, 2026.

Atlassian Cloud is not part of the job: Atlassian says it has already patched affected Cloud products.

The vulnerability

Atlassian’s CVE record describes an arbitrary file access flaw (CWE-552, files or directories accessible to external parties) that “allows an unauthenticated attacker to access specific files within the web application root directory.” Atlassian scores it CVSS 4.0 9.3, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H.

Read that vector carefully (our CVSS v4.0 walkthrough covers each metric). The vulnerable product loses confidentiality only (VC:H, VI:N, VA:N). The high scores for subsequent systems (SC:H/SI:H/SA:H) reflect what stolen files can unlock elsewhere: credentials in a configuration file are worth more than the file.

Two limits from the record matter for triage:

• The attacker needs the exact name and path of the file. The flaw “does not allow attackers to enumerate or list directory contents.”
• Atlassian says “in some configurations, there may be some sensitive files that make this highly severe.” Whether a given instance is a nuisance or a breach depends on what sits in its web root.

Root cause, per watchTowr

watchTowr Labs diffed vulnerable and patched Jira, Confluence and Bitbucket builds and, as summarized by Rapid7, found a path traversal in Atlassian’s web-resource handling where double-colon (::) sequences can act as path separators during request processing. In watchTowr’s testing the attacker could not leave the Tomcat context but could read files throughout the web root, including the protected WEB-INF/web.xml.

The most serious example in the research is Crowd. In a Crowd deployment connected to Jira, reading WEB-INF/classes/crowd.properties exposed application credentials. watchTowr used them to create a user and add it to jira-administrators. Rapid7 notes that Crowd’s IP allowlisting for applications can block that second step.

Timeline

Reports differ on what was published. Help Net Security says watchTowr built but did not publish an exploit and released a vulnerability checker. Rapid7 says file-read proof-of-concept scripts and a Nuclei template are publicly available. Either way, detailed root-cause analysis has been public since October 6, and you should assume working exploits exist.

CISA’s SSVC values in the CVE record are Exploitation active, Automatable no, Technical Impact total. “Automatable: no” fits the need to know file paths per target; it is not a reason to wait. Our Vulnrichment guide explains how to read these fields.

What to patch

Upgrade to one of these releases or later. Versions are from Atlassian’s CVE record; Atlassian’s Jira ticket says versions past end of life may also be affected, so an unsupported release needs a move to a fixed supported line, not a hunt for a patch.

Don’t forget the quiet ones. Crowd and Bamboo often run on separate hosts owned by a different team, and Crowd is where the published credential-theft path lives.

If you cannot patch today

Atlassian offers three interim mitigations, described in its per-product Jira tickets:

1. A WAF or reverse-proxy rule (all products) that blocks URLs where .. sits next to /, \ or ::, including URL-encoded forms. Atlassian asks you to test that encoded variants are blocked.
2. A Tomcat RewriteValve (Confluence, Jira Software, Jira Service Management, Bamboo, Crowd): add <Valve className="org.apache.catalina.valves.rewrite.RewriteValve" /> inside the application’s <Context> in conf/server.xml, install Atlassian’s rewrite.config under the application’s WEB-INF, and restart each node in turn.
3. A urlrewrite.xml rule for Bitbucket.

Take the rule content from Atlassian’s ticket for your product, not from a third-party blog. Atlassian is direct about the value: the mitigations are “limited and not a replacement for patching.” Where possible, remove unpatched instances from internet reach until they are upgraded.

How to hunt

Patching closes the hole; it does not tell you whether someone already read a file. Rapid7 recommends checking for compromise even after patching and describes a log search: decode each request line up to twice, then look for .. directly next to /, \ or ::.

Here is a small implementation of that approach. It is our script, not Atlassian’s published regex, and it will flag some benign requests. We ran it with Python 3 against a five-line synthetic log; the request paths in that test were made up to exercise the matcher and are not real exploit strings.

#!/usr/bin/env python3
"""Flag access-log lines with '..' next to '/', '\\' or '::' after up to two
rounds of URL decoding. Illustrates the approach Rapid7 describes for
CVE-2026-21589; it is not Atlassian's published regex.
Usage: python3 scan_access_log.py access_log.txt"""
import re
import sys
from urllib.parse import unquote

PATTERN = re.compile(r"(\.\.(/|\\|::))|((/|\\|::)\.\.)")

def suspicious(line):
    candidates = [line]
    decoded = line
    for _ in range(2):
        decoded = unquote(decoded)
        candidates.append(decoded)
    return any(PATTERN.search(c) for c in candidates)

with open(sys.argv[1], errors="replace") as f:
    for n, line in enumerate(f, 1):
        if suspicious(line):
            print(f"{n}: {line.rstrip()}")

On the synthetic log it flagged a raw ::..:: request, a double-encoded %252e%252e%252f request and an encoded backslash variant, and ignored a filename containing report..final.

When you triage hits:

• Start from October 5. Scan back at least to the advisory date; extend further if your logs allow, because the CVE record lists every release before the fixes as affected.
• Look at the status code and size. A 200 with a body on a traversal-shaped request deserves more attention than a 404.
• Check every node and the proxy. In a Data Center cluster each node has its own Tomcat access log; a WAF or load balancer in front may log what the nodes did not.
• Note what the path aimed at. Requests for WEB-INF paths, configuration files or .properties files tell you which secrets to rotate.

If a read may have succeeded

Treat any secret in a web-root file as exposed, then contain and rotate in this order:

1. Crowd application credentials from crowd.properties, and review Crowd’s application IP allowlists.
2. Recently created users and group changes, especially additions to jira-administrators or other admin groups since October 5.
3. Database credentials, API tokens and integration secrets held in configuration files the requests could have reached.
4. Downstream systems those credentials unlock: build agents behind Bamboo, repositories behind Bitbucket, SSO-linked applications behind Crowd.

Rapid7’s advice matches: contain first, then rotate exposed credentials and secrets. If you work to US federal timelines, this flaw also falls under BOD 26-04’s forensic triage requirements, which the required action of every KEV entry added in October cites.

Limits of this article

We have not tested the vulnerability or Atlassian’s mitigations. The root-cause details come from watchTowr’s research as reported by Rapid7 and Help Net Security; we did not reach watchTowr’s original post or Atlassian’s main advisory page during research, and rely on the CVE record and Atlassian’s public Jira tickets for versions and mitigations. No public source we found names the files requested in observed attacks.

Sources and verification