On its own, a bug that reads files you can name sounds modest. It stops being modest when one of the files is a configuration file holding a password. Atlassian disclosed CVE-2026-21589 on 5 October: a critical arbitrary file access flaw, rated 9.3, in eight Data Center and Server products including Jira, Confluence, Bitbucket, Bamboo and Crowd. A public proof of concept followed within a day, and honeypot operators say attempts to exploit it started within hours.
Patching is the first job. The second is checking what an unauthenticated reader could have fetched from your servers, and what you would then have to rotate.
What is confirmed
Atlassian describes an unauthenticated attacker being able to access specific files within an application's web root directory. It stresses the limits: the attacker must know the exact file name and path, and the flaw does not let them list directories. The affected products are Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye in their Data Center or Server form, and all versions before the fixed releases are affected regardless of configuration. Atlassian says its cloud products are already patched and need no action.
Fixed versions reported from the advisory include Bitbucket 9.4.26, 10.2.8 and 10.5.1; Confluence 9.2.26 and 10.2.19; Jira Software 9.12.40, 10.3.26 and 11.3.12; Jira Service Management 5.12.40, 10.3.26 and 11.3.12; Bamboo 10.2.24 and 12.1.12; Crowd 6.3.7, 7.0.3, 7.1.7 and 7.2.4; and Crucible and Fisheye 4.9.15. Use Atlassian's bulletin for your exact product line. Atlassian also advises taking instances off the internet where possible, and says logins on public-facing instances do not remove the risk. It has published temporary mitigations, and says it cannot tell customers whether their own instances were accessed.
watchTowr traced the bug to a web-resource library shared across the products, in routing code that turns a double-colon sequence into a path separator. Rapid7's testing found the read stays inside the application: it could not traverse outside the Tomcat context but could read files throughout the application web root.
Why one file matters: the Crowd configuration
The write-ups describe a concrete chain. Atlassian's documentation places Crowd client settings in WEB-INF/classes/crowd.properties, which stores the application name and its password. That path is inside the web root. Rapid7 and BleepingComputer describe how, on a Jira instance integrated with Crowd, reading that file exposes the application credentials, and with network access to Crowd they could use them to create a user and add it to a Jira administrators group.
The path to Crowd is the hard part. Crowd's IP allow-listing blocks the direct route, and reaching it from outside may need a pivot through another machine. That is a real limit, not a guarantee: any other file in the web root that holds a secret is a candidate. What counts is what your instances keep there, and you should check rather than assume.
What is not established
- Confirmed compromises. BleepingComputer cites Previdian's honeypots seeing exploitation attempts within about two hours of watchTowr's public technical write-up, and watchTowr reports exploitation in the wild as of 6 October. Atlassian's advisory said its investigation found no evidence of exploitation, and the flaw was not on CISA's known-exploited list in the reporting we reviewed. Attempts against honeypots are not proof that any customer was breached.
- Which files were read. watchTowr says it does not know which files observed attackers targeted, or who they were.
- Who found it. The reporter has not been named.
- The credential chain beyond Crowd. The Crowd-to-Jira-admin route is a published demonstration. We have no evidence it has been used against a real organisation.
Public exploit scripts and a detection template for the vulnerability scanner Nuclei exist, and watchTowr has released a free scanner. Treat the window as open.
A response order
- Find every Atlassian Data Center or Server instance, including old ones and ones managed by another team, and note the product, version and whether it is reachable from the internet.
- Restrict exposure now. Take instances off the public internet where you can, put them behind a VPN or allow-list, and apply Atlassian's temporary rule while the upgrade is scheduled. Restrict Crowd to the hosts that need it.
- Upgrade to a fixed release. Atlassian and Rapid7 both call for immediate patching, outside the normal window.
- Search the logs. watchTowr suggests looking for a double dot next to a slash, backslash or double colon after decoding the URL up to twice. Keep the logs before any rotation or rebuild.
- Inventory secrets in the web root. Look for properties files, configuration files, keys and anything else under the application directory that holds a password or token, starting with
crowd.properties. Move secrets out of the web root where the product allows it. - Rotate on suspicion. If your logs show matching requests, or you cannot rule them out for an internet-exposed instance, rotate the Crowd application password and any credential found in files you identified. Then review Jira, Confluence and Bitbucket administrators for accounts nobody can account for.
- Check what these systems connect to. Bitbucket and Bamboo typically hold repository tokens, deployment keys and CI variables. If an instance was compromised, those are the next secrets to rotate, so find them before an incident, not during.
The handover step
Rotating a Crowd application password or a deployment key means giving the new value to whoever configures it, often a platform team or an external administrator. Under pressure these end up in the chat channel where the incident is being run, which is exactly the kind of place an attacker with a foothold in your tooling can read. Send each value once, to the one person who needs it, over a channel that does not keep it.
Where Secretus fits, and where it does not
Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret, such as a break-glass administrator password.
It is not an Atlassian security tool. It cannot patch Jira or Crowd, search your logs, move a secret out of a web root, or tell you whether CVE-2026-21589 was used against you. Do those with Atlassian's guidance and your own process, and use a one-time link for the step where one person gives another a value.
Sources
- watchTowr Labs: pre-auth arbitrary file read in Atlassian products (CVE-2026-21589)
- watchTowr: Atlassian arbitrary file access FAQ for CVE-2026-21589, 6 October 2026 (updated 7 October)
- Help Net Security: Atlassian urges immediate patching of critical Data Center file access vulnerability, 6 October 2026
- BleepingComputer: hackers exploit critical Atlassian flaw after public PoC release, 7 October 2026
- Rapid7: CVE-2026-21589, critical unauthenticated arbitrary file access in Atlassian products
