SEKurity GmbH Logo
CVE Research

InSEKurity of the Week (CW41/2026): Atlassian Data Center Pre-Auth Arbitrary File Read (CVE-2026-21589)

One unauthenticated request to Jira, Confluence or Bitbucket reads files out of the webapp root -- including WEB-INF, where crowd.properties can hand over plaintext credentials and, from there, admin on the instance. CVSS 9.3, eight products, all versions, exploitation attempts within hours of the public write-up.

SEKurity Team

Offensive Security Experts

17 min read
Share:

This week in our InSEKurity of the Week series: the vulnerability that reads your secrets out of the one directory a web application is never supposed to serve. On October 5, 2026, Atlassian published an out-of-band advisory for CVE-2026-21589, an arbitrary file access flaw affecting eight of its self-hosted Data Center and Server products — Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye. It scores CVSS 4.0 9.3, needs no authentication, and affects all previous versions of every one of those products.

The advisory is careful about what the bug does: an attacker can read a specific file inside the web application root if they know its exact name and path, but cannot list or enumerate directories. That framing undersells it. The web application root includes WEB-INF, the Java servlet directory that holds configuration and, in common deployments, credentials. Independent research published the day after the advisory walked the chain from “read one known file” to plaintext Crowd application credentials to administrator on the instance — without ever logging in.

What makes this an InSEKurity rather than a footnote is the install base and the clock. Jira and Confluence are the default system-of-record and build pipeline for a very large share of enterprise IT. Atlassian issued the advisory out of band, not on its normal Tuesday cadence. And exploitation attempts against Atlassian Data Center were reported within hours of the public technical write-up landing — the gap between “patch available” and “being probed” was measured in a single working day.

🚨 Summary

  • CVE ID: CVE-2026-21589
  • CVSS 4.0 Score: 9.3 Critical (scored by Atlassian)
  • CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”)
  • Vendor Advisory: Atlassian out-of-band advisory, published 2026-10-05
  • Affected Software: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible and Fisheye — Data Center and Server editions, all previous versions
  • Attack Vector: Network — anywhere the web interface answers
  • Authentication Required: None
  • Root Cause: A path-traversal sequence survives the request. Shared web-resource code converts :: into / after the request has passed edge filtering, so a traversal encoded as ..::..:: reaches a file-read sink without tripping slash-based checks
  • Impact: Unauthenticated read of files in the webapp root, including WEB-INF. In Crowd-integrated deployments this can expose plaintext application credentials, which chain to administrator access via Crowd’s REST API
  • Patch Status: Available — fixed releases shipped for all eight products (table below)
  • Cloud: Not affected / already patched. Atlassian Cloud customers need take no action
  • Workarounds: Atlassian published temporary mitigations; they do not replace patching
  • Exploitation Status: Exploitation attempts observed in the wild shortly after public technical details were released; a detection tool and public analysis exist
  • CISA KEV: Not listed at the time of writing
  • The part people miss: the advisory says “specific files,” which reads like low severity. The specific file that matters is WEB-INF/classes/crowd.properties, and on a Crowd-integrated instance that one file is enough to become admin

🖥️ What is Atlassian Data Center?

Atlassian Data Center (and the now largely retired Server line) is the self-hosted edition of Atlassian’s product suite. Where Atlassian Cloud runs the software for you, Data Center runs on infrastructure you own — behind your firewall, on your Tomcat, with your database. Organisations choose it for data-residency, regulatory and latency reasons, which means Data Center instances disproportionately belong to banks, governments, defence contractors and large enterprises: exactly the places where the contents of WEB-INF are worth stealing.

The eight affected products cover most of an engineering organisation’s connective tissue:

  • Jira Software / Jira Service Management — issue tracking, project management and IT service desk; the system of record for what an organisation is building and what is broken.
  • Confluence — the wiki and knowledge base; in practice, where credentials, runbooks, architecture diagrams and incident notes accumulate.
  • Bitbucket — Git hosting and the source of truth for code and CI configuration.
  • Bamboo — continuous integration and deployment.
  • Crowd — centralised identity and single sign-on for the other products, and often for third-party applications too.
  • Crucible / Fisheye — code review and repository browsing.

Typical Use Cases

  • Hosting source code, build pipelines and deployment automation on-premises
  • Centralising user directories and SSO across the Atlassian estate through Crowd
  • Running an IT and customer service desk on Jira Service Management
  • Keeping internal documentation, including sensitive operational detail, in Confluence

Why a File Read Is Different Here

A pre-auth arbitrary file read on a brochure website is an information leak. A pre-auth file read on a Crowd-integrated Jira is a credential disclosure that leads to identity-provider access, because the product’s job is to hold the keys to everything else. The severity of this class of bug is set almost entirely by what is sitting in the directory the attacker can now reach — and on a mature Atlassian deployment, that directory is full.

🔍 Technical Analysis

Vulnerability Description

CVE-2026-21589 is an unauthenticated path traversal in a component shared across the Atlassian product line, exposed through the static-resource download endpoints that every product uses to serve CSS, JavaScript and images. Because the flaw lives in shared web-resource handling rather than in any one product, a single root cause surfaces in all eight affected products at once, under slightly different URL prefixes.

Root Cause Analysis

  1. Shared resource router. The atlassian-plugins-webresource component resolves static-resource requests. To carry path segments safely inside a single URL segment, it escapes / as :: and later unescapes :: back to /.
  2. Unescape happens after filtering. The unescape step runs on user-supplied path segments inside the application, after the request has already passed any edge filtering that looks for /, \ or classic ../. A traversal written as ..::..:: contains no slash to catch at the edge, and becomes ../../ only once the router has already accepted it.
  3. Ineffective sanitisation at the sink. The deprecated resource-serving path that handles these requests attempts to strip traversal, but the stripping does not account for the :: encoding, so the normalised ../ sequences survive to the file-read operation.
  4. A resource mapping anchored to a real directory. A built-in plugin resource maps an images/ path to a fixed local directory with a trailing slash, giving the traversal a concrete, writable-adjacent anchor from which to climb out of the intended directory and into WEB-INF.

The net effect is a textbook CWE-22: user input decides which file on disk the server reads, and the control that was supposed to confine it to a safe directory does not.

Attack Vector

The public research by watchTowr demonstrated the chain against Jira, Confluence and Bitbucket, each via its own static-resource download prefix. The shape of a request — shown here for understanding and detection, not as a copy-paste exploit — is a normal-looking resource download whose final path segment carries the ::-encoded traversal into WEB-INF:

# ILLUSTRATIVE -- request SHAPE for detection and log review only.
# Based on public watchTowr research; NOT a functional, drop-in exploit.
# The signal to hunt for is the combination of a /download/resources/
# path, "::"-encoded traversal, and a WEB-INF target in one request.

GET /download/resources/<plugin-key>/images/..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: jira.example.com

The attacker must know the exact path of the file they want — the bug reads a named file, it does not list directories. In practice that is not much of a barrier, because the interesting files live at well-known, product-standard paths:

  • WEB-INF/web.xml — confirms the read works and reveals the app layout.
  • WEB-INF/classes/crowd.properties — on a Crowd-integrated instance, this holds the application name, the Crowd URL, and a plaintext application password.

Exploitation in the Wild

  • 2026-10-05 — Atlassian publishes the advisory out of band and ships fixes.
  • 2026-10-06 — Public technical analysis is released, including a detection artifact generator.
  • Within hours of the public details, security vendors reported exploitation attempts against Atlassian Data Center instances. The research itself noted no confirmed in-the-wild exploitation at the moment of publication; reporting of attempts followed quickly after, which is the pattern to plan around.
  • No CISA KEV listing at the time of writing, and no confirmation from Atlassian that any Data Center instance was successfully exploited — Atlassian’s own guidance is that it cannot rule it out and that customers should check for signs of compromise.

Post-Exploitation Impact

  1. Disclosure of WEB-INF contents — configuration files, and anything else an application happens to keep inside its servlet directory.
  2. Plaintext Crowd application credentials from crowd.properties on integrated deployments.
  3. Crowd REST API access using those credentials — the research used it to create a user and add it to jira-administrators.
  4. Administrator on the Atlassian product, reached without a single valid login, if Crowd is reachable from the attacker’s position.
  5. Downstream disclosure of whatever the compromised product governs: source code and CI secrets in Bitbucket/Bamboo, operational documentation and secrets in Confluence, ticketing and customer data in Jira.

📊 Impact Assessment

Immediate Impact

  • Unauthenticated, remote, low-complexity file read against the webapp root of any unpatched instance that answers on the network.
  • Credential exposure wherever sensitive files sit inside the webroot — crowd.properties is the headline, but any secret an operator placed under WEB-INF is in scope.
  • Escalation to instance admin on Crowd-integrated deployments where Crowd’s REST API is reachable.
  • No authentication logs to help you — the request never authenticates, so it will not appear in your login or audit trails. The evidence is in the web/access log, not the application audit log.

Affected Versions

All previous versions of each product are affected. Fixed releases:

ProductFixed versions
Bitbucket Data Center9.4.26, 10.2.8, 10.5.1
Confluence Data Center9.2.26, 10.2.19
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
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

Atlassian Cloud products are not affected and have already been patched.

Affected Environments

  • Self-hosted Atlassian Data Center / Server of any of the eight products, at any version prior to the fixes above.
  • Internet-facing instances are at highest risk, but any instance reachable by an attacker who already has a foothold (user VLAN, VPN, compromised workstation) is exposed — the bug needs no credentials.
  • Crowd-integrated deployments carry the extra escalation risk, especially where Crowd is not IP-allowlisted.

Attacker Profiles

  • Opportunistic operators running internet-wide scans for /download/resources/ traversal, harvesting crowd.properties at scale once a PoC circulates.
  • Ransomware affiliates and access brokers, for whom admin on a Jira/Confluence/Bitbucket estate is both a data-theft target and a staging point.
  • Targeted intrusion sets interested in the specific source code, tickets and documentation a given organisation keeps in Atlassian — the Data Center population skews toward exactly these targets.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1)

  1. Identify every affected instance and its version. Check the product’s reported version against the fixed-release table above. These REST endpoints return the running version and are commonly reachable without authentication — use them to inventory quickly:

    # Jira -- serverInfo returns the running version as JSON.
    # -s silent, -k only if you must skip TLS verification on an internal host.
    curl -s https://jira.example.com/rest/api/2/serverInfo | grep -o '"version":"[^"]*"'
    
    # Confluence -- the applinks manifest exposes <version> in its XML.
    curl -s https://confluence.example.com/rest/applinks/latest/manifest | grep -o '<version>[^<]*</version>'
    
    # Bitbucket -- application-properties returns the version string.
    curl -s https://bitbucket.example.com/rest/api/1.0/application-properties | grep -o '"version":"[^"]*"'
  2. Upgrade to a fixed release for each product (table above). This is the only fix; the temporary mitigations buy time, they do not close the hole.

  3. Take publicly reachable instances off the public internet until patched, as Atlassian recommends — including instances that sit behind a login page, because this bug does not need the login.

  4. Apply Atlassian’s published temporary mitigations on anything you cannot patch immediately, exactly as written in the advisory. Note that naive WAF rules keyed only on /, \ or ../ will not catch the ..::..:: encoding on their own; rely on the vendor’s current guidance, not a hand-rolled slash filter.

Detection Measures

The bug leaves its trace in the web/access log, not the application audit log, because the request never authenticates. Hunt for resource-download requests that carry traversal or reach WEB-INF:

# Search Tomcat/reverse-proxy access logs for the exploit SHAPE:
# a /download/resources/ request containing "::"-encoded traversal,
# a classic "../", or an explicit WEB-INF reference.
# -E extended regex, -i case-insensitive, -r recurse the log dir.
grep -E -i -r '/download/resources/.*(::|\.\.|%2e%2e|WEB-INF)' /var/atlassian/*/logs/
# Splunk SPL -- same question over web access logs indexed as "web".
# Replace index, field names and host filter with your own.
index=web uri_path="/download/resources/*"
  (uri="*::*" OR uri="*..*" OR uri="*WEB-INF*")
| stats count AS hits, values(status) AS statuses, earliest(_time) AS first_seen
        BY src_ip, uri
| sort - hits
# Microsoft Sentinel / Defender KQL -- normalised web logs.
# Adjust the table and column names to your schema.
W3CIISLog
| where csUriStem startswith "/download/resources/"
| where csUriQuery has "::" or csUriStem has ".." or csUriStem has "WEB-INF"
| summarize Hits = count(), FirstSeen = min(TimeGenerated) by cIP, csUriStem
| order by Hits desc

Run the public detection artifact generator (watchTowr published watchTowr-vs-Atlassian-CVE-2026-21589) against your own instances to confirm patch state, and if you suspect exposure, rotate the Crowd application password and any secret that lived under WEB-INF — a file that was readable must be treated as read.

Long-term Security Improvements

  1. Treat the Atlassian estate as Tier-0-adjacent. Crowd is an identity provider; Bitbucket holds your source and CI secrets; Confluence holds your operational knowledge. Monitor, segment and change-control them accordingly, not as “internal web apps.”
  2. Never put instances on the open internet by default. Data Center is self-hosted precisely so you control exposure; reach it through VPN or a reverse proxy with authentication in front, not a public DNS record.
  3. IP-allowlist Crowd. The escalation path in this CVE depends on Crowd’s REST API being reachable with leaked credentials. Restricting which hosts may call Crowd turns a credential leak into a dead end.
  4. Keep secrets out of WEB-INF where you can, and inventory what is there where you cannot. The blast radius of any file-read bug is whatever you left in the webroot.
  5. Ship web/access logs off-box in real time. The only trace of this attack is in logs an attacker with file read cannot see — but an attacker who later gets admin can. Centralised, append-only logging preserves the evidence.
  6. Subscribe to Atlassian security advisories and route them to someone who can schedule an emergency patch. An out-of-band advisory is the vendor telling you not to wait for the maintenance window.

⚠️ Why is this Critical?

  1. Unauthenticated and low-complexity. One crafted request, no credentials, from anywhere the instance answers.
  2. Eight products, all versions. The usual triage step where half the estate turns out not to be affected does not apply here.
  3. It reaches WEB-INF. The one directory a Java web app must never serve is exactly where the traversal lands.
  4. “Read one file” becomes “become admin.” crowd.properties to plaintext credentials to Crowd’s REST API to jira-administrators is a documented, demonstrated chain.
  5. The install base is the enterprise. Data Center is where the regulated, high-value organisations keep their code, tickets and documentation.
  6. Out-of-band disclosure. Atlassian broke its own release cadence, which it does only when it judges the risk cannot wait.
  7. The window was hours. Exploitation attempts were reported within a working day of the public write-up. There was no quiet period to patch in.
  8. It hides from your audit log. The request never authenticates, so the evidence is in the access log, not the place most teams look first.

📅 Timeline and Disclosure

  • 2026-10-05 — Atlassian publishes an out-of-band security advisory for CVE-2026-21589 (CVSS 4.0 9.3) and ships fixed releases for all eight products.
  • 2026-10-06 — Public technical analysis is released by watchTowr, including the root-cause breakdown and a detection artifact generator; Help Net Security and other outlets report the advisory.
  • Shortly after 2026-10-06 — Security vendors report exploitation attempts against Atlassian Data Center instances in the wild.
  • 2026-10-13 — No CISA KEV listing; Atlassian has not confirmed any successful Data Center compromise and advises customers to check for signs of it.

📚 Resources and References

🤝 SEKurity Supports You

There is a recurring shape to these posts: the system that everything else trusts turns out to be the least examined one in the building. A VPN concentrator, a NAC platform, and now the wiki, the issue tracker and the Git host. Nobody schedules a penetration test against Confluence, because Confluence is “just the wiki” — right up until the moment it becomes the directory an attacker reads your Crowd password out of.

The questions for your Atlassian estate are short and uncomfortable. Which of the eight products do you actually run, and at what version — every node, not the one someone remembers? Which of them are reachable from the internet, or from a user VLAN, without a VPN in front? Is Crowd IP-allowlisted, or can anyone who finds a leaked application password call its REST API? And if the access log showed a /download/resources/ request with :: in it last week, would anyone have noticed?

We test these systems from the network position an attacker would really have — from the inside, against the appliance nobody wants taken offline for a test window — and we treat the identity plane as the prize it is. If your Confluence or Jira has never been looked at from an untrusted segment, that is the gap worth closing before the next out-of-band advisory arrives.

Our Services

  • Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
  • Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
  • Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.


Contact:

Website: www.sekurity.de

Inquiries: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH


Your SEKurity Team — Your Trusted Adversaries

The security of your collaboration and identity infrastructure is our drive.


Sources

About the Author

SEKurity Team

Offensive Security Experts

The SEKurity GmbH team consists of experienced penetration testers, security researchers, and cybersecurity consultants. Under the motto 'Your Trusted Adversaries', we support organizations in evaluating their IT security from an attacker's perspective and improving it.

Related Articles