Yaamlabs
Vulnerabilities

Atlassian CVE-2026-21589: file access across 8 DC products

CVE-2026-21589 (CVSS 9.3) lets anyone with no login read files in the web root of Jira, Confluence, Bitbucket and five more. Fixed versions and mitigations.

By Yaali. October 6, 2026, 6 min read, Vulnerabilities, Patching.

Cover illustration of a server rack with one drawer pulled open and a beam of light reaching inside, with the Yaamlabs logo and the text: One bug reads files across eight Atlassian products, 9.3, CVSS, no login needed

Atlassian published CVE-2026-21589 on October 5, an arbitrary file access flaw rated 9.3 (critical) under CVSS 4.0. An attacker with no account can fetch specific files from the web application root of an affected server. It reaches eight self-managed products at once: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Fisheye and Crucible. Every Data Center version before the fixed releases listed below is affected, going back as far as Bitbucket 4.6.0, Confluence 5.10.0 and Bamboo 7.0.1.

Atlassian Cloud has already been patched and Cloud customers have nothing to do. Atlassian says its investigation found no evidence of exploitation. If you run any of these products on your own servers, and especially if one of them is reachable from the internet, plan the upgrade for this week and put the published mitigation in front of it today.

How CVE-2026-21589 works: an unauthenticated request with a dot-dot path segment reaches the application, which returns a file from the web application root that the attacker named exactly. Below, what limits the attack and what raises the risk

How it works

All eight products are Java web applications. Each ships a web application root: the directory the application server (Tomcat, for most of them) serves static content and application files from. Requests are meant to reach only the resources the application exposes, and the rest of that directory should stay behind the login or not be served at all.

CVE-2026-21589 breaks that boundary. Atlassian describes it as unauthenticated access to "specific files within the web application root directory." There are two important limits. The attacker has to know the exact name and path of the file they want, and the flaw does not let them list or enumerate directories. Atlassian adds that "in some configurations, there may be sensitive files present that increase your risk," but has not named those files.

Atlassian has not published the vulnerable code path either, but its mitigation shows the shape of the request. The firewall rule it supplies blocks .. (the "parent directory" path segment) whenever it sits next to a forward slash, a backslash, a double colon, a semicolon, the end of the URL, or any URL-encoded form of those characters, including double-encoded ones such as %252e. That is a path traversal pattern, and VulDB classifies the flaw the same way. The semicolon matters because Tomcat treats ; as the start of a path parameter, so a segment like /..;/ can look harmless to a front-end proxy and still be resolved as .. by Tomcat. Covering every encoding is the point of the rule: a filter that only blocks a literal ../ will miss %2e%2e%2f.

The CVSS 4.0 vector explains the 9.3. It needs no privileges, no user interaction and no special conditions (AV:N/AC:L/AT:N/PR:N/UI:N). Impact on the vulnerable system is confidentiality only, but impact on subsequent systems is rated high for confidentiality, integrity and availability. In other words, Atlassian expects that what can be read from one of these servers could be used to compromise other systems.

What attackers are doing

Nothing confirmed so far. Atlassian's advisory says it found no evidence of exploitation, and none of the sources we checked on October 6 report attacks, a listing in CISA's Known Exploited Vulnerabilities catalog or a public proof of concept.

The window may be short. Atlassian Data Center flaws have a long record of being exploited soon after disclosure, and the published mitigation regex tells anyone reading it which request pattern to try. The requirement to know an exact file path slows down mass scanning only until someone works out which files are worth requesting on a default install.

What to do

Fixed versions of all eight affected Atlassian Data Center products, followed by four steps: upgrade, apply a WAF or Tomcat rewrite mitigation if you cannot upgrade today, search access logs for traversal attempts, and rotate anything a matched request could have read

1. Upgrade to a fixed release

Pick the fixed release on your current line:

ProductFixed versions
Jira Software Data Center9.12.40, 10.3.26, 11.3.12
Jira Service Management Data Center5.12.40, 10.3.26, 11.3.12
Confluence Data Center9.2.26, 10.2.19
Bitbucket Data Center9.4.26, 10.2.8, 10.5.1
Bamboo Data Center10.2.24, 12.1.12
Crowd Data Center6.3.7, 7.0.3, 7.1.7, 7.2.4
Fisheye and Crucible4.9.15

Upgrade every node in a clustered deployment. Apart from Fisheye and Crucible, Atlassian lists only Data Center releases. Server editions of the other products reached end of support on February 15, 2024 and get no security fixes, so a Jira, Confluence, Bitbucket, Bamboo or Crowd Server install still in use needs to move to Data Center or come off the network.

2. If you cannot upgrade today

Atlassian gives three temporary mitigations. Use one, then upgrade anyway.

  • Web application firewall (WAF) or reverse proxy. Block any request URL that matches the regex in the advisory. It is case-insensitive and catches .. next to /, \, ::, ; or the end of the path, in plain, URL-encoded and double-encoded forms. Copy it from the advisory rather than retyping it, and test that it matches %2e%2e%2f and ..;/ before relying on it.
  • Tomcat RewriteValve, for Jira, Jira Service Management, Confluence, Bamboo and Crowd. Add a RewriteValve element inside the application's Context in server.xml, then create or extend rewrite.config in the application's WEB-INF directory with the deny rules from the advisory. The location of server.xml differs by product. Restart each node for the change to take effect.
  • Bitbucket. Add the advisory's rule to urlrewrite.xml, then restart.

These rules do not change the vulnerable code. A fixed release is the only complete fix.

3. Check whether anyone tried

Atlassian's detection advice is to URL-decode your access logs and search for .. next to path delimiters. Decode at least twice, so that double-encoded requests show up. Check the application server access logs on every node (for Jira and Confluence, the Tomcat access logs under <install-dir>/logs/) and the logs of any load balancer or reverse proxy in front, which often keep a longer history. Pay most attention to requests from unfamiliar addresses that returned HTTP 200 with a non-trivial response size.

4. Clean up after a match

If a traversal request got a 200 response, find out which file it named and assume its contents are known to the attacker. Rotate anything it held: database passwords, API tokens, application links, and service account or directory credentials. Crowd and Bamboo deserve extra attention. Crowd handles single sign-on for the other products, and Bamboo usually stores credentials for build and deployment targets.

The wider lesson

One CVE across eight products suggests a flaw in code they have in common, though Atlassian has not said where it sits. When that happens, the patch list is every Atlassian service you run, including the Fisheye instance nobody has opened in a year. Keep an inventory of every self-managed Atlassian node with its version and whether the internet can reach it, so a bulletin like this one takes minutes to triage.

Our attack surface management work keeps that list of exposed services and versions current, and our web application penetration testing checks whether path traversal and encoding tricks get past your proxy and WAF rules. Open the chat and Yaali, our AI agent, will pass your question to an engineer.


Sources: Atlassian advisory for CVE-2026-21589, Atlassian security advisories, SecurityOnline, Encrypt the Planet, Strix, VulDB.

Read next

Back to the blog, or tell us about your system in the chat. Yaali, our AI agent, answers first and brings in an engineer.