Atlassian flaw CVE-2026-21589: An unauthenticated file read that turns you into a Jira administrator

Atlassian published an advisory for eight on-prem products on 5 October 2026, outside its regular security bulletins. CVE-2026-21589 lets a request read files out of the directory of the web application without that request having logged in anywhere. Atlassian scores the severity at 9.3 under CVSS 4.0 and delivers fixed versions for every affected line. The next day watchTowr Labs laid the mechanics open, described an attack path up to the administrator role in Jira, and released a checking tool for your own estate.

What the flaw actually does

Files inside the application root directory of the instance are what can be read. Neither an access nor an account nor a token is needed for that; the request runs over routes that serve web resources and that build on the same shared code in all the products named. Atlassian adds a caveat in the advisory: the attacker has to know the name and the path of the target file, browsing a directory is not possible through the vulnerability. That takes little away from the report, because the interesting files carry the same name in every installation. The proof from watchTowr reads the WEB-INF/web.xml of a Jira instance, a file Tomcat normally shields from a direct request.

According to the advisory, every version before the fix releases of Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible and Fisheye is affected. The advisory names the fixed levels at full length; for the German operations-handbook extract the LTS lines are enough: Bitbucket from 9.4.26, Confluence from 9.2.26, Jira and Jira Service Management from 9.12.40 and 5.12.40 respectively, Bamboo from 10.2.24, Crowd from 6.3.7, Crucible and Fisheye from 4.9.15. Anyone who moves up to the currently maintained line is on the safe side, because every earlier version is affected by explicit statement.

The mechanism: two colons make the slash

watchTowr compared the atlassian-plugins-webresource jar files of the unpatched and the patched levels and came across a pair of functions in the Router class that swaps two colons for plain slashes inside path segments. The web resource routes use this escaping so that a resource name in the URL is not read as a path. The filters in front of the application do not know colons as separators, the application behind them does exactly that. After unescaping, ..::..::..::..::WEB-INF::web.xml becomes a sequence of dot-dot segments, and a traversal that every normal check would have expected for a slash or a backslash. The entry leads through inconspicuous download routes of the bundled plugins, in Jira through the image collection of the colour picker plugin. watchTowr documents the finished URIs for Jira, Confluence and Bitbucket and notes that the path cannot be continued beyond the Tomcat context boundary: what is readable is the application scope, the whole disk stays out of reach.

From the read file to a Jira administrator

The advisory itself describes the effect in one sentence an operator should take literally: "In some configurations, there may be sensitive files present that increase your risk." watchTowr shows which configurations are meant. Anyone who hangs their Atlassian products onto a central single sign-on through Atlassian Crowd stores the application data in the file crowd.properties in the folder WEB-INF/classes, and there the application name and the application password sit in plain text. This file is one of the files whose names an attacker has to know, and the public analysis names the path.

Chain as described by the research from watchTowr Labs on 6 October 2026. The first three steps run against every vulnerable instance, the last two only where Crowd is set up as SSO. The authors point out that a Crowd instance with an IP allowlist makes the final step considerably harder. (Quelle: watchTowr Labs, CVE-2026-21589)

With a name and a password, the Crowd REST interface can be addressed as an authorised application. The documented proof-of-concept chain reads the user list, creates a user of its own and adds that user to the jira-administrators group. After that the administrator role in Jira is there, reached through a single vulnerability that formally only reads files. The CVSS vector from Atlassian carries exactly this direction, it sets confidentiality to High in the primary as well as in the secondary scope. The practical difference between reading files and taking over rights hangs on one configuration file.

State of play: numbers and exploitation

The CVSS vector in full wording: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H. The upgrade sits in the secondary scope, that is with the systems that become reachable through the data that was read, and for a Crowd installation connected to several products that is a considerable circle. Atlassian reports all clear for the cloud: according to the advisory the cloud products are patched, the investigation found no sign of exploitation, cloud customers have to do nothing. For the self-operated instances the vendor does not rule out impairment; the sentence in the advisory states that Atlassian cannot confirm whether its own instances are affected.

Two numbers stay in the ratings, because two bodies did the arithmetic themselves. Atlassian lists the vulnerability at 9.3 under CVSS 4.0. The BSI arrives at 8.6 base and 8.2 time-dependent in its report WID-SEC-2026-3755, both classified as high, dated 5 October 2026 and updated on 8 October; its product circle names Bamboo, Bitbucket, Confluence, Crucible, Fisheye and Jira, Crowd is missing there, although Atlassian lists four fixed versions for Crowd Data Center. The Dutch NCSC took over the 9.3 from Atlassian on 6 October 2026 at 18:47, priority Normaal. Neither report names a deadline by which patching has to be done.

Read off the Atlassian advisory (5 October 2026), the BSI report WID-SEC-2026-3755 (state of 8 October 2026) and NCSC-2026-0402 (6 October 2026). The range exists because the BSI scored the case independently instead of adopting the vendor number. (Quelle: Atlassian Advisory, BSI CERT-Bund, NCSC Netherlands)

Exploitation is now reported, four days after publication. According to the telemetry of the provider Previdian, evaluated by The Hacker News, 15 attack attempts from three addresses in Japan and the United States arrived in its honeypot network, the first of them two hours after watchTowr published the technical details. watchTowr confirmed to the same outlet that it observes active exploitation, most attempts aimed at probing known configuration files; no period after a break-in in which captured logins were used has been visible so far. These are provider statements carried by one report, neither a vendor figure nor an authority figure, and no report claims a confirmed break-in. The open check for operators therefore remains the log entry rather than the headline.

So far the case is absent from the official catalogue of exploited vulnerabilities kept by the American cyber security agency CISA: measured against the edition of 8 October 2026 with 6231 entries, no hit. The catalogue did not appear again over the weekend, so a later entry cannot be ruled out.

The researchers estimate the size of the affected estate from the FOFA platform, and the number is narrower than its reputation. Their sentence says an internet search yields just under 700,000 instances of Confluence alone, where the search term is the title of the login screen, so what is counted is the visibly answering service rather than the vulnerable installation. Jira does not appear in this count, and the same authors place the size of the actually affected set only broadly, in the six to seven digit range. This is no vendor statistic, and it says nothing about how many of those are unpatched. For testing, a checking tool has been sitting open on GitHub since 6 October, a Detection Artefact Generator, two files, three preset paths and a response check without a login; the authors show the complete chain up to the administrator role as an image in the post, the script for it stays under lock and key. The same holds for a Nuclei template: the report cited above quotes the expectation that its release makes mass automated scanning even easier. For operators both are useful and unpleasant at the same time: your own instance is checked in seconds, and so is every other one.

What operators do now

Patch to the fixed versions the advisory names for each product and line. Atlassian recommends the next maintained LTS level; the full table is linked in the advisory.
Take whatever cannot be patched today off the internet. Atlassian names switching off public reachability entirely as the first workaround, also behind a login, until the patch is in place.
Until then put the WAF rule from the advisory in place. It blocks URLs in which dot-dot sits directly next to a slash, backslash, colon, or the percent spellings of those characters. The rule in full wording:

(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*

The rule gets tested against both halves: the raw form ..:: and the encoded variants. Anyone who prefers to seal Tomcat on the host itself finds the route over the RewriteValve with a rewrite.config for Confluence, Jira Service Management, Jira, Bamboo and Crowd in the advisory.
Search the access logs for ..::, for %3a%3a and for dot-dot segments on the web resource routes. A hit means: somebody tried exactly the path the public analysis describes, and from then on the estate counts as potentially compromised.
Rotate the Crowd application passwords, on every connected product, as soon as an instance was reachable while unpatched for any length of time, even without a log hit. The password sits in plain text in a file the flaw makes readable, a log entry would be the worst of all traces for that.

Our own estate

We operate none of the eight products, and since 11 October that statement rests on three measured levels instead of an assumption from operations notes. First level, the guest population: through the management interface of our Proxmox clusters we searched the names of all guests of both clusters, 65 production guests and 20 more in the homelab, no hit for Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible or Fisheye. Second level, the edge: on our internal edge there are 36 configuration files holding 33 server names for senn-gruppe.com, no Atlassian product among them; the internal wiki one might mistake for one of them answers with a redirect to the help area of our Zammad ticket system and is not Confluence. Third level, the DNS: the internal zone with 101 entries carries no hit either.

What this measurement does not deliver belongs in that statement just as much: it checks names, not drives. An Atlassian product that is published under no DNS name and needs no vhost at the edge is not found by this measurement. Anyone running one of the products who does not know whether it sits on an affected line should check it with the open checking tool of the researchers against their own instance; the test only sends requests to your own address.