Atlassian has shipped an out-of-band fix for a critical flaw that lets an attacker with no account read files straight off a self-hosted Jira, Confluence or Bitbucket server. The bug, tracked as CVE-2026-21589 and scored 9.3 under CVSSv4, sits in code shared across eight on-premises products, and Atlassian treats every version before the fixed releases as affected, including unsupported ones.
Atlassian Cloud is already patched and cloud customers need to do nothing. Everyone running their own servers does.
One shared library, eight exposed products
The advisory, published on October 5, covers Bitbucket Data Center, Confluence Data Center, Jira Software Data Center, Jira Service Management Data Center, Bamboo Data Center, Crowd Data Center, Crucible and Fisheye. Atlassian describes the issue as "arbitrary file access": an unauthenticated remote attacker who knows a file's exact name and path can retrieve it from inside the application's web root. It does not give a directory listing, so the attacker has to know what to ask for.
A day later, researcher Piotr Bazydlo of watchTowr Labs published a technical analysis built by comparing vulnerable and patched builds. The team traced the flaw to a web-resource component common to the products, which explains why one bug spans so many of them. In their testing the read could not escape the Tomcat application context, but it could reach protected configuration files inside it.
Why a file read can end in admin access
A file read sounds limited until you look at what some deployments keep in that web root. watchTowr showed that on a Jira server wired to Atlassian Crowd, Atlassian's identity and single sign-on product, a Crowd configuration file stored the application's credentials in plain text. With network access to Crowd, the researchers used those credentials to create a new user and add it to the Jira administrators group. Crowd's IP allowlisting can block that direct route, so how far an attacker gets depends heavily on configuration.
Rapid7's emergency response team, in its own write-up, notes that detailed analysis and file-read proof-of-concept scripts are now public and recommends patching on an emergency basis, outside normal cycles. Neither source reports exploitation in the wild so far. The exposure is large: watchTowr counts just under 700,000 internet-facing Confluence instances alone, though not all will be vulnerable.
The pattern is familiar. Unauthenticated file reads in developer platforms have a habit of turning into credential theft, as the recent GitLab file-leak bug showed.
Upgrade to the fixed builds, then hunt
Atlassian lists these 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 and Fisheye: 4.9.15
If you cannot patch immediately, take affected instances off the internet. Atlassian also publishes a WAF or proxy rule for all products, a Tomcat RewriteValve mitigation for most of them and a separate rule for Bitbucket, but Rapid7 stresses these are stopgaps, not replacements for the update.
Patching does not tell you whether someone got there first. Atlassian recommends URL-decoding access-log request lines up to twice and searching for directory-traversal sequences, and its advisory carries a regex for raw logs. If those logs show access to protected configuration files, contain the host and rotate every credential and secret it held, starting with any Crowd application password.
For most organizations the real question is not whether a Jira box is exposed, but what it can reach once someone reads its configuration.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.