
Table of contents
23
Read this in 30 seconds: CVE-2026-21589 is an unauthenticated arbitrary file read in eight Atlassian Data Center products. CISA added it to the Known Exploited Vulnerabilities catalog on October 15, 2026, with a deadline of October 18 and a forensic-triage flag, and Atlassian rates it Critical (9.3).
- One shared library, eight products. watchTowr traces the bug to custom path handling in
atlassian-plugins-webresource, which is why Bitbucket, Confluence, both Jira products, Bamboo, Crowd, Crucible and Fisheye are all affected.- “You need the exact file path” is weaker than it sounds. Atlassian warns that “sensitive files” may be present, and watchTowr read a Crowd configuration file holding a plaintext password in its lab.
- There are 19 fixed builds across the 8 products. Atlassian says “Binary patches are no longer released,” so you upgrade to a maintenance release.
- Public exploit code exists. Rapid7 says “file-read proof-of-concept scripts are public,” so assume attackers have what they need.
- Mitigations exist, but they are stopgaps. Atlassian publishes a WAF rule, a Tomcat RewriteValve rule and a Bitbucket rule, and Rapid7 calls them “limited and are not replacements for patching.”
A bug in a shared library does not care which Atlassian product you thought you had already patched.
The last Atlassian addition to the CISA catalog before this one was November 12, 2024, almost two years ago. Of the 13 earlier Atlassian entries, 8 carry a known-ransomware flag. Atlassian’s own advisory says Data Center products “require immediate attention.”
This article covers what Atlassian and the researchers say about CVE-2026-21589, the fixed version for every product, how the bug works at the level that is public, what we know and do not know about exploitation, and the order to fix things in. It includes two scripts we tested, one that checks your versions and one that searches your logs.
Confluence, Jira, Bitbucket, Bamboo, Crowd, Crucible and Fisheye sit in the middle of how many teams build software. They hold documentation, tickets, source code, builds, identity and code review.
That spread is the risk with CVE-2026-21589. watchTowr says the root cause is custom path-escaping logic in the atlassian-plugins-webresource library, where helper functions “match and replace double colons (::) with forward slashes (/).” Every product that ships the library inherits the bug.
Atlassian’s advisory, released October 5, 2026, says the bug “allows an unauthenticated attacker to access specific files within the web application root directory in affected versions.” It adds that “Exploitation requires prior knowledge of the target file’s exact name and path,” and that attackers cannot list directories.
The record for CVE-2026-21589 carries these facts:
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. It calls this “our internal assessment.”Atlassian’s table for CVE-2026-21589 says “All versions are affected” and that the bug “affects all versions prior to the listed fix versions.” NVD adds a lower bound for six products, showing when the bug was introduced.
| Product | Introduced (per NVD) | Fixed versions |
|---|---|---|
| Bitbucket Data Center | 4.6.0 | 9.4.26, 10.2.8, 10.5.1 |
| Confluence Data Center | 5.10.0 | 9.2.26, 10.2.19 |
| Jira Service Management Data Center | 3.1.0 | 5.12.40, 10.3.26, 11.3.12 |
| Jira Software Data Center | 7.1.0 | 9.12.40, 10.3.26, 11.3.12 |
| Bamboo Data Center | 7.0.1 | 10.2.24, 12.1.12 |
| Crowd Data Center | 2.11.0 | 6.3.7, 7.0.3, 7.1.7, 7.2.4 |
| Crucible | not given | 4.9.15 |
| Fisheye | not given | 4.9.15 |
Atlassian “recommends patching to the fixed LTS version or later.” Crucible and Fisheye are easy to miss, because they may not sit in the same inventory as Jira.
Do not eyeball version strings across a whole estate. This script, which we wrote and tested against both fixed and affected builds, classifies each product and version against Atlassian’s table.
import re, sys
FIXED = {
"bitbucket": ["9.4.26", "10.2.8", "10.5.1"],
"confluence": ["9.2.26", "10.2.19"],
"jira-service-management": ["5.12.40", "10.3.26", "11.3.12"],
"jira-software": ["9.12.40", "10.3.26", "11.3.12"],
"bamboo": ["10.2.24", "12.1.12"],
"crowd": ["6.3.7", "7.0.3", "7.1.7", "7.2.4"],
"crucible": ["4.9.15"],
"fisheye": ["4.9.15"],
}
def v(s):
if not re.fullmatch(r"\d+(\.\d+){1,3}", s):
raise ValueError(f"unrecognised version: {s!r}")
return tuple(int(x) for x in s.split("."))
def verdict(product, version):
fixes = sorted(FIXED[product], key=v)
cur = v(version)
if cur >= v(fixes[-1]):
return f"at or above {fixes[-1]}: assumed fixed (confirm in the release notes)"
same = [f for f in fixes if v(f)[:2] == cur[:2]]
if same:
return "fixed" if cur >= v(same[0]) else f"AFFECTED, update to {same[0]}"
target = next(f for f in fixes if v(f) > cur)
return f"AFFECTED, no fix listed for this train, move to {target} or later"
for line in sys.stdin:
if line.strip() and not line.startswith("#"):
product, version = line.split()
print(f"{product:<25} {version:<9} {verdict(product, version)}")
Feed it a list of product version pairs and you get a verdict for each:
python3 atlassian_check.py < inventory.txt
# confluence 9.2.25 AFFECTED, update to 9.2.26
# confluence 9.2.26 fixed
# bitbucket 9.3.4 AFFECTED, no fix listed for this train, move to 9.4.26 or later
# crowd 7.1.6 AFFECTED, update to 7.1.7
# crucible 4.9.14 AFFECTED, update to 4.9.15
This is our illustration of Atlassian’s table, not an Atlassian tool. It treats a version at or above the highest fixed build as fixed, which is an assumption, so confirm against the release notes for your product.

Here is what the researchers say about CVE-2026-21589, at the level that matters to a defender. watchTowr compared vulnerable and patched Jira, Confluence and Bitbucket packages and found that user-supplied resource names pass through the library’s path handling into a local file read.
watchTowr says it was “not able to traverse outside of the Tomcat context.” It could read files inside the web root, including WEB-INF, which is where products keep configuration. Its example was a Crowd integration configuration file that stored the application’s password in plaintext in its lab, which let it create users and change group membership.
We will not describe the requests. The vendor and researchers have not given a recipe in prose, and we are not going to reconstruct one. What matters is what is public. watchTowr published a detection tool, and Rapid7 says that “Detailed technical analysis and file-read proof-of-concept scripts are public,” including a Nuclei template.
Our reading, and it is an inference: “you need the exact path” is a speed bump, not a wall. Product layouts are public, so the files worth reading sit in predictable places. Treat any secret stored in a web-root-reachable file as exposed. The CVSS 4.0 vector, with high impact on the vulnerable system and on subsequent systems, fits that reading, though it is Atlassian’s own assessment.
| Date | Event | Source |
|---|---|---|
| Oct 5 | Atlassian advisory; NVD record published | Atlassian; NVD |
| Oct 6 | watchTowr technical analysis and detection tool | watchTowr |
| Oct 7 | Rapid7 post says PoC scripts are public | Rapid7 |
| Oct 8 | Rapid7 ships a Jira Software Data Center check | Rapid7 |
| Oct 15 | CISA adds it to KEV; NVD record updated | CISA; NVD |
| Oct 18 | KEV due date | CISA KEV catalog |

The honest answer for CVE-2026-21589 is “CISA says yes, and the detail is thin.” CISA’s catalog lists it, with a forensic-triage flag, which is the strongest evidence. Everything else is more cautious.
Atlassian found no evidence for Cloud and “cannot confirm” for Data Center. watchTowr’s write-up does not say whether the bug has been exploited, and Rapid7 does not say it observed exploitation. Some secondary articles describe honeypot attempts within hours of the proof of concept. We could not source those to a primary page, so we are not repeating them.
For planning, the combination matters more than any single claim: a listing in the catalog, public exploit code and a Nuclei template.
Atlassian’s first instruction for CVE-2026-21589 is to “Remove your instance from the internet until you can patch or apply mitigations, if possible.” It then publishes three stopgaps, and Rapid7 describes them as “limited and are not replacements for patching.”
.. immediately adjacent to /, \ or ::, including URL-encoded forms.rewrite.config rule.urlrewrite.xml, on every node and mirror.Here is the vendor’s published regex, which all three options use, and the server.xml line that Option 2 adds:
(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*
<Valve className="org.apache.catalina.valves.rewrite.RewriteValve" />
Take the full rewrite.config and urlrewrite.xml blocks from the advisory itself, not from a copy. Back up first, apply the change node by node in a cluster, and test that your rule blocks the encoded forms.

Atlassian’s detection guidance is short. “URL-decode each access-log request line (up to two decoding passes) before searching, then check for .. immediately adjacent to /, \, or ::,” or search the raw lines with the regex above.
This script does both. We tested it on synthetic logs, where it flagged three encoded variants and ignored a harmless filename containing ... Run it over your reverse proxy or application access logs:
import re, sys
from urllib.parse import unquote
VENDOR = re.compile(r"(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*")
DECODED = re.compile(r"(?:/|\\|::)\.\.|\.\.(?:/|\\|::)")
def decode(s, passes=2):
for _ in range(passes):
n = unquote(s)
if n == s:
break
s = n
return s
hits = 0
for no, line in enumerate(sys.stdin, 1):
line = line.rstrip("\n")
if VENDOR.match(line) or DECODED.search(decode(line)):
hits += 1
print(f"line {no}: {line[:110]}")
print(f"{hits} suspicious line(s)")
sys.exit(1 if hits else 0)
python3 atlassian_log_hunt.py < access.log
# line 3: 198.51.100.9 - - [05/Oct/2026:10:03:11 +0000] "GET /example/..%2fWEB-INF/test HTTP/1.1" 404 120
# line 4: ... "GET /example/%252e%252e%252fWEB-INF/test HTTP/1.1" 404 120
# line 5: ... "GET /example/..::WEB-INF/test HTTP/1.1" 404 120
# 3 suspicious line(s)
A hit is a lead, not a verdict. A 404 on a probe means something different from a 200 with a large response, so read the status and size before you escalate. A clean result does not clear you either, because the access log may not be the only place a request leaves a trace.
CISA flags CVE-2026-21589 for forensic triage, and Atlassian says it “cannot confirm if your instances have been affected.” So preserve evidence before you upgrade or rebuild anything:
Rapid7 adds that you should look for signs of compromise “even after the patch has been applied,” and rotate exposed credentials and secrets after containing the affected systems.
Work through these in order for CVE-2026-21589:
Numbers make CVE-2026-21589 concrete. Suppose your estate has six instances, and the script gives you these verdicts:
| Instance | Version | Verdict |
|---|---|---|
| Public Confluence | 9.2.25 | Affected, update to 9.2.26 |
| Internal Jira Software | 10.3.26 | Fixed |
| Bitbucket mirror | 9.3.4 | Affected, no fix in its train, move to 9.4.26 or later |
| Crowd | 7.1.6 | Affected, update to 7.1.7 |
| Forgotten Crucible | 4.9.14 | Affected, update to 4.9.15 |
Here is the order we would work in. It is our suggestion, not Atlassian’s.
Notice the pattern: the version script took seconds, and the real work is the Bitbucket upgrade window. Plan the slow one before the fast ones are done.
We counted this from the catalog file. There are 14 Atlassian entries including this one, and 8 of the earlier 13 carry a known-ransomware flag. The flag on CVE-2026-21589 is “Unknown,” which means it has not been linked to ransomware yet, not that it never will be.
This is also not the first file-read or path-traversal bug in the list. CVE-2019-3398 (Confluence path traversal), CVE-2021-26085 (Confluence pre-authorization arbitrary file read) and CVE-2021-26086 (Jira path traversal) are all in the catalog. You can check the entry yourself:
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
| jq '.vulnerabilities[] | select(.cveID=="CVE-2026-21589")
| {cveID, dateAdded, dueDate, forensicTriage, knownRansomwareCampaignUse, cwes}'
# {
# "cveID": "CVE-2026-21589",
# "dateAdded": "2026-10-15",
# "dueDate": "2026-10-18",
# "forensicTriage": "Yes",
# "knownRansomwareCampaignUse": "Unknown",
# "cwes": ["CWE-552"]
# }
| Point | Source A | Source B | What we used |
|---|---|---|---|
| Exploitation | CISA catalog: exploited | Atlassian: Cloud no evidence, Data Center “cannot confirm”; watchTowr and Rapid7 silent | The catalog entry, with the gap stated |
| Affected versions | Atlassian: “All versions are affected” | NVD: introduced in 4.6.0 to 7.1.0, by product | Treat older versions as affected |
| CWE | Advisory: none named | CISA and NVD: CWE-552 | CWE-552 |
| Server editions | Advisory: silent | Rapid7: unsupported versions affected | Treat them as affected, and ask Atlassian |
So yeah, this is where we mention our own work. Handling CVE-2026-21589 starts with knowing which Atlassian instances you have and which are reachable from the internet, because Atlassian’s own first step is to take exposed ones offline.
Our AI VAPT services combine automated and human-led testing against exposed infrastructure, and the exposure review above is part of that work. On infrastructure you own, XHack AI’s autonomous pentesting covers reconnaissance, port scanning and service enumeration, and it streams its work to a live terminal so you can watch what it runs. A pentest report documents what was tested. It does not certify that an instance is patched or clean, and it does not replace the upgrade or the log review. XHack does not store your data, and your session data stays on your own computer.
CVE-2026-21589 is an unauthenticated arbitrary file read in eight Atlassian Data Center products. Atlassian rates it Critical, 9.3 on CVSS 4.0, and says it lets an attacker access specific files in the web application root. CISA lists it as exploited.
Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo and Crowd (all Data Center), plus Crucible and Fisheye. Atlassian says Cloud products are patched and need no action.
Upgrade to a fixed build: Bitbucket 9.4.26, 10.2.8 or 10.5.1, Confluence 9.2.26 or 10.2.19, and the others in the table above. If you cannot patch yet, take the instance off the internet and apply Atlassian’s WAF, RewriteValve or urlrewrite rule.
CISA added it to the Known Exploited Vulnerabilities catalog on October 15, 2026. Atlassian says it cannot confirm whether Data Center instances were affected, and public proof-of-concept scripts exist.
Yes, Atlassian says exploitation “requires prior knowledge of the target file’s exact name and path,” and that attackers cannot list directories. That limits the bug, but configuration files live in predictable places, so treat secrets in the web root as exposed.
URL-decode each access-log line up to two times and look for .. next to /, \ or ::, or search the raw lines with Atlassian’s regex. The script above does both, and a hit is a lead to investigate, not proof of compromise.
CVE-2026-21589 is a critical, unauthenticated file read in a library shared by eight Atlassian Data Center products, and it is now in the Known Exploited Vulnerabilities catalog with public exploit code.
Inventory every instance, preserve the logs, upgrade to a fixed build, and rotate any secret that a web-root file could have held. The fix is available. The hard part is finding the Crucible install nobody remembered.
Categories
Related articles