On 15 October, CISA added an Atlassian flaw to its list of vulnerabilities being exploited in the wild. If your company runs Jira, Confluence, Bitbucket, Bamboo or Crowd on its own servers, this one is yours to deal with.
The bug, CVE-2026-21589, lets someone with no account read files from the web application's root folder. Atlassian rates it 9.3 out of 10. It published the advisory on 5 October, so anyone who has not patched has now been exposed for well over a week, and attackers are using it.
Atlassian Cloud is already fixed and Atlassian says it found no exploitation there. This is a Data Center and Server problem.
Versions that fix it
| Product | Fixed versions |
|---|---|
| Jira Software | 9.12.40, 10.3.26, 11.3.12 |
| Jira Service Management | 5.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 |
| Bamboo | 10.2.24, 12.1.12 |
| Crowd | 6.3.7, 7.0.3, 7.1.7, 7.2.4 |
| Crucible and Fisheye | 4.9.15 |
If you cannot patch today, Atlassian's advice is to take the instance off the public internet. It also publishes reverse proxy and Tomcat rules that block the bad requests. Treat those as a bridge for a day or two, not a fix.
Why a file read is worse than it sounds
"Read files" can sound mild next to remote code execution. It isn't. A web root on a long-lived Jira or Bitbucket box tends to collect things nobody meant to leave there: config files with database passwords, application tokens, backup scripts with cloud keys in them. Bitbucket and Bamboo sit right next to your source code and your build credentials.
So patching is step one. Step two is checking whether anyone got in before you patched. Go through the HTTP access logs since early October and look for path traversal requests that returned 200. If you find any, rotate every credential that lived in or near the web root, and assume it was copied.
The pattern we keep seeing
Last week we wrote about attackers hitting GitLab and Artifactory within days of patches coming out. Now it is Atlassian. Self-hosted developer tools have become a favourite target because they hold source code, secrets and build systems in one place, and they are often maintained by whoever has a spare afternoon.
If you are a CTO or head of platform, the useful question this week is simple. Who owns patching for each self-hosted tool your engineers depend on, and how fast do they move when a critical advisory lands? If the honest answer is "the person who set it up, when they get to it", that is the gap to close. For some teams, that conversation ends with moving to the cloud versions and letting the vendor carry the patching.
