Atlassian CVE-2026-21589: Jira and Confluence Flaw Exploited

Last updated: 26 October 2026. Sources are listed at the end.

A critical Atlassian vulnerability, CVE-2026-21589, lets attackers read files from self-hosted Jira, Confluence, Bitbucket and five other products without logging in. Atlassian published its advisory on 5 October 2026 and rated the flaw 9.3 (Critical). Within two days, a public proof of concept was out and attacks had started.

The flaw affects Data Center and older Server installations that you run yourself. Atlassian Cloud has already been patched, so Cloud customers do not need to do anything. On 15 October 2026, the US agency CISA added the bug to its Known Exploited Vulnerabilities (KEV) list.

Does your team run Jira or Confluence on its own server? Then this post explains what to patch, how to check your version and how to search your logs.

The short answer

• Upgrade every affected Atlassian product to a fixed version (table below). Start with anything reachable from the internet.
• If you cannot patch today, take the instance off the public internet. Then apply one of Atlassian’s temporary mitigations.
• Search your access logs from 5 October onwards for requests containing .. next to ::, / or \.
• If you run Jira with Crowd, treat the Crowd application password as exposed if your logs show hits. Rotate it.
• Cloud users: no action is needed, according to Atlassian.

What is the Atlassian vulnerability?

In plain terms, it is a path traversal bug. Atlassian products share a library called atlassian-plugins-webresource, which serves CSS, JavaScript and images for plugins. According to watchTowr Labs, this library swaps / for :: when it builds resource URLs. Later, it swaps it back. As a result, a request containing ..::..:: turns into ../../ inside the server. The attacker can then climb out of a plugin folder and read other files in the web application.

There are real limits, however. Atlassian says the attacker must already know the exact file name and path, because the bug cannot list directories. watchTowr also found that reads stay inside the Tomcat web application folder. So this is not a “read any file on the disk” bug.

That said, the web application folder can still hold secrets. For example, Jira setups connected to Crowd keep a file called WEB-INF/classes/crowd.properties. It stores the Crowd application name and password in plain text. With those credentials, watchTowr called the Crowd REST API, created a user and added it to jira-administrators. However, Crowd’s IP allowlisting makes this much harder. The attacker would then need access from an internal host.

Timeline and exploitation status

Here is what is confirmed, with dates:

• 5 October 2026: Atlassian publishes the advisory and fixed versions. It says it found no exploitation of Cloud.
• 6 October 2026: watchTowr Labs publishes a technical write-up, a public proof of concept and a free checking tool on GitHub.
• 6–7 October 2026: CERT-EU issues advisory 2026-015 and asks organisations to patch internet-facing instances first.
• 7 October 2026: Previdian, a security firm, reports exploitation on its honeypot network about two hours after watchTowr’s post. BleepingComputer and The Hacker News report 15 attempts from three IP addresses. A Nuclei scanning template has also appeared, which makes mass scanning easier.
• 15 October 2026: CISA adds CVE-2026-21589 to the KEV catalogue. Canada’s Cyber Centre also updates its advisory to note active exploitation.

Jake Knott of watchTowr told The Hacker News that most attacks so far fingerprint the product. Then they sweep for common configuration files. He reported no post-compromise activity and no use of stolen credentials at that point. We could not find GreyNoise or Shadowserver data for this CVE, so we have not quoted any scan numbers.

One correction to some early coverage: a weekly roundup listed this bug alongside October Patch Tuesday. In fact, Atlassian released it as an out-of-band advisory on 5 October, a week earlier.

Am I affected?

Atlassian says all versions below the fixed releases are affected by this Atlassian vulnerability, including unsupported ones. Pick the fixed version on your release line, or anything newer.

What about the old Server editions? Canada’s Cyber Centre lists Bamboo, Bitbucket, Confluence and Crowd Server as affected in all versions. Atlassian no longer ships Server releases. So the only fix is to move to a patched Data Center version or to Cloud. Until then, keep any Server instance off the internet.

How to check your version

The quickest way is the admin screen. In Jira, go to Administration, then System, then System info. In Confluence, open General Configuration, then System Information. The version also shows in the page footer.

You can also check from a terminal. These read-only REST endpoints come from Atlassian’s API documentation. Replace the host names with your own:

# Jira Software / Jira Service Management
curl -s https://jira.example.in/rest/api/2/serverInfo | grep -o '"version":"[^"]*"'

# Bitbucket Data Center
curl -s https://bitbucket.example.in/rest/api/1.0/application-properties | grep -o '"version":"[^"]*"'

Compare the result with the table. For example, Jira 10.3.25 is vulnerable, while 10.3.26 is fixed.

watchTowr has also published a Python checker (watchTowr-vs-Atlassian-CVE-2026-21589) for Jira, Confluence and Bitbucket. It sends real test payloads, so run it only against systems you own. Also note that its “probably NOT VULNERABLE” result is a guess, not proof.

How to fix it

1. Back up first. Take a backup of the home directory, the database and the install directory.
2. Upgrade. Atlassian no longer ships binary patches for this. Instead, the fix is in the maintenance releases listed above. Atlassian recommends the fixed LTS version or later.
3. Patch every node. In a cluster, upgrade all nodes. For Bitbucket, also include mirrors and mirror farm nodes.
4. Restart and confirm. Check the new version number in the admin screen.

If you cannot patch today

Atlassian’s first advice is to remove the instance from the internet, even if it needs a login. Then pick one temporary mitigation:

• Option 1, all products: a WAF or reverse-proxy rule using the regex in Atlassian’s advisory. Test that it blocks .. next to /, \ or ::, including URL-encoded forms.
• Option 2, Confluence, Jira, Jira Service Management, Bamboo and Crowd: enable Tomcat’s RewriteValve inside the application <Context> in server.xml. Then place Atlassian’s rewrite.config in the product’s WEB-INF folder (for example confluence/WEB-INF or atlassian-jira/WEB-INF) and restart each node.
• Option 3, Bitbucket only: add Atlassian’s blocking rule at the top of <installation-directory>/app/WEB-INF/urlrewrite.xml, then restart.

Copy the exact regex and config blocks from the Atlassian advisory rather than from blogs. These are stopgaps, not a replacement for upgrading.

How to check if you were already compromised

Atlassian suggests two log checks. First, URL-decode each access-log request line (up to two times). Then look for .. next to /, \ or ::. Alternatively, you can search the raw lines with the regex from the advisory.

Access logs usually sit in the logs folder of the installation directory for Jira and Confluence. Bitbucket keeps its logs under the home directory. Paths vary by setup, so confirm yours. The application log (for example atlassian-confluence.log) is less useful here, because the attack shows up as a web request.

This read-only search covers plain and gzipped logs. We tested it on sample log lines with plain, single-encoded and double-encoded payloads:

# Change the path to your access log folder
find /opt/atlassian/confluence/logs -type f -name '*access*' -print0 |
  xargs -0 zgrep -EiH '(\.\.|%2e%2e|%252e%252e)(::|%3a%3a|%253a%253a)'

The pattern above is our own simpler version, not Atlassian’s regex. It focuses on the ..:: form used in the published exploit. So for full coverage, also run Atlassian’s regex.

Next, check for the three source IPs that Previdian reported and BleepingComputer published:

zgrep -EH '38\.60\.157\.86|146\.70\.187\.234|159\.26\.119\.225' /opt/atlassian/*/logs/*access*

What do the hits mean? A request with a 200 status that names a file such as WEB-INF/web.xml or crowd.properties suggests the read worked. A 404 or 403 most likely means it failed. Also, a lack of matches is not proof of safety if your logs do not go back to early October.

Clean-up if you find hits

• Isolate the instance or restrict access before you change anything else.
• Rotate any secrets stored in the web application folder. In particular, change the Crowd application password if crowd.properties was read.
• In Jira, review recent user accounts and members of jira-administrators. Remove anything you did not create.
• Keep copies of the logs for your investigation.
• Then upgrade to a fixed version.

The India angle

Many Indian IT services firms, startups and GCCs still run self-hosted Jira and Confluence. We could not find a CERT-In advisory for this Atlassian vulnerability when writing. However, CERT-In’s April 2022 Directions require covered entities to report certain incidents within six hours of noticing them. Unauthorised access to IT systems is one of the listed incident types. So if your log check shows a successful read, speak to your legal or compliance team about reporting.

The DPDP Rules also include a breach notice duty under Rule 7. That rule applies from May 2027 and is not yet in force. Even so, it makes sense to document what you found now.

Quick checklist

• ☐ List every self-hosted Atlassian product, including Bamboo, Crowd, Fisheye and Crucible
• ☐ Check each version against the fixed-version table
• ☐ Upgrade all nodes, including Bitbucket mirrors
• ☐ Take unpatched or Server-edition instances off the internet
• ☐ Apply a temporary mitigation if patching must wait
• ☐ Search access logs from 5 October 2026 for ..:: patterns and the three reported IPs
• ☐ Rotate the Crowd application password if crowd.properties may have been read
• ☐ Review new Jira admin accounts and group changes
• ☐ Decide whether the CERT-In six-hour rule applies to you

If you want a second pair of eyes on an exposed Jira or Confluence server, our VAPT services team can test it and review your logs. For the Linux host underneath, see our Linux server hardening checklist. We also covered another October bug that saw attacks soon after details went public: the Arista VeloCloud Orchestrator flaw.

Sources

• Atlassian security advisory: CVE-2026-21589 Arbitrary File Access Vulnerability
• CERT-EU Security Advisory 2026-015
• watchTowr Labs technical analysis of CVE-2026-21589
• watchTowr detection tool on GitHub
• BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release
• The Hacker News: Atlassian Data Center flaw draws exploitation attempts within two hours
• Rapid7: CVE-2026-21589 analysis and KEV update
• Canadian Centre for Cyber Security advisory AV26-1002

Running Linux servers in production? Our Linux server hardening & security audit checks configuration, patching, SSH and logging. You can also use our free Linux server hardening checklist, or contact us.