Introduction On October 5, 2026, Atlassian published an out-of-band advisory for CVE-2026-21589, an arbitrary file access flaw that affects every version of eight self-hosted products: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo and Crowd (all in their Data Center editions), plus Crucible and Fisheye. Atlassian itself rates the flaw critical (CVSS 4.0: 9.3). An attacker with no login can read files inside the web application's root directory. What made this urgent was the speed. One day after the advisory, watchTowr Labs published its technical analysis. A few hours later, threat intelligence firm Previdian reported that exploitation attempts were already hitting its honeypot network. If your company, or a vendor that works for you, runs Jira, Confluence or Bitbucket on its own servers or in its own cloud account (AWS, Azure and so on), this article is for you. We summarize what has been confirmed, which versions fix the problem, what to do if you cannot upgrade today and how to look for signs of attack in your logs. We do not publish exploit code or attack step-by-steps. All information comes from the sources listed at the end. What Atlassian confirmed According to the official advisory: The flaw lets an unauthenticated attacker access specific files within the web application root directory. Exploitation requires knowing the exact name and path of the target file. The flaw does not allow listing directory contents. "In some configurations, there may be sensitive files present that increase your risk," the company says. Affected Atlassian Cloud products have already been patched, and Atlassian's investigation found no evidence of exploitation. Cloud customers do not need to do anything. Atlassian says it cannot confirm whether a customer's instances have been affected and recommends that the security team check every installation. Why "just reading files" earned a 9.3 At first glance, reading files from the application folder sounds less serious than running code. watchTowr's analysis shows why that is not quite true: A shared root cause. All eight products share the same library, atlassian-plugins-webresource. Its path-handling logic made it possible to bypass the path traversal protections. That is why the same flaw shows up in such different products. Reach. In watchTowr's tests against Jira, Confluence and Bitbucket, it was possible to read any file within the application server (without leaving the Tomcat context), including normally protected files in the WEB-INF folder. The Crowd link. When Jira uses Atlassian Crowd (Atlassian's central identity and SSO service), the configuration lives in WEB-INF/classes/crowd.properties. According to watchTowr, that file stores the application name and password in plaintext. With those credentials, an attacker can talk directly to Crowd, list users, create accounts and add them to administrator groups. In watchTowr's lab, this led to Jira administrator access. watchTowr notes that if Crowd only accepts connections from an allowlist of IP addresses, this scenario becomes much harder. The firm built a full proof of concept but did not publish it. It released only a tool that checks whether a Jira, Confluence or Bitbucket instance is vulnerable. The scale is also a concern. According to watchTowr, an internet search shows just under 700,000 instances of Confluence alone. Timeline October 5: Atlassian publishes the advisory and the fixed versions. October 6: watchTowr publishes its technical analysis. Hours later, Previdian reports exploitation attempts on its honeypots, according to Help Net Security. October 7: VulnCheck adds CVE-2026-21589 to its own known exploited vulnerabilities (KEV) list after observing activity against Bamboo Data Center, according to Infosecurity Magazine. October 12 (today): the flaw is still not in CISA's KEV catalog. We checked catalog version 2026.10.08. One important point: public reports describe exploitation attempts seen on honeypots. We found no public report of confirmed victims. That is not a reason to wait. Instances exposed to the internet should be treated as targets. Fixed versions Atlassian recommends upgrading each installation to one of the versions below, or to the latest version. All earlier versions are affected. Product Fixed versions 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 Confluence Data Center 9.2.26 / 10.2.19 Bitbucket Data Center 9.4.26 / 10.2.8 / 10.5.1 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 Atlassian recommends moving to the fixed LTS version or later. The company's current policy is to ship new maintenance releases instead of binary patches. If you cannot upgrade today Atlassian lists temporary measures. The first and simplest is to take the instance off the internet until you apply the fix or a mitigation. That also applies to instances that require a login, because the flaw does not need authentication. If the instance has to stay reachable, there are three official options: A WAF or reverse proxy rule (all products): block URLs matching the regular expression published by Atlassian, which stops .. immediately next to /, \ or ::, including URL-encoded forms. After applying it, test that the block works. Tomcat's RewriteValve (Confluence, Jira, JSM, Bamboo and Crowd): a rule in rewrite.config, applied node by node across the cluster, with a backup first. A rule in urlrewrite.xml (Bitbucket only): applied on all nodes, mirrors and mirror farms. Use the exact text of Atlassian's advisory to configure these rules and do not copy third-party versions. Remember that a mitigation is a bridge, not a fix. The goal is still to upgrade. How to check for attack attempts Atlassian advises looking for evidence in the access logs: URL-decode each request line (up to two decoding passes) and look for .. immediately next to /, \ or ::; or search the raw, non-decoded lines with the same regular expression from the advisory. In practice, this is what we recommend to our clients: Take inventory. List every Data Center, Crucible and Fisheye instance, including test instances and those a vendor runs for you. Review logs since October 5, and preferably earlier. If your logs rotate quickly, copy them to a central location now. If you use Crowd, rotate the application passwords configured in crowd.properties and similar integrations, especially if you find suspicious requests. Review recently created or modified users and administrator groups. Restrict Crowd to an allowlist of IP addresses, as watchTowr itself suggests. Check for other secrets that may sit in configuration files inside the application folder. If you find signs of compromise, preserve the logs before touching the server and call your team or an incident response partner. Conclusion CVE-2026-21589 combines three factors that tend to end badly: it needs no login, it hits every version of widely used products and it drew exploitation attempts within hours of the technical analysis going public. Atlassian Cloud users do not need to act. Anyone running Jira, Confluence, Bitbucket, Bamboo or Crowd on their own servers should upgrade now, or at least take the instance off the internet and apply the official mitigation, then review the logs and the Crowd credentials. We will update this article if CISA adds the flaw to KEV or if Atlassian releases new facts. Sources Atlassian: CVE-2026-21589 - Arbitrary File Access Vulnerability impacts Multiple Products (official advisory, Oct 5, 2026) watchTowr Labs: Atlassian Jira, Confluence (and more) Pre-Auth Arbitrary File Read CVE-2026-21589 (technical analysis, Oct 6, 2026) Help Net Security: Exploitation attempts against critical Atlassian flaw have begun (CVE-2026-21589) Infosecurity Magazine: Critical Flaw in Multiple Atlassian Products Exploited in the Wild CISA: Known Exploited Vulnerabilities Catalog (version 2026.10.08 checked on Oct 12, 2026) Originally published on KGA IT.
Atlassian CVE-2026-21589: critical no-login flaw in Jira, Confluence and Bitbucket Data Center already draws exploitation attempts
Full Article
Original Source
Read the full article at Dev →KhanList aggregates and links to publicly available news content. We do not host full articles from third-party sources. Always verify important information with original sources.