← All resources

Atlassian 9.3 flaw: self-hosted Jira and Confluence (05/10/2026)

Published October 8, 2026 · 7 min read · CyberNovaLabs.io

Scored 9.3 out of 10, no credentials needed, eight products running on your own servers: the Atlassian advisory of 5 October, repeated by CERT-EU on 7 October, calls for an immediate upgrade of internet-facing instances.

In short

On 5 October 2026 Atlassian published a security advisory for CVE-2026-21589, scored 9.3 out of 10, affecting eight of its products that run on your own servers[1]. An attacker with no account at all can read files inside the web application root directory: they need the exact name and path of the file, but no username and no password[1]. On 7 October 2026 CERT-EU repeated the alert and asked organisations to upgrade every affected installation as soon as possible, starting with the instances reachable from the internet[2].

The Atlassian CVE-2026-21589 flaw reaches small companies too

The words "Data Center" in the product names are misleading. They say nothing about the size of your company: that is simply the name of Atlassian's self-hosted range, the one that replaced the old Server range. A team of ten tracking tickets in Jira on a rented server, an engineering office keeping its documentation in Confluence, an IT provider hosting one Bitbucket for several clients — all three are inside the scope of this advisory.

Eight products are listed: Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible and Fisheye[1]. The Cloud versions were patched by Atlassian and require no action from their customers[2]. The working rule fits in one sentence: if you log in on an atlassian.net address, there is nothing for you to do; if the address is your own, there is a patch to install.

What the flaw allows, and what it does not

Reading the advisory avoids two symmetrical mistakes, panic and a shrug. On severity: the access needs no authentication at all, and the 9.3 score reflects easy exploitation with a broad effect[1]. On limits: the attacker cannot list directory contents or walk the file tree; they have to aim at a file whose name and path they already know[1].

That limit is less reassuring than it sounds. Jira, Confluence and Bitbucket ship in tens of thousands of copies: their default installation paths, the names of their configuration files and the location of their logs are public, documented by the vendor itself. An attacker does not need to explore, they need a list, and that list already exists. So the real risk is not "they will read everything", it is "they will read exactly the files that hold secrets".

That is also why installing the patch does not close the case. If a configuration file could be read, treat the credentials inside it as known: database password, integration token, connector key. Upgrading prevents the next read; it does not undo the ones that already happened.

The versions that fix it

Atlassian published one fix per product. Any version earlier than those in the table is affected[1].

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
Crucible and Fisheye4.9.15

If the upgrade cannot happen right away, CERT-EU points to two routes: take the instance off public access, or apply one of the three temporary measures published by the vendor, which work through a web application firewall rule, a Tomcat configuration change or URL rewriting[2]. Those buy time; they are not fixes.

Could personal data be read? The answer differs by country

A Jira Service Management instance holds your customers' requests, their names, their addresses. A Confluence instance holds meeting notes and sometimes HR files. If you find that such an instance was reached and that personal data could have been read, the matter stops being purely technical: the European regulation requires notifying the breach to the supervisory authority within 72 hours of becoming aware of it[4].

Which authority depends on where you are established: the CNIL in France, the Data Protection Authority (APD/GBA) in Belgium, the Autoriteit Persoonsgegevens in the Netherlands, the Commission nationale pour la protection des données (CNPD) in Luxembourg. If your company is also an entity in scope of NIS2 in its own country, a second reporting channel applies, with its own single point of contact and its own deadlines; we set out the scope country by country on our page about NIS2 in the Netherlands.

Finally, if your IT provider hosts the instance, they are your processor under the regulation: it is their job to report the incident to you, and yours to ask them in writing. We went into that in our article on a data breach at a supplier and the 72-hour deadline.

The same pattern, for the third time in two weeks

In a fortnight, three edge services drew the same kind of advisory: two NetScaler flaws exploited before the patch shipped, then a FortiMail flaw on the mail gateway, and now the Atlassian suite. The common factor is not the vendor, it is the position: these are all services published on the internet so that teams can reach them from outside.

The practical consequence is an inventory, not a purchase. A company that knows within a minute which services it exposes, in which version and under whose responsibility, installs a patch within half a day. A company that does not discovers its own estate during the incident, and pays for that discovery twice.

To do this week

  • List your self-hosted Atlassian instances: Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible, Fisheye. An atlassian.net address is not affected[2].
  • Record the exact version of each one and compare it with the table above.
  • Upgrade first what is reachable from the internet, as CERT-EU asks[2].
  • If the upgrade has to wait: take the instance off public access, or apply one of the vendor's temporary measures[2].
  • After patching: rotate the passwords and tokens stored in those instances' configuration files.
  • Ask your host or provider in writing for the date of their upgrade and the result of their log review.
  • If personal data could have been read: open your breach register and hold the 72-hour deadline towards your authority[4].

At CyberNovaLabs.io

We work with small and mid-sized companies in the Netherlands, Belgium, France and Luxembourg, and every alert replays the same scene: nobody knows for certain which services are exposed, or who is supposed to patch them. So our cybersecurity work starts with that inventory — published services, versions, owner, notification procedure — before building the habit of upgrading when an advisory like this one lands. To find out within an hour where you stand on these eight products, book a call with us. Our work is quoted per engagement, with no minimum term.

Sources

  1. Atlassian — CVE-2026-21589: Arbitrary File Access Vulnerability Impacts Multiple Products (publie le 05/10/2026)
  2. CERT-EU — Security Advisory 2026-015, Critical Vulnerability in Multiple Atlassian Products (publie le 07/10/2026)
  3. Help Net Security — Atlassian urges immediate patching of critical Data Center file access vulnerability (publie le 06/10/2026)
  4. Reglement (UE) 2016/679 (RGPD), article 33 — notification d'une violation a l'autorite de controle
CyberNovaLabs.io

Qualified meetings, no lock-in.

Criteria in writing before launch, pay per meeting or monthly, stop with a simple email.

→ Get meetings booked

Read next

Newsletter · CyberNovaLabs.io

Security Briefing

One email a month: a figure from our barometer, the NIS2 and CRA dates that matter in the Netherlands, Belgium and Luxembourg, and one practical guide. In English. Unsubscribe in one click.

→ Get meetings booked