What is CVE-2026-21589?
CVE-2026-21589 is an arbitrary file access flaw affecting most of Atlassian’s self-hosted Data Center product line. CISA classifies it as CWE-552, files or directories accessible to external parties. An unauthenticated remote attacker can read specific files inside the web application root directory.
The vulnerability carries a CVSS v4.0 base score of 9.3 (Critical). Attack vector is network, attack complexity is low, and neither privileges nor user interaction are required.
The score is driven by what the stolen files lead to rather than by the read itself. Atlassian rates confidentiality impact on the vulnerable system as high and integrity and availability as none, but rates confidentiality, integrity, and availability on subsequent systems as high across the board. That is the signature of a credential disclosure flaw. Reading a configuration file is harmless until that file contains a database password, a service account token, or a signing key, at which point the consequence moves to whatever those credentials unlock.
One constraint narrows exploitation meaningfully, and Atlassian states it twice. The attacker must already know the exact name and path of the file they want. The flaw provides no way to enumerate or list directory contents. In practice that limits attackers to files whose locations are predictable from the product itself, which for a widely deployed commercial application still means configuration files, property files, and anything an administrator placed in a default location.
CISA’s vulnrichment entry records exploitation as none observed, automatable as no, and technical impact as partial. Atlassian published the advisory on October 5, 2026.
What assets are affected by CVE-2026-21589?
The affected list covers nearly the whole Data Center range. Jira Software from 7.1.0, Jira Service Management from 3.1.0, Confluence from 5.10.0, Bitbucket from 4.6.0, Crowd from 2.11.0, Bamboo from 7.0.1, plus Crucible and Fisheye. The introduced-in versions reach back years, so a long-running deployment is affected unless it has been patched.
Fix versions are numerous because each product carries several supported branches. Jira Software and Jira Service Management are fixed in 9.12.40, 10.3.26, and 11.3.12, with Jira Service Management’s long-term branch at 5.12.40. Confluence is fixed in 9.2.26 and 10.2.19. Bitbucket is fixed in 9.4.26, 10.2.8, and 10.5.1. Crowd is fixed in 6.3.7, 7.0.3, 7.1.7, and 7.2.4. Bamboo is fixed in 10.2.24 and 12.1.12. Crucible and Fisheye are both fixed in 4.9.15. The correct target depends on which branch an instance is on, not on the newest number available.
The edition boundary is the critical scoping question. This is a Data Center vulnerability. Atlassian Cloud instances are operated by the vendor and are not in scope for customer action.
In practice an affected asset is a self-hosted Atlassian application reachable from the internet, which for most organizations means a Jira or Confluence instance exposed so that contractors, partners, or remote staff can use it without a VPN. These are not edge devices or marketing sites. They are the systems that hold project history, architecture documentation, runbooks, and in too many cases credentials pasted into a ticket years ago, which is what makes a read-only flaw worth this score.
Externally, a service fingerprint identifies the product family but not the edition and often not the version. Determining whether a given instance is Data Center, and on which branch, requires checking it.
What does our data show about exposure patterns?
Exposure in this set is led by Consumer Discretionary at 22.0% of observed assets, with Information Technology and Industrials tied at 14.3% each. The remaining sectors together account for 49.3%.
No sector dominates, and neither does any single organization. The largest estate in this set holds well under a tenth of the observed assets, and the remainder is spread broadly rather than pooled in a few places. That makes the sector distribution closer to a genuine signal than the usual pattern, where one large deployment sets the shape of the entire chart.
The flatness is the expected result for developer and collaboration tooling. Jira and Confluence are not tied to any industry’s operations. They are where engineering and project work happens in organizations of a certain size, so the footprint tracks organizational scale rather than sector.
Two details in this set matter more than the sector split. Roughly a quarter of the observed assets carry a high-confidence detection rather than a bare fingerprint, and a similar share carry an explicit version string, which is a stronger evidentiary base than most exposure sets of this kind provide.
Working against that, the product fingerprints rarely state the edition. Most resolve to the generic product name rather than to a Data Center identifier, and since this flaw is Data Center only, the fingerprint population necessarily includes instances that are not in scope at all. Jira and Confluence account for the overwhelming majority of what was observed, with Bitbucket, Bamboo, and Jira Service Management appearing in small numbers.
The practical consequence is that this is an inventory problem before it is a patching problem. An organization cannot act on a list of internet-facing Atlassian hostnames without first establishing, per instance, which product it is, which edition, and which branch. That is work only the asset owner can do, and in estates where instances were stood up by individual teams it is frequently nobody’s standing responsibility.
Are fixes available?
Yes. Atlassian shipped fixes for every affected product on October 5, 2026, and the advisory lists a patched version for each supported branch.
The branch structure is the main source of friction. An organization running several Atlassian products, which is the common case, has to map each instance to its branch and then to the right fix version rather than applying a single uniform upgrade. The long-term support branches carry their own patched versions, so instances deliberately held on an older line do have a fix available and do not need a major upgrade.
Instances on versions below the introduced-in thresholds are not affected by this specific issue, but those releases are long past end of support and carry their own accumulated exposure. Treating that as a reason not to act would be a mistake.
Because the impact is credential disclosure rather than direct compromise, patching alone may not close out the exposure. An instance that was internet-facing before the fix should be treated as potentially having leaked whatever predictable-path files it held, which makes rotating credentials stored in or near those files the companion action to the upgrade.
Are there any other recommended actions to take?
Until patching is confirmed, defenders should:
- Inventory every internet-facing Atlassian instance across all products
- Establish the edition and branch for each instance before planning upgrades
- Rotate credentials held in configuration files on previously exposed instances
- Remove secrets from Atlassian configuration and move them to a managed store
- Restrict instance access to VPN or identity-aware proxy where full exposure is unnecessary
- Review web server logs for repeated requests to configuration and property file paths
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for CVE-2026-21589 in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
