Atlassian's CVSS 9.3 flaw lets anyone read files from eight Data Center products' web root without logging in. Fixed versions, mitigations and what to rotate.
What happened
On 5 October 2026 Atlassian disclosed CVE-2026-21589, an arbitrary file access flaw that lets an unauthenticated attacker read specific files from the web application root of its self-hosted products. Atlassian rates it 9.3 (Critical) under CVSS 4.0, with network attack vector, low complexity and no privileges or user interaction. The weakness is CWE-552.
Affected: Bitbucket Data Center, Confluence Data Center, Jira Software Data Center, Jira Service Management Data Center, Bamboo Data Center, Crowd Data Center, Crucible and Fisheye. Atlassian's advisory says all versions before the fixed releases are affected; its CVE record gives the introduction points shown below. Atlassian Cloud has already been patched and needs no customer action. The advisory covers Data Center; it does not list Server editions.
| Product | Introduced in (per Atlassian's CVE record) | 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 Software Data Center | 7.1.0 | 9.12.40, 10.3.26, 11.3.12 |
| Jira Service Management Data Center | 3.1.0 | 5.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 stated | 4.9.15 |
| Fisheye | not stated | 4.9.15 |
Fixed releases by product; upgrade to the version for your release line or later.
Why it matters
The affected list is Atlassian's whole self-hosted stack: source code, wiki, tickets, builds and identity. (This is a different bug from the earlier MCP Atlassian server flaw.) Atlassian says exploitation needs the exact file name and path and that the bug cannot list directories. That limit removes blind browsing. It does not remove targeting. In our reading, because Atlassian documents where its products keep configuration files, an attacker who knows where a product keeps a sensitive file does not need to enumerate anything. Atlassian itself warns that "in some configurations, there may be sensitive files present that increase your risk." (We covered a similar GitLab arbitrary file read earlier.)
watchTowr Labs, which published its own analysis on 6 October, says the read is confined to the application server's web root (it cannot leave the Tomcat context) but includes the WEB-INF directory, where configuration lives. Its worked example is a Jira instance integrated with Crowd, where a config file holds the Crowd application password in plaintext; the researchers show that credential leading to Crowd administration and then Jira administrator. They note that a Crowd IP allow-list would make that chain harder. That is a researcher scenario, not an observed attack.
On exposure, watchTowr says a quick internet search finds just under 700,000 Confluence instances and estimates the total across products in the "six to seven-figure range." Those are the researchers' claims with no method given, and they count internet-facing instances, not confirmed vulnerable ones. Atlassian's 9.3 is the only published score; watchTowr gives none, though it writes that it sometimes regrets that CVSS stops at 10 for a flaw baked into almost all of a vendor's products.
Technical details
Atlassian describes it as arbitrary file access within the web application root: a request for a specific file path returns that file without authentication. watchTowr examined Bitbucket, Confluence and Jira and concluded the products share the same underlying behaviour. We do not reproduce request details here; see the watchTowr write-up in the sources.
As of 6 October CISA's Vulnrichment record lists SSVC values of exploitation none, automatable no and technical impact partial. Atlassian says it found no evidence of exploitation of its Cloud products and says nothing about Data Center; SecurityWeek reports that watchTowr has seen none in the wild. The CVE is not in CISA's KEV catalogue (checked against catalogue version 2026.10.04), which already lists 13 other Atlassian entries.
What defenders should do
- Patch to the fixed version for your release line (table above). Atlassian recommends the fixed LTS release or later.
- If you cannot patch now, take instances off the public internet. Atlassian says this applies even to instances that require user login.
- Apply one of Atlassian's temporary mitigations: a WAF or proxy regex rule for all products; a Tomcat RewriteValve rule for Confluence, JSM, Jira, Bamboo and Crowd; or a urlrewrite.xml edit for Bitbucket. Atlassian stresses these are interim.
- Hunt in access logs. Atlassian says to URL-decode each request line (up to two passes) and look for two dots adjacent to a slash, backslash or double colon, or to search raw lines with its regex.
- Treat credentials in files under WEB-INF as exposed on any instance that was reachable and unpatched, and rotate them, starting with Crowd application passwords.
- Atlassian cannot confirm whether your instance was affected; involve your security team.
What is still unclear
- Whether Crucible and Fisheye share the introduction points above; Atlassian's CVE record gives none for them.
- Whether anyone is exploiting it. No exploitation is reported as of 7 October (Atlassian's no-evidence statement covers Cloud only), but watchTowr says it built a full proof-of-concept chain and offers a detection tool, and the bug needs no login.
- The real number of exposed, unpatched instances. The 700,000 figure is a researcher claim.
- Who found it. Atlassian lists no credits.
- NVD analysis is still pending.