plaincve:~$

// threat brief

CVE-2026-21589Actively exploited

Atlassian Data Center arbitrary file access: attackers can read specific files in the web app folder without logging in

CVSS
9.3 CRITICAL
CISA KEV
2026-10-15
Weakness
CWE-552
Topics
Web apps

PlainCVE Team · Published 2026-10-20 · AI-assisted · Press brief ↓

AI review 2026-10-20 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

Several Atlassian Data Center products let unauthenticated attackers read specific files in the web app folder. Listed in CISA KEV.

Who is affectedOrganizations self-hosting Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo or Crowd Data Center, or Crucible or Fisheye, on versions below each product's fixed release. Atlassian Cloud is already patched, and Bitbucket Cloud is not affected.
What happensIf attackers know a file's exact name and path, they can read it from inside the web application root directory, though they cannot list directory contents. Some configurations may hold sensitive files there; researchers showed that in a Crowd setup with Jira configured, this exposed application credentials; where Crowd was reachable and the application had sufficient permissions, they used them to create a Jira administrator.
What to do nowUpgrade every installation to a fixed or the latest version. If you can't yet, take the instance off the internet if possible, or apply Atlassian's temporary mitigations such as a WAF or proxy rule.
Affected versionsAtlassian's advisory and tickets: all versions before each product's fixed release (All versions are affected); versions past End of Life may also be affected. The CVE record Atlassian filed as CNA lists starting versions (e.g. Bitbucket >= 4.6.0, Confluence >= 5.10.0, Jira Software >= 7.1.0). The two first-party sources differ, so this page lists both; detection should cover the union (all older versions).
Fixed versionsBitbucket 9.4.26 / 10.2.8 / 10.5.1; Confluence 9.2.26 / 10.2.19; Jira Software 9.12.40 / 10.3.26 / 11.3.12; JSM 5.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 (GitHub says 7.1.1) / 7.2.4; Crucible and Fisheye 4.9.15
CVSS vector
Show full vectorCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H
Timeline
  • First public 2026-10-05
CISA KEVListed (2026-10-15): attacks have been seen in the wild

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Compare your version against the fixed releases

    Check each product's version in its admin interface and compare it with the fixed-version table on this page. All older Data Center, Crucible and Fisheye versions are affected, and End of Life versions may be too. Atlassian Cloud has been patched by the vendor and needs no action.

  2. 02Search access logs for traversal patterns

    Per Atlassian's advisory: URL-decode each access-log request line up to twice, then look for ".." right next to /, \ or :: (the advisory also gives a regex for searching raw, undecoded lines, which you can use instead). Where to run it: on the host running the affected product (or the host where its access logs are collected), replacing /path/to/product/logs at the end with the directory holding that product's access logs (the location depends on your installation; the advisory does not specify it). This is PlainCVE's command: it only reads, changes no files and connects to no other host; it searches every subfolder recursively for log files whose names contain "access", including date-rotated and .gz files, replaces undecodable bytes instead of stopping, and prints the file name plus each matching line. A security vendor's report (that page contains attack code, so PlainCVE does not link it) notes a matching request is an attempt, not proof of success, and does not show which file was returned.

    Read-only check
    python3 -c 'import sys,os,re,gzip,urllib.parse as u; p=re.compile(r"\.\.(/|\\|::)|(/|\\|::)\.\."); [sys.stdout.write(os.path.join(d,f)+"\t"+l) for d,_,fs in os.walk(sys.argv[1]) for f in fs if "access" in f for l in (gzip.open if f.endswith(".gz") else open)(os.path.join(d,f),"rt",errors="replace") if p.search(u.unquote(u.unquote(l)))]' /path/to/product/logs
    Step 1Step 2Step 3
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Upgrade to a fixed or the latest version

    The vendor recommends patching every affected installation. For End of Life versions, it recommends upgrading to a fixed LTS version or later.

    Step 2Step 3
  2. 02Can't upgrade yet: take it off the internet

    The vendor advises removing the instance from the internet until you can patch or apply mitigations, if possible.

    Step 1
  3. 03Apply the vendor's temporary blocking rules

    Pick one: a WAF/proxy regex rule (all products), Tomcat RewriteValve (Confluence, JSM, Jira, Bamboo, Crowd), or a urlrewrite.xml rule (Bitbucket only). The vendor stresses these are limited and no replacement for patching. Take the exact rules from the official advisory.

    Step 3
RESPONDRespondIf you find signs of compromise
  1. 01Rotate application credentials that may have leaked

    If logs show suspicious requests, especially in a Crowd setup with Jira, rotate the application credentials in Crowd's configuration. This is a precautionary PlainCVE suggestion; according to a news report (that page contains attack code, so PlainCVE does not link it), watchTowr says no use of stolen credentials has been observed so far.

    Step 4
  2. 02Review jira-administrators membership

    The takeover researchers demonstrated adds a user to jira-administrators. Check for unfamiliar new accounts (PlainCVE suggestion).

    Step 5
HARDENHardenPrevent the next one
  1. 01Turn on Crowd IP allowlisting

    Researchers note this can block the direct route from stolen credentials to a new administrator.

    Step 5
  2. 02Don't expose Data Center products directly to the internet

    This flaw needs no login, only network access to the instance (plus knowledge of the exact file path); keeping it behind a VPN or internal network shrinks exposure (PlainCVE suggestion).

    Step 1
  3. 03Don't stay on End of Life versions

    The vendor says End of Life versions may also be affected and recommends a fixed LTS version or later.

Full remediation steps and notes
  1. Upgrade first. Pick the fixed version on the same branch as your current version from the table above; for End of Life versions, the vendor recommends a fixed LTS version or later.
  2. Limits of the temporary mitigations. The vendor offers three rule options (WAF/proxy, Tomcat RewriteValve, Bitbucket-only urlrewrite.xml) but says plainly they are limited and no replacement for patching. Copy the rules from the official advisory rather than writing your own.
  3. For Crowd, go by the vendor ticket. Atlassian’s ticket lists 7.1.7 while GitHub’s unreviewed advisory says 7.1.1; on the 7.1.x branch, 7.1.7 or later satisfies both.
  4. When reading logs. A matching request only shows someone tried (a security vendor’s report; that page contains attack code, so PlainCVE does not link it); judge it together with the response status and any later account changes.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

Atlassian Data Center arbitrary file access: attackers can read specific files in the web app folder without logging in: 1. Sends a crafted request to a reachable Data Center instance → 2. Shared web-resource code turns "::" into a path separator → 3. The server returns the named file from the web app folder → 4. In a Crowd setup with Jira, reads application credentials → 5. Uses the credentials to create a Jira administratorCVE-2026-21589 · Atlassian Data Center arbitrary file access: attackers can read specific files in the webapp folder without logging inAttackerYour systemSends a crafted request to a reachable Data Center instance — No account or login is needed, only network access to an affected instance. 1Sends a craftedrequest to areachable DataCenter instanceShared web-resource code turns "::" into a path separator — watchTowr's analysis (as reported by Rapid7) traced the flaw to path handling in Atlassian's shared web-resource code, where "::" sequences can become path separators during processing. 2Sharedweb-resource codeturns "::" into apath separatorThe server returns the named file from the web app folder — The attacker must already know the file's exact name and path and cannot list directories. Researchers could not reach files outside the Tomcat application context. 3The server returnsthe named filefrom the web appfolderIn a Crowd setup with Jira, reads application credentials — watchTowr reports (as relayed by Rapid7) that reading Crowd's crowd.properties configuration file exposed application credentials. This only applies in certain setups. 4In a Crowd setupwith Jira, readsapplicationcredentialsUses the credentials to create a Jira administrator — Where Crowd was reachable and the application had sufficient permissions, researchers created a user and added it to jira-administrators. 5Uses thecredentials tocreate a JiraadministratorAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-21589-atlassian-data-center-file-read · CC BY 4.0
Atlassian Data Center arbitrary file access: attackers can read specific files in the web app folder without logging in: 1. Sends a crafted request to a reachable Data Center instance → 2. Shared web-resource code turns "::" into a path separator → 3. The server returns the named file from the web app folder → 4. In a Crowd setup with Jira, reads application credentials → 5. Uses the credentials to create a Jira administratorCVE-2026-21589 · Atlassian Data Centerarbitrary file access: attackers canread specific files in the web appfolder without logging inSends a crafted request to a reachable Data Center instance — No account or login is needed, only network access to an affected instance. 1AttackerSends a crafted request to areachable Data Center instanceShared web-resource code turns "::" into a path separator — watchTowr's analysis (as reported by Rapid7) traced the flaw to path handling in Atlassian's shared web-resource code, where "::" sequences can become path separators during processing. 2Your systemShared web-resource code turns"::" into a path separatorThe server returns the named file from the web app folder — The attacker must already know the file's exact name and path and cannot list directories. Researchers could not reach files outside the Tomcat application context. 3Your systemThe server returns the namedfile from the web app folderIn a Crowd setup with Jira, reads application credentials — watchTowr reports (as relayed by Rapid7) that reading Crowd's crowd.properties configuration file exposed application credentials. This only applies in certain setups. 4AttackerIn a Crowd setup with Jira,reads application credentialsUses the credentials to create a Jira administrator — Where Crowd was reachable and the application had sufficient permissions, researchers created a user and added it to jira-administrators. 5AttackerUses the credentials to createa Jira administratorAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-21589-atlassian-data-center-file-read
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    Sends a crafted request to a reachable Data Center instance

    No account or login is needed, only network access to an affected instance.

    Defense: Until patched, take the instance off the internet if possible (vendor advice).

  2. Your system

    Shared web-resource code turns "::" into a path separator

    watchTowr's analysis (as reported by Rapid7) traced the flaw to path handling in Atlassian's shared web-resource code, where "::" sequences can become path separators during processing.

    Defense: Upgrade to a fixed version; a security vendor's report (that page contains attack code, so PlainCVE does not link it) says the fix is in atlassian-plugins-webresource 6.0.8, shipped in the fixed releases.

  3. Your system

    The server returns the named file from the web app folder

    The attacker must already know the file's exact name and path and cannot list directories. Researchers could not reach files outside the Tomcat application context.

    Defense: Temporary mitigations: a WAF/proxy regex rule (all products), Tomcat RewriteValve (Confluence, JSM, Jira, Bamboo, Crowd) or a urlrewrite.xml rule (Bitbucket only).

  4. Attacker

    In a Crowd setup with Jira, reads application credentials

    watchTowr reports (as relayed by Rapid7) that reading Crowd's crowd.properties configuration file exposed application credentials. This only applies in certain setups.

    Defense: Patch; if you suspect the file was read, rotate those credentials (PlainCVE suggestion).

  5. Attacker

    Uses the credentials to create a Jira administrator

    Where Crowd was reachable and the application had sufficient permissions, researchers created a user and added it to jira-administrators.

    Defense: Researchers note Crowd's IP allowlisting can block this direct route.

Who is affected

ProductFixed versionsFirst affected version (CVE record, filed by Atlassian as CNA; the advisory says all versions)
Bitbucket Data Center9.4.26, 10.2.8, 10.5.14.6.0
Confluence Data Center9.2.26, 10.2.195.10.0
Jira Software Data Center9.12.40, 10.3.26, 11.3.127.1.0
Jira Service Management Data Center5.12.40, 10.3.26, 11.3.123.1.0
Bamboo Data Center10.2.24, 12.1.127.0.1
Crowd Data Center6.3.7, 7.0.3, 7.1.7 (GitHub says 7.1.1), 7.2.42.11.0
Crucible4.9.15Not listed
Fisheye4.9.15Not listed
Atlassian Cloud productsPatched by the vendor; no action needed—
Bitbucket CloudNot affected—

Two first-party sources from the same vendor differ, so this page lists both: Atlassian’s security advisory and product tickets say “All versions are affected” and give no starting version. The CVE record Atlassian filed as CNA lists the starting versions in the right-hand column (e.g. Bitbucket >= 4.6.0), while the same record’s affected field also says “All other versions affected”. NVD’s CPE ranges largely follow it but differ in detail (e.g. NVD’s Bitbucket Data Center CPE starts at 7.17.0, while 4.6.0 through 8.14.6 are listed under the bitbucket_server CPE). GitHub’s unreviewed advisory repeats the CVE record’s numbers. This page does not pick a side: detection and upgrades should cover the union, i.e. all versions before the fixed releases. Versions past End of Life may also be affected.

CVE record status: PlainCVE’s snapshot at research time (2026-10-18) showed the CVE record and NVD as rejected since 2026-10-16 (reason: publication “may have been a false positive or a mistake”). When re-read on 2026-10-20, the CVE record’s state was PUBLISHED (updated 2026-10-19) with no rejection data, and NVD showed Analyzed. No source explains the rejection or the restoration. Either way, go by the fixes.

How it works

Atlassian’s advisory says only that an unauthenticated attacker can read specific files inside the web application root directory. The attacker must already know the file’s exact name and path; the flaw does not let anyone list directory contents. The vendor also warns that in some configurations sensitive files may be present that raise the risk.

watchTowr’s analysis (as reported by Rapid7) traced the flaw to the “web-resource” code that the products share: during request processing, double-colon (”::”) sequences can become path separators, letting a request step outside the folder it should be limited to. A security vendor’s report (that page contains attack code, so PlainCVE does not link it) says the fix is in the shared library atlassian-plugins-webresource 6.0.8. CISA classifies the weakness as CWE-552 (files or directories accessible to external parties).

The flawed approach (conceptual illustration, not the original source code):

Show code example(python)
def serve_resource(name):
    # Checks for ".." first, then turns :: into /
    if ".." in name.split("/"):
        reject()
    path = name.replace("::", "/")   # path segments created by the conversion are never re-checked
    return read_file(WEBAPP_ROOT / path)

The fixed approach:

Show code example(python)
def serve_resource(name):
    path = (RESOURCE_DIR / name.replace("::", "/")).resolve()
    # After every conversion, confirm the final path is still inside the allowed folder
    if not path.is_relative_to(RESOURCE_DIR):
        reject()
    return read_file(path)

What researchers could confirm: watchTowr confirmed file reads on Jira, Confluence and Bitbucket, but could not reach files outside the Tomcat application context. Rapid7, relaying watchTowr’s findings, reports that in a Crowd deployment with Jira configured, reading crowd.properties exposed application credentials; where Crowd was reachable and the application had sufficient permissions, researchers used them to create a Jira administrator. Crowd’s IP allowlisting can block that route. No source says this flaw allows remote code execution.

Timeline

DateEvent
2026-10-02Tickets for Jira, JSM, Confluence, Bitbucket and Crowd are created on 10-02 (Bamboo, Crucible and Fisheye on 10-03); some had a rewrite.config attached the same day (Bamboo’s rewrite.config was attached on 10-06; Crucible and Fisheye have none). The tickets’ current content matches the advisory summary, but whether they were public when created and what they said then cannot be confirmed from the sources, so first disclosure stays at 10-05, the advisory and CVE record date
2026-10-05Atlassian publishes its advisory and fixes for every product; the advisory says Cloud products are patched and its investigation found no evidence of exploitation of them, while for self-managed instances Atlassian cannot confirm whether they have been affected
2026-10-06watchTowr publishes its analysis with proof-of-concept code; according to news reports, Previdian says its honeypots recorded exploitation attempts within hours (SecurityWeek says October 6, while another news report [that page contains attack code, so PlainCVE does not link it] dated October 7 says “earlier today”; the date is reported inconsistently)
2026-10-15CISA adds it to the Known Exploited Vulnerabilities catalog
2026-10-16The CVE record and NVD are marked rejected (per the 10-18 snapshot)
2026-10-18CISA’s patch deadline for federal agencies
2026-10-19The CVE record is updated to PUBLISHED (confirmed when read on 2026-10-20); NVD shows Analyzed

Further reading

  • Scoring differences: Atlassian’s (the CNA’s) own CVSS 4.0 score is 9.3 (Critical), with its vector rating the impact on downstream systems (SC/SI/SA) as high; NVD lists it as Secondary. NVD’s own score is CVSS 3.1 7.5 (High; AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, Primary), counting only confidentiality impact. This page uses Atlassian’s 9.3 in its severity field because it is the vendor’s assessment and matches the advisory; NVD’s 7.5 is shown alongside.
  • How far exploitation has gone: It is listed in CISA KEV; according to a news report (that page contains attack code, so PlainCVE does not link it), watchTowr says it is seeing active exploitation but no post-compromise activity or use of stolen credentials so far; a security vendor’s report (that page contains attack code, so PlainCVE does not link it) cannot confirm any attempt succeeded. CISA lists ransomware use as “Unknown”.
  • Zero-day? No source says so. The earliest reported attempts (October 6 or 7; reports differ) came after the fixes and advisory (October 5); this is PlainCVE’s analysis.
  • Who found it: watchTowr says Atlassian found and disclosed it itself; Atlassian does not say.
  • Related weakness type: CWE-552.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-20 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. AdvisoryCVE-2026-21589 - Arbitrary File Access Vulnerability impacts Multiple Products · Atlassian, 2026-10-05 · accessed 2026-10-18
  2. CVE / NVD / OSVCVE-2026-21589 CVE record · CVE Program, 2026-10-19 · accessed 2026-10-20
  3. CVE / NVD / OSVNVD - CVE-2026-21589 · NIST · accessed 2026-10-20
  4. OtherGitHub Advisory Database entry for CVE-2026-21589 (unreviewed) · GitHub · accessed 2026-10-18
  5. AdvisoryCISA KEV snapshot for CVE-2026-21589 · CISA (PlainCVE snapshot), 2026-10-15 · accessed 2026-10-18
  6. VendorBSERV-20604 (Bitbucket Data Center) · Atlassian · accessed 2026-10-18
  7. VendorCONFSERVER-104488 (Confluence Data Center) · Atlassian · accessed 2026-10-18
  8. VendorJRASERVER-79546 (Jira Software Data Center) · Atlassian · accessed 2026-10-18
  9. VendorJSDSERVER-16809 (Jira Service Management Data Center) · Atlassian · accessed 2026-10-18
  10. VendorBAM-26567 (Bamboo Data Center) · Atlassian · accessed 2026-10-18
  11. VendorCWD-6610 (Crowd Data Center) · Atlassian · accessed 2026-10-18
  12. VendorCRUC-8741 (Crucible) · Atlassian · accessed 2026-10-18
  13. VendorFE-7583 (Fisheye) · Atlassian · accessed 2026-10-18
  14. ResearchETR: CVE-2026-21589 critical unauthenticated arbitrary file access in Atlassian products · Rapid7 · accessed 2026-10-18
  15. ResearchAtlassian Jira/Confluence arbitrary file read (CVE-2026-21589) · watchTowr · accessed 2026-10-18
  16. NewsAtlassian warns of critical file access flaw in Jira, Confluence · BleepingComputer · accessed 2026-10-18
  17. NewsAttackers target critical Atlassian vulnerability within hours of PoC publication · SecurityWeek · accessed 2026-10-18

Press brief

In one sentence

On October 5, 2026, Atlassian disclosed a flaw in eight self-hosted products (six Data Center products plus Crucible and Fisheye), including Jira, Confluence and Bitbucket, that lets unauthenticated attackers read specific files inside the web application folder, and released fixes the same day. Research firm watchTowr published an analysis with proof-of-concept code the next day; according to news reports, security firm Previdian said it saw exploitation attempts within hours. The US agency CISA added it to its Known Exploited Vulnerabilities catalog on October 15. Separately, the CVE record was marked rejected on October 16 (per PlainCVE's October 18 snapshot) but was back to PUBLISHED by October 19.

Key facts

Severity
CVSS 4.0 9.3 (Atlassian as CNA; listed as Secondary in NVD; the score this page uses); NVD 7.5 (CVSS 3.1, Primary) services.nvd.nist.gov
Advisory and fixes
2026-10-05 confluence.atlassian.com
Added to CISA KEV
2026-10-15 (federal deadline 10-18) cisa.gov
CVE record status
Currently PUBLISHED (updated 2026-10-19); had been marked rejected on 2026-10-16, and the 10-18 snapshot still showed that cveawg.mitre.org
Proof of concept published
2026-10-06 (watchTowr) securityweek.com

Confirmed

  • Atlassian confirms eight self-hosted products (six Data Center products plus Crucible and Fisheye) are affected, letting unauthenticated attackers read specific files in the web application root, and has released fixes.
  • CISA added it to the Known Exploited Vulnerabilities catalog on 2026-10-15.

Unconfirmed / disputed

  • According to news reports, Previdian says its honeypots recorded exploitation attempts within hours of watchTowr publishing technical details; the date is reported inconsistently (SecurityWeek says October 6, while another news report (that page contains attack code, so PlainCVE does not link it) dated October 7 says "earlier today"). PlainCVE could not obtain Previdian's own public material.
  • According to a news report (that page contains attack code, so PlainCVE does not link it), watchTowr says it is seeing active exploitation but no post-compromise activity or use of stolen credentials so far.
  • PlainCVE's snapshot from 2026-10-18 showed the CVE record as rejected (reason: possible false positive or mistake); when re-read on 2026-10-20, the CVE record was PUBLISHED and NVD was Analyzed. No source explains the rejection or the restoration.
  • For one Crowd fixed version, Atlassian's ticket says 7.1.7 while GitHub's unreviewed advisory says 7.1.1.
  • A security vendor's report (that page contains attack code, so PlainCVE does not link it) says it cannot confirm any observed attempt succeeded.
  • No source says this flaw allows remote code execution.

Quotable line

This flaw doesn't show an intruder what's in the room, but anyone who knows which drawer to open can walk off with what's inside.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "Atlassian Data Center arbitrary file access: attackers can read specific files in the web app folder without logging in". PlainCVE. https://plaincve.date/en/vulns/cve-2026-21589-atlassian-data-center-file-read (accessed YYYY-MM-DD)
BibTeX
@misc{cve202621589atlassiandatacenterfileread2026,
  title  = {Atlassian Data Center arbitrary file access: attackers can read specific files in the web app folder without logging in},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-21589-atlassian-data-center-file-read},
  note   = {Updated 2026-10-20}
}