Eight products, nineteen versions: Atlassian's advisory tells you what to do, not what you have

Atlassian's 5 October advisory asks you to do three things: patch to one of nineteen versions, pull the instance off the internet in the meantime, and dig through your access logs. All three are reasonable and well explained. All three start with a question they cannot answer for you from Australia: what you run, and where.

We are talking about CVE-2026-21589, published on 5 October 2026. Arbitrary file access, unauthenticated, 9.3 under CVSS 4.0 by Atlassian's own assessment, critical. It affects eight self-hosted products: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye. In the affected-versions table all eight say the same thing: "All versions are affected". Atlassian Cloud is already patched and needs no action from its customers.

The description of the flaw, whole and uncut. These are two consecutive paragraphs of the advisory:

«This Arbitrary File Access vulnerability allows an unauthenticated attacker to access specific files within the web application root directory in affected versions. Exploitation requires prior knowledge of the target file's exact name and path; this vulnerability does not allow attackers to enumerate or list directory contents.»

«In some configurations, there may be sensitive files present that increase your risk. All Data Center products listed below are at risk and require immediate attention.»

The two halves pull in different directions, and both are the vendor's. The first narrows things down: with no directory listing, you need the exact name and path. The second warns that in some configurations there will be sensitive files raising the risk, and closes with "require immediate attention". Which of the two is your case depends on the state of your installation, and Atlassian does not know that. They put it in writing further down, in the detection section: "Atlassian cannot confirm if your instances have been affected by this vulnerability". A point of precision while we are here: that sentence says "All Data Center products", and two of the eight affected —Crucible and Fisheye— do not carry Data Center in their name. They are on the list all the same.

Instruction one: patch. That is nineteen versions

The advisory's table, with the rows in our own order. The right-hand column, as we read it, holds each product's live maintenance branches, and the usual move is for each installation to go up within its own; Atlassian puts it more openly: "patch each of your affected installations to fixed versions or the latest version", so jumping to the latest is fair game too if you can afford it. And it recommends the fixed LTS version or later.

Nineteen fixed versions in a single advisory. Crowd —which in many shops is the identity service sitting in front of everything else— shows up with four live branches. The two Jiras carry three branches each. Crucible and Fisheye share 4.9.15, which figures, given they share half a codebase.

Try asking your team "what version are we on?". If the answer is "10.2", three products in this advisory have a 10.2 branch —Bitbucket, Confluence and Bamboo— and all three take different patches. If the answer is "the latest", that does not help either: there are three latest Jira Softwares and three latest Jira Service Managements. We went round something similar when a NetScaler version number was not enough to tell whether you were exposed; the bar is lower here, because the number does not even tell you which patch is yours.

Instruction two: if you cannot patch, take it off the internet

Atlassian asks you to remove the instance from the internet until you can patch or mitigate, and adds that instances reachable from the public internet "including those with user authentication" should be kept out of external reach in the meantime. Sitting behind a login does not count as mitigation, and that rules out in one stroke the quick answer most people would give.

If taking it down is not viable, the advisory numbers three options, and the parenthesis on each one is worth reading, because they do not cover the same ground. Option 1, the only one marked "For All Affected Products", is a web application firewall or proxy-layer rule blocking the pattern by regular expression; the stated intent is to block .. when it sits immediately adjacent to /, \ or ::, including the encoded forms. Option 2 is Tomcat's RewriteValve, and it covers only Confluence, Jira Service Management, Jira, Bamboo and Crowd. Option 3 is a rule in urlrewrite.xml, which the advisory marks "For Bitbucket only".

Cross the parentheses against the list of affected products and the thing that matters falls out: for Crucible and Fisheye there is no option 2 and no option 3. If you run those two and cannot patch them today, you are left with the firewall rule or pulling them off the internet, and there is no third door. The exact rule and the specific paths are in the advisory; we are not copying them here so that nobody applies them from a translation. What you do need before picking any of the three is knowing, product by product, which ones are reachable from outside, how traffic gets in and what sits in front. With one Confluence that is answered from memory; with eight products spread across a proxy, a VPN and an access opened "temporarily" for a supplier, it is half a morning before you can touch anything.

Instruction three: check the logs. Do you have them?

The detection section runs to one paragraph. Atlassian acknowledges it cannot confirm whether your instance has been affected, asks your security team to check every affected installation for evidence of compromise, and hands over the method: URL-decode each access-log request line —up to two decoding passes, because the pattern can arrive double-encoded— and then look for .. immediately adjacent to /, \ or ::. Alternatively, run the same regular expression over the raw lines.

It is an excellent instruction, which is why the next question stings: how far back do your access logs go? The advisory landed on 5 October, but the flaw affects every version prior to the fixed ones, so the window you would want to look at does not start on 5 October. If rotation keeps seven days, or if the log lives on the box you are about to rebuild, the instruction is perfect and still cannot be carried out. We have written before about how an issue title ended up leaking a Jira token; the thread running through both is the same, that what goes unrecorded cannot be reconstructed later.

Where the record piles up: thirteen, eight and zero

As of today there is no catalogued exploitation of this CVE. We checked this morning against the public file of CISA's KEV catalogue —the list of vulnerabilities with confirmed exploitation— version 2026.10.04, 1,734 entries: CVE-2026-21589 is not there. That figure should not be stretched: CISA not having catalogued it does not mean nobody is using it, and all Atlassian says about Cloud is that its investigation has not found evidence of exploitation.

While we were at it, we asked about the whole vendor instead of the CVE. The query takes as long as the download takes:

curl -s "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json" \
  | jq -r '[.vulnerabilities[] | select(.vendorProject=="Atlassian")]
           | length,
             (map(select(.knownRansomwareCampaignUse=="Known")) | length),
             (map(select(.product | test("Cloud"))) | length)'

13
8
0

Thirteen historical Atlassian vulnerabilities with confirmed exploitation. Eight of the thirteen flagged as used in known ransomware campaigns. And the third figure: none belongs to a Cloud product. That does not prove Cloud is safer, and we are not going to sell it that way —a Cloud flaw gets fixed by the vendor without anyone having to catalogue it, so by construction it never reaches KEV. What it does describe is where the work lands when an advisory like Monday's comes out. One detail that only shows up when you sort by date: the best-known entry on that list, Confluence's CVE-2023-22515, entered the catalogue on 5 October, three years to the day before this advisory.

The order we would work in

What we are not claiming

With one Confluence and little else, this is an afternoon and you need nobody: check the branch, upgrade, confirm how it is reached. It weighs when it is all eight, each on its own branch, with a Crowd in front authenticating the rest and a Fisheye nobody has thought about in years. At that point the bottleneck stops being technical: it is knowing what you have, on which branch and who watches it, and having somebody read the advisory first thing on Monday rather than on Thursday, which is literally what 24×7 support is. Conflict of interest up front: we sell both. If your own people already own this, good, and you owe us nothing. If nobody owns it, which is the usual case, let us talk.

Sources