A file read on a documentation server is a credential exposure

Atlassian published an advisory on 5 October for CVE-2026-21589, an arbitrary file access flaw across eight Data Center products: Bitbucket, Confluence, Jira Service Management, Jira Software, Bamboo, Crowd, Crucible, and Fisheye ¹. An attacker with no account can read specific files inside the web application root, and Atlassian treats every version before the fixed releases as affected ¹. The request needs the exact file name and path, and the flaw does not list directories, so the attacker arrives with a target in hand ¹. Atlassian scores it 9.3 on the CVSS 4.0 scale and sets the severity level at Critical, with fixed builds listed for each product ¹. CISA added the CVE to the Known Exploited Vulnerabilities catalog on 15 October and set a federal remediation due date of 18 October, with forensic triage required ².

On its face that reads like a middling finding. Nothing writes to disk or executes code, and the attacker has to know a filename. I ranked it higher than its shape suggests, because of one line in Atlassian’s advisory: “In some configurations, there may be sensitive files present that increase your risk” ¹.

The file that returns a password

Crowd is Atlassian’s directory and single sign-on product, the place Jira, Confluence, Bitbucket, and Bamboo send authentication and group lookups. An instance wired into Crowd keeps that wiring in WEB-INF/classes/crowd.properties, and the file holds the application name and the application password in plaintext ³. watchTowr read it through a traversal built on double colons: the web-resource router replaces / with :: in one direction and turns :: back into / when it resolves a path, so an attacker can write a traversal as ..::..:: and step up out of the directory that route is meant to serve ³. Their requests pulled WEB-INF/web.xml on Jira and Confluence, and WEB-INF/urlrewrite.xml on Bitbucket, where web.xml was blocked. With the Crowd password in hand they authenticated to Crowd as the application, created a user, and added it to the jira-administrators group ³. The traversal stopped at the Tomcat context, and inside that boundary watchTowr read any file on the application server ³.

The severity of a read like that depends on what the instance keeps in the served tree. A read that returns a config file returns a credential, and the credential here opens the identity hub: the application account behind it can enumerate users, change group memberships, and create accounts.

The question I ask first

Two questions drive how I rank a file-read finding: how far the path escapes, and what sits inside the readable tree. The second one decides the verdict. My starting point is the files an installation of that product writes into its own web root: connector configs with application passwords, credentials for the database behind it, and whatever keystore or properties file an administrator left there while troubleshooting. In my experience that list grows on a documentation server, because the instance also holds the connectors that publish pages or sync a directory from somewhere else, and each of those connectors authenticates somewhere.

An unauthenticated read that lands on a plaintext password outranks a higher-scored bug that needs a user to open a file, because one hands the attacker a working credential and the other needs an action I can influence. That reordering is the change this advisory made to how I rank a file read.

The check I run in the logs

Atlassian’s detection guidance is specific: URL-decode each access-log request line up to two passes, then look for .. adjacent to /, \, or ::, or grep the raw lines with the regex from the advisory ¹. The decode step earns its place because the payload can arrive percent-encoded a second time, and a raw grep will miss it. A request for a path that climbs into WEB-INF deserves an incident ticket. The application never meant to serve that file, and the status code tells you whether the read succeeded.

Patching is the fix, and Atlassian ships a fixed build for every affected product, with the LTS version or later as the target. The fixes land on Confluence Data Center 9.2.26 and 10.2.19, and on the Jira Software trains at 9.12.40, 10.3.26, and 11.3.12 ¹. Where a patch cannot land this week, the advisory includes a WAF rule that blocks .. next to /, \, or ::, plus a Tomcat RewriteValve or urlrewrite rule for the Java products ¹. I treat those as a bridge. The rule blocks the traversal shape the vendor knew about at publication, and a flaw rated 9.3 with no authentication step is not something I want living behind a filter for months. Deployment runs through automation and the teams that own the systems, so what I add to a cycle is the ranking and the reason for it.

The record and the advisory disagree

As of 16 October the CVE record for CVE-2026-21589 reads Rejected, and the two records give different reasons: the CVE Program page says the ID was unused by the CNA, and NVD says the publication may have been a false positive or a mistake ⁴⁵. NVD’s entry carries no metrics and no references. Nothing else moved. The KEV entry keeps its due date. Atlassian’s advisory keeps its fixed versions, and watchTowr’s intel page reports exploitation it observed in the wild ¹²⁶. I cannot say which of the two reasons is accurate, and I do not need to. The practical change is the number I write down: with NVD holding no score, the vendor’s 9.3 is the one I cite, along with the page I took it from.

The fixed versions answer what to run. The files beside the application in that served tree are the part I can change this week, while the versions catch up.