Attackers are exploiting critical CVE-2026-21589 in Jira and Confluence Data Center

Since 7 October, attackers have been trying to exploit CVE-2026-21589, a critical flaw that lets anyone read files without authentication in eight self-hosted Atlassian Data Center products, including Jira, Confluence and Bitbucket. If you use Atlassian Cloud, you don't need to do anything. If your company or a provider hosts it, patch today or take the instance off the internet.

Key facts

• CVE-2026-21589 has a CVSS score of 9.3. It is a path traversal flaw that lets an unauthenticated attacker read specific files from the web application's root directory (The Hacker News).
• Atlassian released patches on 5 October. All versions before the fixed ones are affected, including end-of-life releases (SecurityWeek).
• On 7 October, Previdian logged 15 exploitation attempts from 3 IPs in Japan and the US, 2 hours after watchTowr published technical details and a proof of concept (The Hacker News).
• A Nuclei template for automated scanning is already available.
• Spain's INCIBE-CERT published a critical-severity advisory on 6 October titled Arbitrary file access in Atlassian products (INCIBE-CERT).

Am I affected if I use Jira or Confluence?

It depends on where they are hosted. If you use Atlassian Cloud, no: cloud products are already patched and Bitbucket Cloud is not affected.

You are affected if your company, or your IT provider, hosts any of these products in their Data Center edition: Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible or Fisheye. If you don't know which applies to you, ask whoever runs your IT today.

What can an attacker do with this flaw?

Read files on the server without a username or password. There is a limit: they need to know the exact file name and path, because the flaw does not allow directory listing. The problem is that in some configurations those files are sensitive.

watchTowr describes the worst case. In deployments with Crowd, an attacker can read crowd.properties, which contains Crowd credentials. With them, they get admin access, create users and escalate privileges, for example to Jira administrator (BleepingComputer).

So far, almost all attempts aim to fingerprint the product and probe for configuration files. watchTowr has not seen post-compromise activity or use of stolen credentials. Mind the timeline: early reports, such as SecurityWeek's, said there was no evidence of exploitation. Later updates confirm it.

Which version should I update to?

• Bitbucket DC: 9.4.26, 10.2.8 or 10.5.1
• Confluence DC: 9.2.26 or 10.2.19
• Jira Software DC: 9.12.40, 10.3.26 or 11.3.12
• Jira Service Management DC: 5.12.40, 10.3.26 or 11.3.12
• Bamboo DC: 10.2.24 or 12.1.12
• Crowd DC: 6.3.7, 7.0.3, 7.1.7 or 7.2.4
• Crucible and Fisheye: 4.9.15

If your version is out of support, it is affected too.

What to do today

1. Check whether you run any self-hosted Atlassian product. If you don't know, ask your IT provider.
2. Update to the fixed version for your release line.
3. If you can't update this week, take the instance off the internet and make it reachable only via VPN, or add a WAF or proxy rule that blocks traversal patterns (.. combined with /, \ or ::). Atlassian also provides Tomcat RewriteValve rules for Confluence, Jira, JSM, Bamboo and Crowd, and a urlrewrite.xml rule for Bitbucket. Apply them on every cluster node, including Bitbucket mirrors.
4. Review access logs for requests with .. or :: in the URL.
5. If there are signs of access, or the instance was exposed and unpatched, rotate credentials and tokens (starting with those in crowd.properties) and check for new admin accounts.
6. If the system processes personal data and you suspect a compromise, check with your DPO whether GDPR notification obligations apply.

What it means for a small business

Two hours. That's the gap between the proof of concept going public and the first attacks. Your patching window is set by whoever publishes the technical details, not by the maintenance slot your provider books. With a Nuclei template in circulation, any exposed instance ends up in automated scans.

Another detail is worth reading twice: Atlassian says it cannot determine whether each customer's instances have been compromised. That check is on you, or on whoever manages your server. If nobody in your company can say who patches Jira, that is the underlying problem, more than this particular CVE.

Our view: a self-hosted Jira or Confluence doesn't need to be open to the internet for your team to work. Putting it behind a VPN takes you off the list of easy targets for the next flaw like this one. And if running your own servers adds nothing to your business, it's worth asking whether it still makes sense. If you want someone to review your exposure with you, our cybersecurity service can help.

FAQ

Do I need to do anything if I use Atlassian Cloud?

No. Cloud products are already patched and Bitbucket Cloud is not affected.

Is the WAF or proxy rule enough?

It is a temporary mitigation. It must be on every cluster node, including Bitbucket mirrors. The fix is updating to the patched version.

Have credentials already been stolen through this flaw?

watchTowr has not seen post-compromise activity or use of stolen credentials. But Atlassian can't tell whether your specific instance is compromised, so check your logs.

Sources

• The Hacker News – Atlassian Data Center Flaw Draws Exploitation Attempts Within Two Hours of Public Details
• BleepingComputer – Hackers exploit critical Atlassian flaw after public PoC release
• The Hacker News – Critical Atlassian Flaw Lets Unauthenticated Attackers Read Known Files Across 8 Products
• SecurityWeek – Atlassian Patches Critical Vulnerability Affecting 8 Products
• INCIBE-CERT – Avisos