CVE-2026-21589 in Atlassian Data Center: risk analysis and urgent response steps

The critical vulnerability CVE-2026-21589 (CVSS 9.3) in Atlassian Data Center products is already being actively probed by attackers: according to telemetry, at least 15 exploitation attempts were recorded just two hours after the publication of technical details, making immediate patching and isolation of vulnerable instances from the internet a top priority for all organizations using on-premises deployments of Jira, Confluence, Bitbucket, Bamboo, Crowd, and other Atlassian systems.

Technical details of CVE-2026-21589

The CVE-2026-21589 vulnerability is classified as unauthenticated arbitrary file access within the web application root directory (webroot). The formal description and basic information can be found in the NVD database using the CVE template: the CVE-2026-21589 record in NVD.

The following Atlassian products (Data Center editions and related server solutions) are affected:

• Bitbucket Data Center — fixed versions: 9.4.26, 10.2.8, 10.5.1
• Confluence Data Center — 9.2.26, 10.2.19
• Jira Service Management Data Center — 5.12.40, 10.3.26, 11.3.12
• Jira Software Data Center — 9.12.40, 10.3.26, 11.3.12
• Bamboo Data Center — 10.2.24, 12.1.12
• Crowd Data Center — 6.3.7, 7.0.3, 7.1.7, 7.2.4
• Crucible — 4.9.15
• Fisheye — 4.9.15

According to the vendor, Atlassian Cloud products have already been updated.

The key to exploitation lies in Atlassian’s web resource handling mechanism. Researchers from watchTowr have shown that the path resolution logic converts strings like \\\"..::..::..::..::WEB-INF::web.xml\\\" into a standard relative path \\\"../../../../WEB-INF/web.xml\\\". A detailed technical breakdown is available in their publication: analysis of CVE-2026-21589 by watchTowr.

This behavior is then combined with the jQuery colorpicker plugin resource located at /includes/jquery/plugins/colorpicker/images/. Thanks to the trailing “/” character, an attacker can “break out” of the images directory and access other files in the application using a single HTTP request. Example request for Jira:

GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: <Jira-Hostname>

Limitation of the vulnerability: the attacker must know the exact file name and its path; the vulnerability does not allow directory listing. Nevertheless, in a typical configuration, configuration files with credentials and keys reside within the webroot, which significantly increases the level of risk.

The scenario is particularly critical for Crowd and Jira: the file WEB-INF/classes/crowd.properties containing Crowd credentials is accessible. The researchers show that once an attacker obtains these credentials, they can achieve administrative access to the application, create new accounts, and escalate privileges up to Jira Administrator. Supporting material and examples are available in the watchTowr repository: watchTowr vs Atlassian CVE-2026-21589.

Early exploitation signs and IOCs

Previdian, a company specializing in proactive vulnerability assessment, recorded the start of attacks against its honeypot systems two hours after the publication of watchTowr’s technical exploit details. According to their telemetry, 15 exploitation attempts were registered from three unique IP addresses in Japan and the USA. Details are available in their review: telemetry on CVE-2026-21589 from Previdian.

Identified indicators of compromise (IOCs):

• 38.60.157[.]86
• 146.70.187[.]234
• 159.26.119[.]225

These are early signs of reconnaissance and testing traffic. Importantly, the main trigger for the wave of scanning was the public disclosure of technical details and the availability of ready-made templates for automated scanning tools (Nuclei). After the corresponding template is published, as Previdian warns, mass scanning of external perimeters for this vulnerability will become a trivial task even for low-skilled attackers.

Impact assessment and risk profile

The highest risk is for organizations that:

• expose Jira, Confluence, Bitbucket, Bamboo, Crowd, and other Atlassian Data Center instances directly to the internet;
• use Crowd as a central authentication point for other applications;
• store configuration files with passwords, API keys, and access tokens within the webroot (including files like web.xml, crowd.properties, and similar).

Potential consequences of successful exploitation:

• Credential compromise — extraction of passwords, tokens, and encryption keys from configuration files.
• Privilege escalation — moving from unauthenticated access to Atlassian application administrator rights through stolen Crowd data.
• Deep interference with business processes — creating hidden administrative accounts, changing user permissions, manipulating issue queues, code repositories, and build pipelines.
• Chained compromise — using obtained credentials to access other systems integrated with Atlassian (CI/CD, service desk, authentication systems).

In terms of industries, the situation is especially sensitive for companies where Jira and Confluence are critical elements of operations: IT providers, software developers, financial organizations, telecoms, and large industrial enterprises. For them, loss of integrity or confidentiality of data in the Atlassian environment directly impacts operational resilience and regulatory compliance.

Practical protection recommendations

1. Prioritization and patch installation

The recommended priority is to immediately update all affected instances to versions that include the fix:

• Bitbucket Data Center: 9.4.26, 10.2.8, 10.5.1;
• Confluence Data Center: 9.2.26, 10.2.19;
• Jira Service Management Data Center: 5.12.40, 10.3.26, 11.3.12;
• Jira Software Data Center: 9.12.40, 10.3.26, 11.3.12;
• Bamboo Data Center: 10.2.24, 12.1.12;
• Crowd Data Center: 6.3.7, 7.0.3, 7.1.7, 7.2.4;
• Crucible and Fisheye: 4.9.15.

It makes sense to sequence updates starting with publicly accessible instances and systems where Atlassian is tied to access management (Crowd) and development (Jira, Bitbucket, Bamboo).

2. Temporary measures if immediate patching is impossible

Until patches can be installed, it is advisable to implement all recommended temporary measures:

• Remove the instance from direct internet access — place it behind a VPN or proxy, or restrict access using IP allowlists.
• Configure Web Application Firewall rules to block suspicious requests to /download/resources/…/images/ resources containing ..:: sequences and attempts to access WEB-INF.
• Use Tomcat RewriteValve (for Confluence, Jira, Jira Service Management, Bamboo, Crowd) to forcefully reject such URL patterns.
• For Bitbucket — add an appropriate rule to urlrewrite.xml blocking traversal from image paths to system directories.

Even after installing patches, it makes sense to keep some of these filters as an additional protection layer against potential future bypasses.

3. Detecting possible exploitation

Recommended steps to check for any past attack attempts:

• Analyze web server and reverse proxy access logs for requests containing:
  • ..::..:: sequences in the URL;
  • access to paths like /download/resources/*color-picker-popup/images/;
  • mentions of WEB-INF/web.xml, crowd.properties, and other sensitive files.
• Check logs for access from the IP addresses:
  • 38.60.157[.]86
  • 146.70.187[.]234
  • 159.26.119[.]225

  followed by correlation by time and request context.

• Reevaluate authentication logs in Jira and Crowd: look for the appearance of new administrator accounts and changes in permissions of existing users in the period after the exploit was published.

4. Limiting the impact of configuration file compromise

Even if there are no clear signs of exploitation, you should proceed from the assumption that configuration files might have been read while the vulnerability window was open. The practical minimum:

• change passwords and keys that may have been stored in web.xml, crowd.properties, and similar files;
• revoke and reissue tokens used by integrations with external systems (CI/CD, code repositories, authentication systems);
• check for anomalous activity in integrated systems that could have been accessed using compromised credentials.

The key action for the next 24–48 hours is to update all vulnerable Atlassian Data Center instances to fixed versions, temporarily limit their internet exposure, and then deliberately analyze logs for characteristic requests containing ..:: and access to WEB-INF, followed by rotating all credentials that may have been accessible through configuration files.