News

Atlassian Data Center’s unauthenticated file reads

Louis Stowasser
Louis Stowasser
Wednesday 7 October 2026
Atlassian Data Center’s unauthenticated file reads
Atlassian Data Center’s unauthenticated file reads

CVE-2026-21589 is an unauthenticated arbitrary-file-access flaw shared across Atlassian’s self-managed Data Center estate: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye. These are the systems organisations use to host Git projects, run CI pipelines, manage tickets and service desks, publish internal knowledge, and centralise identity. They are typically operated by enterprise IT and engineering teams, including large companies and government organisations that need to control the underlying infrastructure or run clustered services.

An internet-reachable installation is the urgent case. The attacker needs no account and no user interaction, but does need the exact name and path of a target file beneath the application’s web root. This is not directory browsing: the flaw cannot list a directory to discover what is there. Still, known filenames, default layouts, deployment conventions and information gained elsewhere can make that constraint much less reassuring, particularly where a web-root file contains configuration or credentials.

A shared route turns encoded paths back into slashes

Atlassian rates CVE-2026-21589 9.3 under CVSS 4.0 and describes the affected surface and fixed releases. Public technical research traced the issue to shared web-resource routing: an application-specific :: representation can be translated back into / before a user-influenced resource name reaches relative-resource resolution.

public static String escapeSlashes(String string) {
	return string.replaceAll("/", "::");
}

public static String unescapeSlashes(String string) {
	return string.replaceAll("::", "/");
}

What matters is the decoding step, not that these two methods alone prove the whole bug. Atlassian has not released a source patch or diff, so the exact corrected validation cannot be confirmed. Researchers reproduced reads in Jira, Confluence and Bitbucket and showed a lab-only Jira-to-Crowd configuration in which retrieving a known crowd.properties file exposed credentials usable against Crowd. That is a configuration-dependent demonstration, not evidence of a customer compromise.

Patch first; isolate exposed instances meanwhile

Maintenance releases are available: Bitbucket 9.4.26, 10.2.8 and 10.5.1; Confluence 9.2.26 and 10.2.19; Jira Software 9.12.40, 10.3.26 and 11.3.12; and Jira Service Management 5.12.40, 10.3.26 and 11.3.12. Bamboo is fixed in 10.2.24 and 12.1.12; Crowd in 6.3.7, 7.0.3, 7.1.7 and 7.2.4; Crucible and Fisheye in 4.9.15.

There is one scope wrinkle worth handling conservatively. The advisory says releases before those fixes are affected, while the CVE record lists introduction points for most products—for example, Bitbucket 4.6.0, Confluence 5.10.0 and Jira Software 7.1.0—and none for Crucible or Fisheye. Treat an unpatched supported deployment as in scope and use Atlassian’s advisory values, rather than stale mirrors.

If upgrading cannot happen immediately, remove the service from direct internet exposure or apply Atlassian’s temporary WAF, Tomcat RewriteValve, or Bitbucket URL-rewrite mitigations. They filter traversal patterns involving slash, backslash and double-colon encoding, but are not replacements for the maintenance release. Review access logs for traversal requests and assess whether web-root configuration files could expose secrets; rotate any credentials where evidence warrants it.

Public code changes the containment clock

As of October 7, Atlassian reported no evidence of in-the-wild exploitation, and no confirmed victim or campaign has surfaced. CVE-2026-21589 was not in CISA’s KEV catalogue at that point, as reflected by current tracking. But public proof-of-concept work exists, including a Jira-to-Crowd chain and a detection-artifact generator; that makes rapid exposure reduction more important even without confirmed attacks.

For teams running these platforms, the practical sequence is simple: identify every externally reachable instance, patch it, validate the mitigation during the change window, and hunt logs. SecAlerts monitors an organisation’s actual software stack and alerts on new vulnerabilities affecting the products it runs, which helps keep this kind of shared-component issue from disappearing into a long application inventory.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203