Attackers are already scanning for CVE-2026-21589, a critical unauthenticated file-read flaw that Atlassian disclosed on October 5 across eight self-hosted products, including Jira, Confluence, Bitbucket and Crowd. Any internet-facing self-hosted Atlassian instance that hasn't been patched should be treated as exposed today.
What happened
Atlassian published its advisory on October 5, 2026, rating the flaw critical with a CVSS 4.0 score of 9.3. An unauthenticated attacker can read specific files inside the web application root directory. Atlassian notes the attacker has to know the exact file name and path, because the bug does not allow directory listing. Every version of these products is affected, and fixes are available:
| Product | Fixed versions |
|---|---|
| Bitbucket Data Center | 9.4.26, 10.2.8, 10.5.1 |
| Confluence Data Center | 9.2.26, 10.2.19 |
| Jira Software Data Center | 9.12.40, 10.3.26, 11.3.12 |
| Jira Service Management Data Center | 5.12.40, 10.3.26, 11.3.12 |
| Bamboo Data Center | 10.2.24, 12.1.12 |
| Crowd Data Center | 6.3.7, 7.0.3, 7.1.7, 7.2.4 |
| Crucible | 4.9.15 |
| Fisheye | 4.9.15 |
Atlassian says affected Cloud products have already been patched and it found no evidence of exploitation there. For self-hosted customers who can't upgrade right away, the advisory lists three interim mitigations: a WAF rule that blocks path traversal, a Tomcat RewriteValve rule (Confluence, Jira, Jira Service Management, Bamboo, Crowd), or a urlrewrite.xml rule for Bitbucket.
watchTowr Labs published a technical write-up and proof of concept on October 6. They trace the root cause to the web-resource plugin's escape logic, which converts :: back into / and so lets a request climb out of the intended directory. On October 7, Johannes Ullrich of the SANS Internet Storm Center reported that honeypots had been seeing exploit attempts since October 5, from 13 source IPs all on DigitalOcean infrastructure. The requests aimed at files like WEB-INF/web.xml and WEB-INF/urlrewrite.xml through Jira, Confluence and Bitbucket resource paths.
Why it matters
A file read sounds less severe than code execution, but on these platforms the files that matter hold credentials. watchTowr shows that on a Jira instance using Crowd for identity, the readable WEB-INF/classes/crowd.properties file holds the Crowd application name and password. With those, they created a new user in Crowd and added it to jira-administrators. They note this depends on how permissive the Crowd IP allowlist is, and that real deployments vary.
That is the identity angle here. Crowd is the directory and SSO broker for many self-hosted Atlassian estates. Once an attacker has an application credential trusted by Crowd, a pre-auth file read can turn into administrator access in every connected application. Patching closes the read. It does nothing about secrets that may already have been taken. Because the SANS scanning began the same day the advisory went out, assume any unpatched, internet-facing instance has been probed.
What to check in your environment
- Inventory every self-hosted Atlassian instance across all eight products, including staging and forgotten departmental servers, and record each one's version against the table above.
- Upgrade to a fixed release. If you can't do it this week, apply one of Atlassian's three mitigations, or follow Atlassian's advice to take the instance off the internet until it is patched or mitigated.
- Review web and access logs back to at least October 5 for requests containing
..::sequences or ending inWEB-INF::file names. SANS lists sample paths under/download/resources/and/s/…/_/download/resources/. Atlassian's advisory also tells customers to check access logs for signs of compromise. - If you find hits, treat config secrets as exposed. Rotate the Crowd application password in
crowd.propertiesalong with any other credentials stored under the web root, and check with each product's owner which files apply to their instance. - Audit Crowd for new or changed accounts and unexpected membership in administrator groups such as
jira-administratorssince October 5. - Tighten the Crowd application IP allowlist so only the specific application servers can authenticate. watchTowr notes a restrictive list limits the credential-reuse path.
- Name an owner for each product and confirm the upgrade or mitigation is in place, so no instance ends up unpatched because nobody claimed it. Blocking the scanning sources at your edge can help, but it doesn't replace patching.