Atlassian CVE-2026-21589: active attacks and unauthenticated file access

CISA has added CVE-2026-21589 to its Known Exploited Vulnerabilities catalogue, indicating evidence of real-world exploitation. The flaw enables an unauthenticated attacker to retrieve specific files from the web application root in several self-managed Atlassian products. Atlassian rates it critical at 9.3 under CVSS 4.0.

The technical basis for this analysis is Atlassian’s 5 October advisory. CISA added the vulnerability to KEV on 15 October and set an 18 October action deadline for US federal agencies. That deadline is not a legal obligation for organisations elsewhere, but its short window is a useful signal of operational urgency.

Breachroad’s conclusion: do not close the task after installing an update. If an instance was reachable from the internet, investigate its logs and establish which data or secrets may have been stored in application files. The update closes the vulnerability but cannot revoke information retrieved earlier.

Which products are affected

The advisory covers every release earlier than the fixed versions for:

• Bitbucket Data Center;
• Confluence Data Center;
• Jira Service Management Data Center;
• Jira Software Data Center;
• Bamboo Data Center;
• Crowd Data Center;
• Crucible and Fisheye.

An attacker needs the exact name and path of the target file. The flaw does not provide a directory listing. That is not a sufficient defence: common file names, standard installation layouts and information gathered elsewhere may help an attacker identify a target. Risk also depends on which files are present in the application directory and what they contain.

Atlassian says affected Cloud services have been patched and that its investigation found no evidence of exploitation there. Cloud customers do not need to perform the self-managed remediation steps. Establish the service model first—the Jira or Confluence name alone does not say whether your organisation, a partner or Atlassian owns the update.

Releases to install

Atlassian recommends the latest release or at least the applicable fixed version:

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

Choose a release within the correct supported product branch. Do not compare version numbers across branches or assume that any numerically higher release in another line is an appropriate migration target. Check every cluster node and, for Bitbucket, mirrors and mirror-farm nodes as well.

Where an immediate update is impossible, the vendor recommends removing the instance from the internet. It also provides a WAF or reverse-proxy rule that filters traversal variants, plus separate mitigations for Tomcat and Bitbucket. These are temporary controls: copy the current instructions directly from the advisory, test them and deploy them to every node. They do not replace the update.

How to look for exploitation

Atlassian advises reviewing access logs for every affected instance. Decode each request line up to twice, then search for .. directly adjacent to /, \ or ::. Alternatively, search raw log lines with the regular expression in the vendor’s advisory.

A match may represent an attempt rather than a successful file read. Conversely, no match does not always close the investigation: retention may be too short, logging may have missed some traffic, or another route to the instance may exist. Correlate application, reverse-proxy, WAF, load-balancer and network records. Record the time range, data completeness and every telemetry gap.

Determine whether a request received a response, the volume transferred and whether the same pattern reached several products. Avoid publishing or automatically blocking source addresses as the sole indicator, however; attacker infrastructure can be shared or replaced quickly.

What to do if a file may have been retrieved

Preserve evidence first and establish the potential scope. Identify the files present at the requested paths at the time of the event. Assess whether they held passwords, tokens, private keys, connection data, SSO configuration, database details or other information that could enable the next stage of an attack.

Then revoke and replace exposed secrets according to their reach. Restarting an application does not change a stolen token. Review activity in the accounts and services those values could unlock, including unusual logins and changes after the probable access time. If a file contained personal data or confidential customer information, involve the business owner, legal counsel and the team responsible for notification obligations.

These are Breachroad recommendations derived from the potential impact of arbitrary file access. Atlassian’s advisory establishes the products, vulnerability behaviour, fixed versions and request-search method; it cannot determine which file was retrieved in a particular organisation.

A plan for the first few hours

1. Identify every self-managed instance, cluster, mirror and internet exposure.
2. Preserve logs, configuration snapshots and a timeline before making changes.
3. Restrict public access if the update cannot be installed immediately.
4. Update to the applicable release and verify every node.
5. Search decoded and raw logs using the vendor’s instructions.
6. For suspicious reads, identify the file, rotate secrets and widen the investigation.
7. Document the result, including what was checked, the evidence used and its limitations.

Organisations should have this sequence ready before the next KEV entry appears. A mature vulnerability management process combined with an incident response plan makes that possible. IT, security and service owners can rehearse the joint decisions in our cybersecurity training for organisations.