You Won’t Hear About These, Even In Myths (Atlassian Jira, Confluence (and more) Pre-Auth Arbitrary File Read CVE-2026-21589)
watchTowr finds a pre-auth arbitrary file read in Atlassian Jira and Confluence, CVE-2026-21589, with full root cause.
Extract
Welcome back to yet another episode of "security was taken seriously". Being who we are (and constantly being exposed to what we see…), we recognize we have been doomed to eternal damnation as we keep on watching security best practices crumble behind “secure by design” public statements. And in the times we live in, where anyone with a prompt window in front of them can say "reproduce the vulnerability, make no mistakes", so are you. In Greek mythology, Atlas was punished by the gods for misbehaving. Reality is unfair, and all we get is Atlassian punishing the rest of us for running their systems on-prem. And so they did, on October 5th, in a security advisory . Sometimes we regret that CVSS scores go as high as 10, because when a vulnerability is baked into almost all of a vendor's products across every version, the vulnerability deserves a special place (just like you, our dear reader). Welcome back to another watchTowr Labs blog post. What Is Going On Atlassian has published an out-of-band critical vulnerability advisory for CVE-2026-21589 for numerous Atlassian products. CVE-2026-21589 was reported by Atlassian as “Arbitrary File Access” and as we’ve come to learn, this means “Arbitrary File Read”. The CVSS score itself tells us a story: a vector showing no prerequisites of authentication or complexity. This vulnerability affects all previous versions of: 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 Service Management Data Center • 5.12.40 • 10.3.26 • 11.3.12 Jira Software Data Center • 9.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 Seeing this list of affected products, we stopped thinking about the potentially few thousand vulnerable instances exposed to the internet, and quickly realized we are in the six to seven-figure range. Bitbucket is a Git-based code hosting service where teams store, review, and collaborate on source code, with built-in pull requests and CI/CD pipelines. Confluence is a team wiki and documentation workspace for creating, organizing, and sharing pages like project plans, meeting notes, and technical docs. Jira is a project and issue tracking tool, widely …
Explained
What happened
On 5 October 2026 Atlassian shipped an out-of-band fix for CVE-2026-21589, an unauthenticated arbitrary file read affecting Jira, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Fisheye and Crucible Data Center. Researchers reconstructed it by comparing patched and unpatched builds:
- The one shared change sat in a common library,
atlassian-plugins-webresource, so a single flaw reached every product. - A static-resource route encoded path separators in an unusual way and decoded them back before resolving the file. The sanitizer that stripped normal traversal sequences ran before that decode step, so it never saw the encoded form.
- Using a built-in resource bundle whose configured location ended in a trailing slash, the request could reach the file-reading sink and climb out of the intended folder, though still inside the Tomcat application context.
- That alone leaks
WEB-INFfiles. The high severity comes from configuration: when Atlassian Crowd single sign-on is deployed per the official docs,WEB-INF/classes/crowd.propertiesholds the shared application password, which gives an attacker a foothold into the identity layer behind the whole stack.
Why it works
The sanitizer and the decoder ran in the wrong order. Normalizing input, then transforming it, means the final string is not the one that was checked. The reachable file-reading code was marked deprecated yet still wired into a live route, a reminder that dead-looking code is still attack surface. The severity jump is a composition effect: a file read is medium on its own, but combined with a documented config that stores a reusable secret in a readable path, it becomes critical.
The bigger pattern
This is check-then-transform, the ordering cousin of TOCTOU, and it shows up anywhere decoding, canonicalization and validation are not done in a fixed, repeated order. The same shape appears in URL parsers, proxies that normalize differently than their origin, and filename handling. The broader lesson is that a shared library multiplies one bug across an entire product line, and that impact depends on what secrets sit in a readable location.
What it means in practice
- Canonicalize first, then validate the canonical form, and reject anything that still decodes to a separator. Do not validate raw input and transform it afterward.
- Resolve file paths and confirm the result stays under an allowlisted base directory, rather than trying to filter traversal sequences out of the input.
- Keep secrets out of any directory served or reachable by the web application. For web backends, that means database URLs, service credentials and SSO keys belong in a vault or environment, not under the web root.
- When one library is shared across services, patch every consumer together, since attackers will diff the fix and pivot to the slowest to update.
- Audit deprecated routes and handlers. Marking code deprecated does not remove it from the request path.