CVE-2026-21589 ist eine kritische Schwachstelle (CVSS 9.3) in acht Atlassian Data Center-Produkten, die einem entfernten, nicht authentifizierten Angreifer ermöglicht, ihm bekannte Dateien im Wurzelverzeichnis der Webanwendung zu lesen, betrifft sowohl unterstützte als auch teilweise veraltete Versionen einschließlich der Server-Editionen; Atlassian hat die Cloud-Services bereits aktualisiert, und Betreibern lokaler Installationen wird empfohlen, entweder umgehend zu aktualisieren oder die Systeme vorübergehend zu isolieren und mit Hilfe von WAF-Regeln sowie den dem Produkt beigefügten URL-Rewrite-Konfigurationen zu schützen.
Technische Details zu CVE-2026-21589
Atlassian beschreibt das Problem als Schwachstelle der Klasse path traversal: Eine speziell aufgebaute Anfrage mit einer Sequenz der Form .. in unmittelbarer Nähe der Zeichen /, \\ oder :: ermöglicht den Zugriff auf Dateien, die im Deployment-Verzeichnis der Webanwendung liegen. Dabei gilt:
- der Angriff ist vollständig remote über das Netzwerk möglich;
- es ist keine Authentifizierung erforderlich;
- der Angreifer muss den genauen Pfad und Dateinamen im Voraus kennen;
- ein Auflisten von Verzeichnisinhalten ist über diese Schwachstelle nicht möglich.
Die offizielle Beschreibung und Empfehlungen sind im Sicherheitshinweis von Atlassian veröffentlicht: CVE-2026-21589: arbitrary file access vulnerability impacts multiple products. Das CVE ist außerdem in der Datenbank des CVE Project erfasst: Eintrag CVE-2026-21589 sowie in der NVD über den Standardlink NVD: CVE-2026-21589.
Nach Angaben von Atlassian sind alle Versionen bis zu den behobenen (in den Tickets und im Sicherheitshinweis genannt) der folgenden Data Center-Produkte betroffen:
- Bitbucket Data Center – siehe Ticket BSERV-20604;
- Confluence Data Center – Ticket CONFSERVER-104488;
- Jira Software Data Center – Ticket JRASERVER-79546;
- Jira Service Management Data Center – Ticket JSDSERVER-16809;
- Bamboo Data Center – Ticket BAM-26567;
- Crowd Data Center – Ticket CWD-6610;
- Crucible – Ticket CRUC-8741;
- Fisheye – Ticket FE-7583.
Die Cloud-Versionen von Atlassian wurden bereits aktualisiert, Bitbucket Cloud ist nicht verwundbar. Für Cloud-Kunden sind keine Maßnahmen erforderlich, alle Aufmerksamkeit sollte lokalen Deployments gelten.
Problempunkte bei Versionen und Server-Editionen
Rund um die Spanne der betroffenen und behobenen Versionen gibt es Unklarheiten zwischen Sicherheitshinweis und CVE-Einträgen:
- für Crowd gibt im Ticket CWD-6610 ein Feld die behobene Version des 7.1-Zweigs als 7.1.7 an, während die Tabelle im selben Ticket gleichzeitig 7.1.6 sowohl als behoben als auch als verwundbar ausweist;
- im JSON-Eintrag zum CVE für Crowd ist Version 7.1.1 als Grenze angegeben, obwohl laut den Release Notes zu Crowd 7.1 dieser Release vom November 2025 datiert, also lange vor der öffentlichen Offenlegung der Schwachstelle;
- für Bamboo tauchen im CVE-Eintrag zwei Varianten der Versionsnummer auf: 10.2.4 und 10.2.24, was die eindeutige Bestimmung der sicheren Version erschwert.
Ein eigenes Problem ist der Status der Server-Editionen. Im CVE-Eintrag markiert Atlassian alle Versionen von Bamboo Server, Bitbucket Server, Confluence Server und Crowd Server als verwundbar, ohne eine einzige behobene Version zu nennen. Für Jira Software Server, Jira Service Management Server, Crucible Server und Fisheye Server sind Versionen angegeben, ab denen die Produkte als nicht verwundbar gelten (zum Beispiel Jira Software Server ab 9.12.40), ohne zu erläutern, ob der Betrieb dieser Versionen unter den Server-Lizenzbedingungen zulässig ist.
Zusätzlich ist gemäß den allgemeinen Release Notes zu Crowd die letzte Server-Version von Crowd 5.2 (September 2023), das heißt, keine der genannten behobenen Crowd-Versionen gehört zur Server-Linie. Für die Betreiber solcher Installationen bedeutet dies faktisch das Fehlen eines Patches und die Notwendigkeit kompensierender Maßnahmen.
Nach CVSS v4 erhält die Schwachstelle eine Bewertung von 9.3: Angriffsvektor – Netzwerk, ohne Rechte und ohne Benutzereingriff; die Auswirkung auf die Vertraulichkeit des verwundbaren Systems selbst ist hoch, auf Integrität und Verfügbarkeit nicht vorhanden, während der Einfluss auf andere Systeme ebenfalls als hoch bewertet wird. Letzteres spiegelt indirekt das Risiko wider, dass das Lesen von Dateien im Wurzelverzeichnis der Webanwendung zur Kompromittierung von Zugangsdaten, Tokens oder Konfigurationen führen kann, die mit anderen Systemen verbunden sind.
Bedrohungskontext: Präzedenzfall mit CVE-2021-26086
Path traversal in Produkten von Atlassian wurde bereits zuvor ausgenutzt. Die Schwachstelle CVE-2021-26086 in Jira Server und Data Center ermöglichte entfernten Angreifern das Lesen einzelner Dateien und wurde später in den Katalog der bekannt ausgenutzten Schwachstellen (KEV) der CISA aufgenommen. Details finden sich im Eintrag NVD: CVE-2021-26086.
Dieser Präzedenzfall ist aus zwei Gründen wichtig:
- er bestätigt das reale Interesse von Angreifern an Dateilecks aus Atlassian-Plattformen, die häufig Entwicklungsartefakte, Integrationsschlüssel und Dokumentation zur Infrastruktur enthalten;
- er zeigt, dass selbst „eingeschränktes“ Lesen einzelner Dateien gravierend genug sein kann, um in priorisierte Schwachstellenlisten auf Ebene staatlicher Regulierer aufgenommen zu werden.
Im aktuellen Sicherheitshinweis erklärt Atlassian, keine Hinweise auf eine Ausnutzung von CVE-2026-21589 in der Cloud-Umgebung gefunden zu haben und nicht bestätigen zu können, ob konkrete lokale Installationen kompromittiert wurden. Das Fehlen von Informationen zu tatsächlichen Angriffen reduziert das Risiko nicht, angesichts des kritischen CVSS-Scores und der Historie bereits ausgenutzter ähnlicher Fehler.
Auswirkungsanalyse für Organisationen
Gefährdet ist das gesamte Spektrum von Organisationen, die:
- Atlassian Data Center betreiben oder noch nicht von Server– auf moderne Editionen migriert sind;
- diese Instanzen aus dem Internet erreichbar machen (einschließlich Szenarien mit verpflichtender Anmeldung);
- Atlassian als zentrales Element der Entwicklungs- und Betriebs-Toolchain nutzen (Aufgabenverwaltung, Repositories, CI/CD, Zugriffsverwaltung).
Auch wenn die Schwachstelle formal auf das Lesen von Dateien innerhalb des Wurzelverzeichnisses der Webanwendung beschränkt ist, finden sich in solchen Verzeichnissen in der Praxis häufig:
- Konfigurationsdateien mit Verbindungsparametern zu Datenbanken und externen Services;
- Skripte und Templates, deren Inhalt Rückschlüsse auf die Systemarchitektur oder Authentifizierungsmechanismen zulässt;
- Log- und Temporärdateien, die Fragmente von Requests, Tokens und interne Pfade enthalten.
Die Kombination solcher Daten kann führen zu:
- einer Eskalation vom Dateilesen zur Übernahme der Datenbank, eines Integrationskontos oder eines anderen Dienstes;
- einem Abfluss von Quellcode, interner Dokumentation und anderem geistigem Eigentum über die Abhängigkeitskette (etwa bei Zugriff auf Bitbucket oder Bamboo);
- verstärkten Angriffen auf die Lieferkette, wenn ein Angreifer über eine verwundbare Atlassian-Instanz Einblick in den Build- und Release-Prozess eines Produkts erhält.
Die Unklarheit über die Grenzen sicherer Versionen und den Status der Server-Editionen schafft zusätzliches Betriebsrisiko: Administratoren können schwerer schnell beantworten, „ist genau diese Instanz verwundbar“, und damit wird es schwieriger, Maßnahmen zu priorisieren und das Risiko gegenüber dem Business zu kommunizieren.
Praktische Empfehlungen zur Risikoreduzierung
1. Aktualisierung als vorrangiges Szenario
- Orientieren Sie sich am offiziellen Sicherheitshinweis von Atlassian: Sicherheitshinweis zu CVE-2026-21589 und den zugehörigen Produkt-Tickets (BSERV-20604, CONFSERVER-104488 u. a.).
- Ermitteln Sie für jedes Produkt die aktuelle Version und vergleichen Sie sie mit der Angabe „Fixed in“ im jeweiligen Ticket.
- Die bevorzugte Option ist ein Update auf die genannte behobene LTS-Version oder neuer, sofern diese ebenfalls als enthaltenen Fix ausgewiesen ist.
- Für veraltete Server-Editionen, für die es keine Patches gibt, sollten eine beschleunigte Migration auf Data Center oder Cloud beziehungsweise die Verlagerung solcher Instanzen in ein streng kontrolliertes, isoliertes Umfeld erwogen werden.
2. Netzwerkseitige Zugriffsbeschränkungen
- Ist ein sofortiges Update nicht möglich, sollten Sie nach Empfehlung von Atlassian die Instanz nach Möglichkeit vorübergehend vom externen Netzwerk trennen.
- Für kritische Systeme, die nicht abgeschaltet werden können, beschränken Sie den Zugriff auf interne Netze und VPN und vermeiden Sie eine direkte Veröffentlichung im Internet.
- Implementieren Sie im WAF oder am Reverse-Proxy eine Regel, die Anfragen blockiert, in denen nach bis zu zweifacher URL-Dekodierung eine Sequenz
..in unmittelbarer Nähe zu/,\\oder::auftritt. Der konkrete Ausdruck ist im Sicherheitshinweis von Atlassian angegeben.
3. Temporäre Regeln auf Anwendungsebene
Atlassian schlägt zusätzliche „Mitigations“ auf Ebene der Anwendungen selbst vor (sie ersetzen kein Update):
- für Confluence, Jira Software, Jira Service Management, Bamboo, Crowd – Einsatz von Tomcat RewriteValve mit einer Regel, die die oben beschriebenen Muster in URLs blockiert; für die Aktivierung sind Konfigurationsänderungen auf jedem Knoten und ein Neustart des Dienstes erforderlich;
- für Bitbucket – Ergänzung einer Regel in
urlrewrite.xmlauf jedem Knoten und Mirror, ebenfalls mit anschließendem Neustart; - für Crucible und Fisheye stehen nur externe Maßnahmen (WAF/Reverse-Proxy) zur Verfügung.
Diese Maßnahmen verringern die Wahrscheinlichkeit einer erfolgreichen Ausnutzung, beseitigen die Schwachstelle jedoch nicht. Nach Installation des Patches sollten sie als zusätzliche Schutzschicht beibehalten werden.
4. Log-Analyse auf mögliche Ausnutzung
Atlassian weist ausdrücklich darauf hin, dass nicht verifiziert werden kann, ob konkrete Instanzen angegriffen wurden, und empfiehlt Administratoren, die Logs eigenständig zu prüfen.
- Exportieren Sie die Zugriffslogs des Webservers und/oder die integrierten Produkt-Logs für den relevanten Zeitraum.
- Normalisieren Sie die Anfragen: Führen Sie eine bis zu zweifache URL-Dekodierung durch, um Umgehungsversuche über doppelte Kodierung aufzudecken.
- Suchen Sie nach Vorkommen von
..unmittelbar neben/,\\oder::– oder verwenden Sie denselben regulären Ausdruck wie in der von Atlassian vorgeschlagenen Blockierregel.
Der Sicherheitshinweis liefert keine Kriterien zur Unterscheidung zwischen fehlgeschlagenen und erfolgreichen Versuchen. In der Praxis ist es sinnvoll, zusätzlich zu analysieren:
- Antwortcodes des Servers (verdächtig sind Serien von 200/206-Antworten auf untypische Pfade);
- Antwortgrößen und Abweichungen im Vergleich zu üblichen statischen Ressourcen;
- die Korrelation mit nachfolgender Aktivität von derselben IP-Adresse (Authentifizierung, Konfigurationsänderungen, Herunterladen von Artefakten).
Werden verdächtige Zugriffe entdeckt, ist eine vertiefte Untersuchung angebracht: Inventarisierung, welche Dateien theoretisch gelesen worden sein könnten, Überprüfung von Accounts und Schlüsseln, gegebenenfalls erzwungene Änderung von Secrets.
5. Priorisierung der Reaktion
Angesichts des nicht authentifizierten Charakters der Schwachstelle, der starken Auswirkung auf die Vertraulichkeit und des potenziellen Einflusses auf andere Systeme ist es sinnvoll:
- alle aus dem Internet erreichbaren Atlassian-Instanzen in höchste Priorität für Updates und Mitigations aufzunehmen;
- Installationen besonders zu berücksichtigen, die Entwicklungs- und Build-Prozesse bedienen oder sensible Artefakte speichern (Repositories, Build-Artefakte, Zugriffskonfigurationen);
- Unklarheiten zu Versionen so schnell wie möglich zu beseitigen: Abgleich mit Tickets, Sicherheitshinweis und – falls nötig – dem Atlassian-Support zu „grauen“ Versionen wie den erwähnten Crowd- und Bamboo-Varianten.
Die wichtigste praktische Schlussfolgerung: CVE-2026-21589 sollte nicht als lokaler Defekt eines einzelnen Produkts betrachtet werden, sondern als kritisches Risiko für Konfigurations- und Datenabfluss in einem zentralen Teil der Entwicklungsinfrastruktur. Organisationen sollten unverzüglich alle lokalen Atlassian-Instanzen inventarisieren, auf sichere Versionen aktualisieren oder isolieren, die empfohlenen Filter auf WAF- und Anwendungsebene aktivieren und eine gezielte Log-Analyse auf verdächtige Anfragen mit path-traversal-Mustern durchführen.