Atlassian's CVSS 9.3 File-Read Flaw Is Being Exploited. The Advisory Lists Every Version of Eight Products as Affected

Atlassian published a security advisory on 5 October for an arbitrary file access flaw in eight of its self-hosted products. On 7 October, BleepingComputer reported that attackers are exploiting it. The gap between those two dates is two days, and the gap that matters is shorter than that: the security firm Previdian says it saw exploitation attempts land on its honeypot network within roughly two hours of a public proof-of-concept appearing.

The vulnerability is CVE-2026-21589, rated 9.3 on CVSS v4.0. It requires no authentication, no user interaction and no particular privileges. Atlassian's own description is deliberately narrow:

This Arbitrary File Access vulnerability allows an unauthenticated attacker to access specific files within the web application root directory in affected versions.

What the narrow wording conceals

Read literally, this is a file-disclosure bug with a real constraint attached: an attacker has to know the exact path of the file they want, because the flaw does not let them list a directory and browse. That constraint is why the CVSS vector scores confidentiality high but integrity and availability at none — nothing is written, nothing is crashed.

It is also why the score is still 9.3 rather than something middling. On a self-hosted Atlassian deployment, the interesting file paths are not secrets. They are the same paths on every installation, documented in the vendor's own material and visible in any copy of the software. Researchers at watchTowr, who published the technical analysis alongside Atlassian's advisory, demonstrated that reading a known configuration path inside the application root is sufficient, in deployments integrated with Atlassian's identity product, to recover credentials and escalate to administrator. A read-only bug that reliably yields an administrator account is not a read-only bug in practice.

The subordinate-system impact metrics in the CVSS vector — high on confidentiality, integrity and availability of downstream systems — are the scoring committee's way of saying the same thing. Jira and Confluence are where organisations keep credentials in ticket comments, architecture in wiki pages, and incident timelines with the hostnames attached. Bitbucket is where they keep source code. The file read is the entry; it is rarely the objective.

Affected and fixed versions

Atlassian lists every released version of all eight products as affected. There is no safe older branch to sit on.

Atlassian Cloud customers are not affected; the vendor patched its own hosted instances and says no customer action is required. The exposure is entirely in the self-hosted estate — which, since Atlassian ended Server licensing, is the Data Center estate, concentrated in exactly the organisations that chose not to move to Cloud: regulated industries, defence contractors, government, large enterprises with their own compliance reasons for keeping Jira on their own hardware.

The two-hour number

Previdian's honeypot timing is the most useful fact in this story, and it is not about Atlassian. A public proof-of-concept for an unauthenticated flaw in widely deployed enterprise software now converts to scanning traffic faster than most change-management processes can schedule a maintenance window. Two hours is not enough time to get an emergency patch through a change board. It is barely enough time to read the advisory.

That is the argument for Atlassian's secondary mitigations, which it published before the advisory itself — a mitigation file went out publicly on 2 October. The vendor lists network-level restriction of external access, web application firewall or proxy rules that reject traversal-style request paths, and product-specific URL rewriting: a Tomcat RewriteValve configuration for Confluence, Jira, Jira Service Management, Bamboo and Crowd, and a urlrewrite.xml change for Bitbucket. None of these is a substitute for patching. All of them can be deployed in less time than a patch, which is the point.

What to do

Patch to the versions above. If a maintenance window is days away, apply the vendor's mitigation for your product in the meantime and take the instance off the public internet if it does not need to be there. Then review access logs for traversal-style request paths against plugin resource endpoints, going back to 2 October rather than to 7 October — the public proof-of-concept is when mass scanning started, not when the first person could have known. Treat any credential reachable from the application root on an unpatched, internet-facing instance as exposed, and rotate it.

The flaw was not in CISA's Known Exploited Vulnerabilities catalogue as of 6 October. Given the honeypot data, that is a matter of paperwork catching up.

Sources: Atlassian security advisory: CVE-2026-21589 · BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release · BleepingComputer: Atlassian warns of critical file-access flaw in Jira, Confluence · watchTowr: Atlassian arbitrary file access vulnerability FAQ