Atlassian disclosed the flaw, CVE-2026-21589, on October 5 and rated it 9.3 out of 10, warning that unauthenticated attackers can read specific files from the web application root of self-hosted Data Center products.
CVE-2026-21589: what the flaw allows
Atlassian describes CVE-2026-21589 as a path traversal vulnerability that lets an attacker with no login access read particular files in the web application root directory of eight Data Center products. The attacker must already know the exact file name and path; they cannot list directory contents. Atlassian says the web application root may contain sensitive files "in some configurations," which raises the risk for affected instances.
Products affected and inconsistencies in fixed-version reporting
Atlassian said the flaw affects eight Data Center products and listed fixed versions as of October 6. The advisory warns that every version before the listed fixed version is affected — and that may include versions that have reached end of life. The company recommends upgrading to a fixed long-term support (LTS) version or later.
Public records show inconsistencies in how those fixed versions are reported. For Crowd's 7.1 branch, a ticket's fix-version field said 7.1.7 while a table in the same ticket showed 7.1.6 and also listed 7.1.6 as affected. The CVE record filed by Atlassian gives different numbers for two products: for Crowd it lists 7.1.1 (a Crowd 7.1 release the notes date to November 27, 2025) and for Bamboo one field said 10.2.4 while the record's description said 10.2.24.
The CVE record also listed the older Server editions as affected — marking every version of Bamboo Server, Bitbucket Server, Confluence Server, and Crowd Server as affected and listing no fixed versions for them. For Jira Software Server it listed versions from 9.12.40 as unaffected, for Jira Service Management Server from 5.12.40, and for Crucible Server and Fisheye Server from 4.9.15; the record did not say whether Server licenses can run those versions. Atlassian's release notes show Crowd has had no Server release since version 5.2 in September 2023, so none of the fixed Crowd versions are Server releases.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we buildTemporary mitigations Atlassian published
Atlassian offered three temporary blocking rules it calls mitigations. All three block requests whose URL contains ".." directly adjacent to "/", "\" or "::", including URL-encoded forms. The company emphasizes these mitigations "are limited and not a replacement for patching your instance."
- All eight products: use a web application firewall (WAF) or reverse proxy rule that blocks matching URLs.
- Confluence, Jira Software, Jira Service Management, Bamboo and Crowd: apply a Tomcat RewriteValve rule on each node; after installation each node must be shut down and restarted.
- Bitbucket Data Center: add a rule to urlrewrite.xml on every node, mirror and mirror-farm node, followed by a restart.
- Crucible and Fisheye: only the WAF/reverse-proxy option is available.
Atlassian advises customers who cannot upgrade all at once to take the instance offline if possible and to restrict any instance reachable from the public internet — including instances that require a login — until it is upgraded or a temporary blocking rule is in place.
How to check logs for past access
Atlassian said its cloud products have already been patched, that Bitbucket Cloud is not affected, and that its investigation has not found evidence of exploitation in cloud systems. For self-hosted instances the advisory is explicit: "Atlassian cannot confirm if your instances have been affected by this vulnerability."
The company tells customers to search access logs using two suggested methods: URL-decode each request line up to two times and look for ".." directly next to "/", "\" or "::"; or run Atlassian's block pattern over the raw log lines. The advisory does not provide guidance on how to distinguish failed attempts from requests that successfully returned files, nor does it say what steps to take after finding matching log entries beyond upgrading or applying mitigations.
What this means for technologists, procurement teams, and cloud customers
- Technologists and security teams: prioritize inventorying Data Center instances reachable from the internet and apply the WAF/reverse-proxy rule immediately where patching cannot be done at once; follow Atlassian's log-search methods to hunt for signs of access.
- Procurement and operations leaders at affected enterprises: treat this as a version-management problem — Atlassian warned fixed versions exist and recommends upgrading to a fixed LTS release or later — and plan node restarts for Tomcat or urlrewrite.xml changes where required.
- Cloud customers: no action required for cloud-hosted Atlassian products; Atlassian says those products have been patched and its cloud investigation has not found evidence of exploitation. Bitbucket Cloud is explicitly not affected.
The disclosure puts a bright line under two facts: the vulnerability is exploitable over the network without credentials, and Atlassian's public record contains inconsistencies that customers must reconcile against their own inventory. For self-hosted Data Center operators the immediate choices are straightforward — restrict internet access or apply the blocking rules, then upgrade — but the advisory leaves open whether any self-hosted instances were accessed before fixes and how to verify a successful read. That unresolved point will be the practical question for security teams in the days ahead.
