BREAKING: Exploited Atlassian bug lets strangers read files off Jira, Confluence and Bitbucket Data Center, now on CISA KEV (CVE-2026-21589)

BREAKING: Exploited Atlassian bug lets strangers read files off Jira, Confluence and Bitbucket Data Center, now on CISA KEV (CVE-2026-21589)

How to fix CVE-2026-21589: upgrade Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible and Fisheye Data Center to Atlassian's Oct 5 fixed releases (Jira 9.12.40/10.3.26/11.3.12, Confluence 9.2.26/10.2.19, Bitbucket 9.4.26/10.2.8/10.5.1). Unauthenticated file read, on CISA KEV since Oct 15.

6 min read1,334 words
Contents

Anyone who can reach a self-hosted Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible or Fisheye server can pull files out of its web application folder without logging in. Atlassian published the fix for CVE-2026-21589 on October 5. On October 15, CISA added it to the Known Exploited Vulnerabilities catalog, which means it has evidence of attacks in the wild. Federal agencies have until October 18. If you run any Atlassian Data Center product that faces the internet and you have not upgraded since October 5, upgrade first and read the rest after.

This is our operator read of Atlassian's advisory, the CISA KEV entry, and the public research from watchTowr. A HOL Guard evidence pack for this CVE is not listed yet; we will link it here when it is.

How to fix

Upgrade every node to a fixed release on your line. Atlassian ships these as normal maintenance releases, not binary patches. Every version older than the fixed release on each line is affected; Atlassian lists "all versions" for every product.

ProductFixed versions
Jira Software Data Center9.12.40, 10.3.26, 11.3.12
Jira Service Management Data Center5.12.40, 10.3.26, 11.3.12
Confluence Data Center9.2.26, 10.2.19
Bitbucket Data Center9.4.26, 10.2.8, 10.5.1
Bamboo Data Center10.2.24, 12.1.12
Crowd Data Center6.3.7, 7.0.3, 7.1.7, 7.2.4
Crucible4.9.15
Fisheye4.9.15

Patch Bitbucket mirrors and mirror farm nodes too. They serve the same web app and are easy to forget because nobody logs in to them.

If you cannot upgrade today, Atlassian's first ask is to take the instance off the public internet. It says that applies to instances "with user authentication" as well, because the bug is reached before login. A login page in front of Jira does nothing here. A reverse proxy or VPN that refuses to forward any request until the user has authenticated is a different thing, and that is what "off the internet" means in practice.

After that, the advisory gives three stopgaps. Which one you can use depends on the product:

  • WAF or reverse proxy rule (all eight products). Block any URL that matches Atlassian's regex below. Its job is to stop .. sitting right next to /, \ or ::, including URL-encoded and double-encoded forms. This is the only stopgap Atlassian gives for Crucible and Fisheye.
  • Tomcat RewriteValve (Jira, Jira Service Management, Confluence, Bamboo, Crowd). Add the RewriteValve to the app's <Context> in server.xml, drop Atlassian's rewrite.config into the product's WEB-INF directory, and restart each node. Back up first.
  • urlrewrite.xml rule (Bitbucket only). Add Atlassian's rule to the top of <installation-directory>/app/WEB-INF/urlrewrite.xml on every node and mirror, then restart.

The regex from the advisory, unchanged:

(?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*

The :: part is the detail that matters. A WAF rule you already have for ../ will not cover it. Test your rule against the encoded and :: forms before you call the instance mitigated. Atlassian is clear that none of these replace the upgrade.

Check your version in two minutes

Compare what you run against the table above. From a machine that can reach the server:

# Jira Software / Jira Service Management
curl -s https://jira.example.com/rest/api/2/serverInfo | jq -r .version

# Bitbucket Data Center
curl -s https://bitbucket.example.com/rest/api/1.0/application-properties | jq -r .version

For Confluence, Bamboo, Crowd, Crucible and Fisheye, the version is in the page footer and on the admin System Information page. A Jira that answers 10.3.21 is exposed; 10.3.26 is fixed. Check each node in a cluster, not only the one behind your bookmark.

Why a "file read" made the exploited list

Atlassian's advisory has a sentence that is easy to skim past: "In some configurations, there may be sensitive files present that increase your risk." watchTowr's write-up shows the bug reaches files under WEB-INF, the part of a Java web app that is never meant to be served. On a stock install they did not find anything that alone justified a Critical rating.

Then they followed Atlassian's own guide for Crowd single sign-on in Jira. That guide puts crowd.properties in WEB-INF/classes, and the file holds the Crowd application name and password in plain text. With those, anyone who can reach your Crowd server's REST API can act as that application. In their lab that was enough to create a user and add it to jira-administrators. watchTowr also notes that a Crowd IP allowlist makes this much harder, because the attacker would then need a way to reach Crowd from an allowed address.

So the risk depends less on the version number and more on what your team put in that folder over the years. Crowd SSO is the documented case. Any secret someone dropped next to the app, like a copied config, a backup or a license file, is in the same spot.

Check whether your Jira (and Confluence, if you followed the equivalent guide) has the file:

# Jira
ls -l <jira-install>/atlassian-jira/WEB-INF/classes/crowd.properties
# Confluence
ls -l <confluence-install>/confluence/WEB-INF/classes/crowd.properties

If it exists and the server was reachable and unpatched at any point since October 5, upgrade, then rotate that Crowd application password in Crowd and in the file. In Crowd, review users and group memberships created since early October, with extra attention on admin groups. Restrict the application's allowed remote addresses in Crowd to the Jira or Confluence nodes if you have not already.

Who is not in scope

  • Atlassian Cloud. Atlassian already patched Cloud and found no evidence of exploitation there. No Cloud customer action is needed.
  • Instances already on a fixed release from the table above, on every node and mirror.
  • Servers that unauthenticated users cannot reach at the network level. Internal-only instances are lower priority, though anyone already on your network still counts.
  • Files outside the web application root. The bug does not reach the whole filesystem, and it does not list directories. An attacker has to know the exact file name and path to ask for it.

What this is not

This is not remote code execution on its own; it reads specific files the attacker already knows to ask for, and the damage comes from what those files contain.

Look for attempts in your logs

Atlassian says it cannot tell you whether your instance was hit. Its guidance: URL-decode each access log line up to two times and look for .. right next to /, \ or ::, or run the regex above against raw lines. Save the regex to a file and grep your Tomcat and proxy access logs:

grep -P -f atlassian-cve-2026-21589.rx /path/to/access_log* | less

Run it against your reverse proxy or load balancer logs too. Those often keep more history than the app nodes. A hit before you patched is a reason to treat the files under WEB-INF as read, starting with crowd.properties.

If you want an outside check on a Jira, Confluence or Bitbucket instance you own, watchTowr published a detection artifact generator that reports vulnerable or not.

The details

  • CVE: CVE-2026-21589, arbitrary file access in the web application root (CISA lists CWE-552, files or directories accessible to external parties).
  • Products: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo and Crowd Data Center, plus Crucible and Fisheye. Atlassian tickets BSERV-20604, CONFSERVER-104488, JSDSERVER-16809, JRASERVER-79546, BAM-26567, CWD-6610, CRUC-8741, FE-7583.
  • Severity: Atlassian rates it Critical, 9.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H). NVD has not finished its own analysis.
  • Preconditions: network reach to the web app, no account, and knowledge of the exact path of the file to read.
  • Timeline: Atlassian attached the rewrite.config mitigation to the public Jira ticket on October 2 (per watchTowr). Advisory and fixed releases on October 5. watchTowr research published October 6, and its FAQ says watchTowr Intel has seen in-the-wild exploitation since that date. CISA KEV added October 15, due October 18.
  • KEV: known ransomware use listed as Unknown. CISA flags it for forensic triage under BOD 26-04, so agencies need to look for compromise, not only patch.

References

Continue reading

All posts