Atlassian has disclosed a critical path traversal vulnerability affecting eight of its self-hosted Data Center products, including Jira, Confluence and Bitbucket. Tracked as CVE-2026-21589 with a CVSS score of 9.3, the flaw can allow an unauthenticated party to read certain files from the web application root directory.
Atlassian’s cloud-hosted products have already been fixed. Organizations running their own Data Center instances need to update them.
About the vulnerability
According to Atlassian, the issue does not allow directory listing, and in some configurations the web application root may contain sensitive data, which raises the risk. The vendor also says it cannot confirm whether any customer instance has been affected, so each organization has to make that assessment itself.
Affected products and fixed versions
- Bitbucket Data Center: 9.4.26, 10.2.8, 10.5.1
- Confluence Data Center: 9.2.26, 10.2.19
- Jira Software Data Center: 9.12.40, 10.3.26, 11.3.12
- Jira Service Management Data Center: 5.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
What Atlassian recommends
The primary fix is to upgrade to one of the versions above. If that cannot be done immediately, Atlassian advises taking the instance offline where possible. Any instance reachable from the public internet should be cut off from outside access until it is patched or temporary blocking rules are in place.
Atlassian describes three temporary mitigation options:
- All products: blocking rules on a web application firewall or reverse proxy in front of the instance.
- Confluence, Jira Software, Jira Service Management, Bamboo and Crowd: a Tomcat RewriteValve rule, which requires the application to be stopped and restarted.
- Bitbucket: rules in urlrewrite.xml applied to every node and mirror, followed by a restart.
Crucible and Fisheye support only the first option. The exact rule definitions are in Atlassian’s security advisory, and they should be copied from there rather than written by hand. Atlassian stresses that these mitigations are limited and are not a replacement for patching.
Checking logs
For organizations reviewing access logs, Atlassian provides guidance on how to decode and search request lines for traversal attempts. Note that the advisory does not explain how to tell failed attempts from successful file reads. If you find matching requests, treat the instance as potentially exposed and review what files were reachable.
This has happened before
A similar path traversal flaw, CVE-2021-26086, affected Jira Server and Data Center. CISA added it to its Known Exploited Vulnerabilities catalog on November 12, 2024, years after it was disclosed. Old Atlassian bugs stay useful to attackers for a long time because self-hosted instances are often left on outdated versions. There is no reason to expect CVE-2026-21589 to be any different.
Our recommendations
Beyond the vendor’s guidance, the SiteGuarding team recommends the following for every self-hosted Atlassian instance:
- Patch first, then verify. After upgrading, confirm the running version on every node, including Bitbucket mirrors and secondary Data Center nodes, which are easy to miss.
- Take Atlassian off the open internet. Jira, Confluence and Bitbucket rarely need to be publicly reachable. Placing them behind a VPN, a zero-trust access gateway or at least an IP allow list removes most of the exposure from this and future flaws. Our server management service covers exactly this kind of exposure review and hardening.
- Know what lives in the web root. Review the web application root directory for configuration files, backups, exports or other data that should not be there, and move them out.
- Rotate secrets if in doubt. If your logs show suspicious requests, or if you cannot rule out exposure, rotate database credentials, API tokens, application links and integration secrets used by the instance.
- Keep logs long enough to matter. Exploitation of Atlassian flaws is often discovered weeks or months later. Retain and centralize web server and application logs so you can answer the question “were we hit?” when it comes up.
If your logs already show signs of traversal attempts that succeeded, our emergency hacked website repair team can investigate and clean up the same day. If you just want the instance verified and hardened before that becomes necessary, our penetration testing service can confirm whether this exposure, or others like it, actually holds up under real attack conditions.