XHack Logo
XHack
Products
Services
Compliance
Pricing
Resources
Company
Sign upLogin
XHack Logo
XHackOffensive Security

Certified offensive security team delivering penetration testing evidence written for your auditor.

OSCP+OSCPC-AI/MLPenCASA
support@xhack.io

24/7 SOC Operations

XHack Status
Under attack? Get help now
Services
  • VAPT Services
  • Red Teaming
  • SOC Services
  • Threat Intelligence
  • Incident Response
  • Managed Testing
Pricing
  • Platform Plans
  • Services Pricing
Compliance
  • SOC 2
  • PCI DSS
  • ISO 27001
  • GDPR
  • HIPAA
  • ISO 42001
  • AI Maturity Assessment
  • TX-RAMP
  • NBFC / SECP
  • All Frameworks
Products
  • Vulnerability Assessment
  • GitGuard
  • AI Probe
  • SOC Dashboard
  • AI Agent
  • Cloud Investigation
Comparison
  • XBOW vs XHack
  • Horizon3 vs XHack
  • Strix vs XHack
  • Pentera vs XHack
Resources
  • Platform Tour
  • All Features
  • Install the Agent
  • XHack AI
  • Documentation
  • Blog
  • Case Studies
  • Documents
  • FAQ
Company
  • About Us
  • Our Team
  • Certifications
  • Security and Trust
  • VAPT Explained
  • Contact

© 2026 XHack. All rights reserved.

Security & TrustVulnerability DisclosurePrivacy PolicyTerms of ServiceRefund Policy
Blog/News

CVE-2026-21589: The Critical Atlassian File Read Bug Hitting Eight Products

XHack

XHack

Author

October 15, 2026

16 min read

CVE-2026-21589: The Critical Atlassian File Read Bug Hitting Eight Products

Table of contents

23

Why CVE-2026-21589 Matters: Eight Products, One Library

What CVE-2026-21589 Is, According to Atlassian

Fixed Versions for CVE-2026-21589, Product by Product

Check your versions with a script

How the CVE-2026-21589 Bug Works, and Where the Public Detail Stops

The CVE-2026-21589 Timeline: Advisory to Catalog in Ten Days

Is CVE-2026-21589 Being Exploited? What Each Source Says

Mitigations for CVE-2026-21589 If You Cannot Patch Today

Hunting for CVE-2026-21589 in Your Logs

The Forensic Step Comes Before the CVE-2026-21589 Patch

Fixing CVE-2026-21589 in the Right Order

A Worked Example: Six Instances, One Afternoon

Pattern Check: Atlassian in the KEV Catalog

Where the Sources Disagree About CVE-2026-21589

How XHack Reads CVE-2026-21589

FAQ: CVE-2026-21589 Questions Answered

What is CVE-2026-21589?

Which products does CVE-2026-21589 affect?

How do I fix CVE-2026-21589?

Is CVE-2026-21589 being exploited?

Does CVE-2026-21589 need the exact file path?

How do I check my logs for CVE-2026-21589?

The Bottom Line on CVE-2026-21589

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.

Why CVE-2026-21589 Matters: Eight Products, One Library

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.

What CVE-2026-21589 Is, According to Atlassian

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:

  • Weakness: CWE-552, files or directories accessible to external parties. The advisory names no CWE, but CISA’s catalog and NVD do.
  • Severity: Atlassian rates it Critical, 9.3 on CVSS 4.0, with the 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. It calls this “our internal assessment.”
  • Scope: Data Center products only. “Affected Atlassian Cloud products have been patched.”
  • Exploitation: none confirmed by Atlassian. For Cloud it found no evidence. For Data Center it “cannot confirm if your instances have been affected.”
  • Credit: the advisory credits no reporter.

Fixed Versions for CVE-2026-21589, Product by Product

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.

ProductIntroduced (per NVD)Fixed versions
Bitbucket Data Center4.6.09.4.26, 10.2.8, 10.5.1
Confluence Data Center5.10.09.2.26, 10.2.19
Jira Service Management Data Center3.1.05.12.40, 10.3.26, 11.3.12
Jira Software Data Center7.1.09.12.40, 10.3.26, 11.3.12
Bamboo Data Center7.0.110.2.24, 12.1.12
Crowd Data Center2.11.06.3.7, 7.0.3, 7.1.7, 7.2.4
Cruciblenot given4.9.15
Fisheyenot given4.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.

Check your versions with a script

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.

Atlassian Data Center products affected by CVE-2026-21589 with the fixed versions for each, from the vendor advisory
Eight products, 19 fixed builds

How the CVE-2026-21589 Bug Works, and Where the Public Detail Stops

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.

The CVE-2026-21589 Timeline: Advisory to Catalog in Ten Days

DateEventSource
Oct 5Atlassian advisory; NVD record publishedAtlassian; NVD
Oct 6watchTowr technical analysis and detection toolwatchTowr
Oct 7Rapid7 post says PoC scripts are publicRapid7
Oct 8Rapid7 ships a Jira Software Data Center checkRapid7
Oct 15CISA adds it to KEV; NVD record updatedCISA; NVD
Oct 18KEV due dateCISA KEV catalog
CVE-2026-21589 timeline from the October 5 advisory to the October 18 CISA deadline
Advisory to KEV in ten days, with public exploit code in between

Is CVE-2026-21589 Being Exploited? What Each Source Says

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.

Mitigations for CVE-2026-21589 If You Cannot Patch Today

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.”

  • Option 1, all products: a WAF or proxy rule that blocks .. immediately adjacent to /, \ or ::, including URL-encoded forms.
  • Option 2, Confluence, JSM, Jira, Bamboo and Crowd: enable Tomcat’s RewriteValve and add a rewrite.config rule.
  • Option 3, Bitbucket only: add a rule to 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.

The three Atlassian mitigations for CVE-2026-21589: a WAF rule for all products, Tomcat RewriteValve for five products, and urlrewrite.xml for Bitbucket
Three stopgaps, none a replacement for the patch

Hunting for CVE-2026-21589 in Your Logs

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.

The Forensic Step Comes Before the CVE-2026-21589 Patch

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:

  1. Copy the access logs from the application and any proxy or WAF in front of it.
  2. Save the configuration files and a record of the running version.
  3. List accounts and group changes in Crowd, Jira and Confluence. watchTowr’s lab example ended in new users and changed group membership, so check for exactly that.

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.

Fixing CVE-2026-21589 in the Right Order

Work through these in order for CVE-2026-21589:

  1. Inventory every instance, including Crucible, Fisheye and the development or disaster-recovery copies. Run the version script above.
  2. Take internet-facing instances offline or restrict them until you patch, as Atlassian instructs.
  3. Patch to a fixed build for CVE-2026-21589. Use the table, and move to the fixed LTS version or later.
  4. Apply the mitigation on anything you cannot patch today, node by node.
  5. Hunt in your logs, with the script above, before and after the upgrade.
  6. Rotate secrets stored in files that sit under a web root, and review Crowd, Jira and Confluence for new accounts.

A Worked Example: Six Instances, One Afternoon

Numbers make CVE-2026-21589 concrete. Suppose your estate has six instances, and the script gives you these verdicts:

InstanceVersionVerdict
Public Confluence9.2.25Affected, update to 9.2.26
Internal Jira Software10.3.26Fixed
Bitbucket mirror9.3.4Affected, no fix in its train, move to 9.4.26 or later
Crowd7.1.6Affected, update to 7.1.7
Forgotten Crucible4.9.14Affected, update to 4.9.15

Here is the order we would work in. It is our suggestion, not Atlassian’s.

  1. The public Confluence first. Atlassian’s instruction is to remove internet-facing instances until you can patch, and a one-version bump to 9.2.26 is the quickest fix on the list.
  2. Crowd second. watchTowr’s lab example showed what a stolen Crowd configuration file allowed, which makes the identity store the costliest one to leave open.
  3. Bitbucket third, with a window. Version 9.3.4 has no fix in its own train, so it needs a move to the 9.4.26 line. Atlassian says it releases “new maintenance releases” for supported versions “instead of binary patches,” so there is no quick hotfix to apply.
  4. Crucible last, but not forgotten. It is the instance most likely to be missing from your inventory, and an instance nobody tracks is one nobody patches.

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.

Pattern Check: Atlassian in the KEV Catalog

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"]
# }

Where the Sources Disagree About CVE-2026-21589

PointSource ASource BWhat we used
ExploitationCISA catalog: exploitedAtlassian: Cloud no evidence, Data Center “cannot confirm”; watchTowr and Rapid7 silentThe catalog entry, with the gap stated
Affected versionsAtlassian: “All versions are affected”NVD: introduced in 4.6.0 to 7.1.0, by productTreat older versions as affected
CWEAdvisory: none namedCISA and NVD: CWE-552CWE-552
Server editionsAdvisory: silentRapid7: unsupported versions affectedTreat them as affected, and ask Atlassian

How XHack Reads CVE-2026-21589

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.

FAQ: CVE-2026-21589 Questions Answered

What is CVE-2026-21589?

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.

Which products does CVE-2026-21589 affect?

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.

How do I fix CVE-2026-21589?

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.

Is CVE-2026-21589 being exploited?

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.

Does CVE-2026-21589 need the exact file path?

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.

How do I check my logs for CVE-2026-21589?

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.

The Bottom Line on CVE-2026-21589

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

News

Previous

XHack AI Agent Features: The Complete 2026 Guide

Next

Best AI Hacking Tools for Individual Researchers (Not Enterprise Platforms)

On this page

Why CVE-2026-21589 Matters: Eight Products, One Library

What CVE-2026-21589 Is, According to Atlassian

Fixed Versions for CVE-2026-21589, Product by Product

Check your versions with a script

How the CVE-2026-21589 Bug Works, and Where the Public Detail Stops

The CVE-2026-21589 Timeline: Advisory to Catalog in Ten Days

Is CVE-2026-21589 Being Exploited? What Each Source Says

Mitigations for CVE-2026-21589 If You Cannot Patch Today

Hunting for CVE-2026-21589 in Your Logs

The Forensic Step Comes Before the CVE-2026-21589 Patch

Fixing CVE-2026-21589 in the Right Order

A Worked Example: Six Instances, One Afternoon

Pattern Check: Atlassian in the KEV Catalog

Where the Sources Disagree About CVE-2026-21589

How XHack Reads CVE-2026-21589

FAQ: CVE-2026-21589 Questions Answered

What is CVE-2026-21589?

Which products does CVE-2026-21589 affect?

How do I fix CVE-2026-21589?

Is CVE-2026-21589 being exploited?

Does CVE-2026-21589 need the exact file path?

How do I check my logs for CVE-2026-21589?

The Bottom Line on CVE-2026-21589

Related articles

Continue reading

CVE-2026-76519: Cisco&#8217;s Second Critical Email Gateway Zero-Day in a Month

News

CVE-2026-76519: Cisco’s Second Critical Email Gateway Zero-Day in a Month

CVE-2026-76519 lets an unauthenticated attacker get root via a crafted email attachment on Cisco Secure Email Gateway. F...

Read article
CVE-2026-102764: Inside the Critical BeyondTrust Remote Support Zero-Day

News

CVE-2026-102764: Inside the Critical BeyondTrust Remote Support Zero-Day

CVE-2026-102764 is a critical BeyondTrust Remote Support zero-day, exploited by a China-nexus actor since August. Timeli...

Read article
CVE-2026-104935: The Ivanti Connect Secure Zero-Day Exploit Chain, Explained

News

CVE-2026-104935: The Ivanti Connect Secure Zero-Day Exploit Chain, Explained

CVE-2026-104935 is an exploited Ivanti Connect Secure zero-day. Affected and fixed builds, Volexity indicators, the unpa...

Read article