CVE-2026-21589 is a critical vulnerability (CVSS 9.3) in eight Atlassian Data Center products that allows a remote unauthenticated attacker to read files in the web application root whose paths are already known to them. It affects both supported and some legacy versions, including Server editions. Atlassian has already updated its cloud services, and owners of on‑premises installations are advised to update immediately or temporarily isolate and protect the systems using WAF rules and the URL rewrite configurations provided for the product.
Technical details of CVE-2026-21589
Atlassian describes the issue as a path traversal vulnerability: a specially crafted request with a sequence like .. next to the characters /, \\ or :: makes it possible to access files located in the deployment directory of the web application. In this case:
- the attack is possible fully remotely, over the network;
- no authentication is required;
- the attacker must know the exact path and filename in advance;
- listing directory contents via this vulnerability is not possible.
The official description and recommendations are published in the Atlassian advisory: CVE-2026-21589: arbitrary file access vulnerability impacts multiple products. The CVE is also registered in the CVE Project database: CVE-2026-21589 entry and in NVD under the standard link NVD: CVE-2026-21589.
According to Atlassian, all versions prior to the fixed ones (listed in the tickets and advisory) of the following Data Center products are affected:
- Bitbucket Data Center — see ticket BSERV-20604;
- Confluence Data Center — ticket CONFSERVER-104488;
- Jira Software Data Center — ticket JRASERVER-79546;
- Jira Service Management Data Center — ticket JSDSERVER-16809;
- Bamboo Data Center — ticket BAM-26567;
- Crowd Data Center — ticket CWD-6610;
- Crucible — ticket CRUC-8741;
- Fisheye — ticket FE-7583.
Atlassian cloud versions have already been updated; Bitbucket Cloud is not affected by the vulnerability. Cloud customers do not need to take any action; all attention should be focused on on‑premises deployments.
Problem areas with versions and Server editions
There is confusion between the advisory and the CVE records regarding the ranges of affected and fixed versions:
- for Crowd, ticket CWD-6610 has one field that lists the fixed version in the 7.1 branch as 7.1.7, while the table in the same ticket simultaneously shows 7.1.6 as both fixed and vulnerable;
- in the CVE JSON record for Crowd, version 7.1.1 is specified as a boundary, although according to the Crowd 7.1 release notes this release dates back to November 2025, i.e. long before the vulnerability was publicly disclosed;
- for Bamboo, the CVE record contains two variant numbers: 10.2.4 and 10.2.24, which makes it difficult to unambiguously determine the safe version.
A separate problem is the status of Server editions. In the CVE record, Atlassian marks all versions of Bamboo Server, Bitbucket Server, Confluence Server and Crowd Server as vulnerable, without listing a single fixed version for them. For Jira Software Server, Jira Service Management Server, Crucible Server and Fisheye Server, versions are specified from which the products are considered not vulnerable (for example, Jira Software Server from 9.12.40), but it is not explained whether running these versions is permissible under Server licensing terms.
Additionally, according to the general Crowd release notes, the last Server version of Crowd is 5.2 (September 2023), meaning none of the listed fixed Crowd versions belong to the Server line. For owners of such installations this effectively means the absence of a patch and the need for compensating controls.
According to CVSS v4, the vulnerability is rated 9.3: the vector is network, no privileges and no user interaction required; the impact on the confidentiality of the vulnerable system itself is high, while the impact on integrity and availability is none. At the same time, the impact on other systems is also rated as high. The latter indirectly reflects the risk that reading files in the web application root may lead to compromise of credentials, tokens or configurations related to other systems.
Threat context: the CVE-2021-26086 precedent
Path traversal in Atlassian products has already been exploited before. The CVE-2021-26086 vulnerability in Jira Server and Data Center allowed remote attackers to read individual files and was later added to CISA’s Known Exploited Vulnerabilities catalog. Details are available in the record NVD: CVE-2021-26086.
This precedent matters for two reasons:
- it confirms attackers’ real interest in leaking files from Atlassian platforms, which often store development artifacts, integration keys and infrastructure documentation;
- it shows that even “limited” reading of individual files can be serious enough to be placed on top-priority vulnerability lists at the level of government regulators.
In the current advisory, Atlassian states that it has not found evidence of CVE-2026-21589 exploitation in the cloud environment and cannot confirm whether specific on‑premises installations have been compromised. The absence of information about actual attacks does not reduce the risk, given the critical CVSS score and the history of similar issues that have already been exploited.
Impact assessment for organizations
The full range of organizations is at risk if they:
- run Atlassian Data Center or have not yet migrated from Server to modern editions;
- make these instances accessible from the internet (including scenarios with mandatory authentication);
- use Atlassian as a central element of the development and operations chain (task management, repositories, CI/CD, access management).
Although the vulnerability is formally limited to reading files within the web application root, in practice such directories often contain:
- configuration files with connection parameters for databases and external services;
- scripts and templates whose content can be used to reconstruct the system structure or authentication mechanisms;
- logs and temporary files containing fragments of requests, tokens and internal paths.
A combination of such data can lead to:
- escalation from file reading to takeover of the database, an integration account or another service;
- leakage of source code, internal documentation and other intellectual property through a chain of dependencies (for example, when accessing Bitbucket or Bamboo);
- strengthening of supply chain attacks if, via a vulnerable Atlassian instance, an attacker gains insight into the build and release process.
Uncertainty about the boundaries of safe versions and the status of Server editions creates additional operational risk: administrators find it harder to quickly answer the question “is this particular installation vulnerable?”, which in turn makes it harder to prioritize actions and communicate risk to the business.
Practical recommendations for risk reduction
1. Updates as the top‑priority scenario
- Rely on the official Atlassian advisory: advisory for CVE-2026-21589 and the related product tickets (BSERV-20604, CONFSERVER-104488, etc.).
- For each product, determine the current version and compare it with the “Fixed in” entry in the corresponding ticket.
- The preferred option is to update to the specified fixed LTS version or a newer one, if it is also marked as containing the fix.
- For legacy Server editions for which no patches exist, consider an accelerated migration to Data Center or cloud, or moving such instances into a strictly controlled, isolated environment.
2. Network access restrictions
- If an immediate update is not possible, Atlassian recommends, where possible, temporarily disconnecting the instance from external networks.
- For critical systems that cannot be shut down, restrict access to internal networks and VPN only, eliminating direct internet exposure.
- Apply on the WAF or reverse proxy a rule that blocks requests where, after up to two rounds of URL decoding, a
..sequence appears directly next to/,\\or::. Atlassian provides a specific expression in the advisory.
3. Temporary application‑level rules
Atlassian suggests additional mitigations at the application level (they do not replace updating):
- for Confluence, Jira Software, Jira Service Management, Bamboo, Crowd — use Tomcat RewriteValve with a rule that blocks the URL patterns described above; enabling it requires changing the configuration on each node and restarting the service;
- for Bitbucket — add a rule to
urlrewrite.xmlon each node and mirror, also followed by a restart; - for Crucible and Fisheye, only external measures (WAF/reverse proxy) are available.
These measures reduce the likelihood of successful exploitation but do not eliminate the vulnerability itself. After installing the patch, they should be kept as an additional protection layer.
4. Log analysis for signs of possible exploitation
Atlassian explicitly states that it cannot verify whether specific instances have been attacked and suggests that administrators check the logs themselves.
- Export the web server access logs and/or the product’s built‑in logs for the period of interest.
- Normalize requests: perform URL decoding up to two times to detect bypass attempts via double encoding.
- Search for occurrences of
..directly adjacent to/,\\or::, or apply the same regular expression used in Atlassian’s blocking rule.
The advisory does not provide criteria to distinguish unsuccessful attempts from successful ones. In practical terms, it is also useful to analyze:
- server response codes (series of 200/206 responses to unusual paths are suspicious);
- response sizes and anomalies compared with typical static resources;
- correlation with subsequent activity from the same IP (authentication, configuration changes, artifact downloads).
If suspicious requests are found, it makes sense to plan a deeper investigation: an inventory of which files could theoretically have been read, a review of credentials and keys, and potentially forced rotation of secrets.
5. Prioritizing response
Given the unauthenticated nature of the vulnerability, the high impact on confidentiality and the potential impact on other systems, it is advisable to:
- assign the highest priority for updating and implementing mitigations to all Atlassian instances accessible from the internet;
- pay particular attention to installations that support development and build processes and store sensitive artifacts (repositories, build artifacts, access configurations);
- eliminate uncertainty around versions as quickly as possible: cross‑check tickets, the advisory and, if necessary, Atlassian support for “gray” versions like the mentioned Crowd and Bamboo variants.
The main practical conclusion: CVE-2026-21589 should be viewed not as a local defect of a single product, but as a critical risk of configuration and data leakage in a key part of the development infrastructure. Organizations should immediately inventory all on‑premises Atlassian instances, update them to safe versions or isolate them, enable the recommended filters at the WAF and application levels, and conduct a targeted review of logs for suspicious requests with path traversal patterns.