Atlassian-Lücke CVE-2026-21589: Data Center jetzt patchen
Eine kritische Lücke (CVSS 9,3) lässt Unbekannte ohne Anmeldung Dateien aus Jira, Confluence, Bitbucket und weiteren Data-Center-Produkten lesen. Welche Versionen sie schließen, was bei laufenden Angriffen zu prüfen ist und wo die Lücke endet.
Was ist CVE-2026-21589 und welche Produkte betrifft sie?
CVE-2026-21589 ist eine Lücke in acht selbst betriebenen Atlassian-Produkten, über die ein nicht angemeldeter Angreifer einzelne Dateien aus dem Verzeichnis der Webanwendung abrufen kann. Betroffen sind Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo und Crowd in der Data-Center-Edition sowie Crucible und Fisheye. Atlassian hat die Lücke am 5. Oktober 2026 in einem Sicherheitshinweis des Herstellers (öffnet in neuem Tab) veröffentlicht und mit 9,3 von 10 Punkten nach CVSS 4.0 als kritisch eingestuft.
Die Einstufung erklärt sich aus der Kombination: Der Angriff läuft über das Netz, braucht weder Konto noch Mitwirkung eines Nutzers und ist technisch einfach. Die Daten der Anwendung selbst werden nur gelesen, nicht verändert – die hohe Wertung kommt vor allem daher, dass ausgelesene Inhalte die Tür zu weiteren Systemen öffnen können. Der Eintrag in der NVD (öffnet in neuem Tab) führt die Schwachstelle unter CWE-552, also Dateien, die nach außen zugänglich sind, obwohl sie es nicht sein sollten.
Für ein kleines oder mittleres Unternehmen ist die erste Frage deshalb nicht technisch, sondern organisatorisch: Läuft irgendwo im Haus oder bei einem Dienstleister eine selbst gehostete Jira-, Confluence- oder Bitbucket-Instanz? Oft ist das eine Installation, die vor Jahren für die Entwicklung oder den Support aufgesetzt wurde und seither nebenher läuft. Zuerst berichtete im deutschsprachigen Raum heise online über die Warnung (öffnet in neuem Tab) am 6. Oktober 2026.
Welche Versionen schließen die Lücke?
Die Lücke ist geschlossen ab folgenden Versionen, jeweils einschließlich aller späteren Versionen desselben Zweigs: Jira Software Data Center 9.12.40, 10.3.26 und 11.3.12; Jira Service Management Data Center 5.12.40, 10.3.26 und 11.3.12; Confluence Data Center 9.2.26 und 10.2.19; Bitbucket Data Center 9.4.26, 10.2.8 und 10.5.1; Bamboo Data Center 10.2.24 und 12.1.12; Crowd Data Center 6.3.7, 7.0.3, 7.1.7 und 7.2.4; Crucible und Fisheye 4.9.15. Atlassian empfiehlt, jede betroffene Installation auf eine dieser Versionen oder die jeweils neueste zu bringen.
Alle älteren Versionen sind verwundbar, und zwar weit zurück: Laut NVD reicht die Lücke bei Jira Software bis Version 7.1.0, bei Confluence bis 5.10.0, bei Bitbucket bis 4.6.0 und bei Crowd bis 2.11.0. Wer eine Installation betreibt, die seit Jahren nicht mehr aktualisiert wurde, ist also mit hoher Wahrscheinlichkeit betroffen. Wer auf einem Zweig sitzt, für den Atlassian keine korrigierte Version anbietet, muss auf einen der genannten Zweige wechseln – ein einfaches Patch-Update reicht dann nicht.
Wichtig ist der Blick auf alle Produkte, nicht nur auf das wichtigste. Ein aktualisiertes Jira neben einem vergessenen Bamboo oder Crowd lässt die Lücke offen, denn jedes der acht Produkte ist für sich angreifbar. Wo mehrere Atlassian-Systeme laufen, gehört deshalb eine kurze Liste mit Produkt, Version und Erreichbarkeit aus dem Internet an den Anfang – diese Bestandsaufnahme ist auch der erste Schritt jedes Sicherheitsaudits.
Wie funktioniert der Angriff?
Der Angriff funktioniert über manipulierte Pfadangaben in Adressen, über die die Anwendung eigentlich nur Bilder, Skripte und Stylesheets ausliefert. Nach der Beschreibung im öffentlichen Prüfmuster für den Scanner Nuclei (öffnet in neuem Tab) liegt der Fehler in der Bibliothek atlassian-plugins-webresource, die eine doppelte Doppelpunktfolge als Pfadtrenner behandelt. Damit lässt sich aus dem vorgesehenen Ordner herausspringen und eine andere Datei innerhalb der Webanwendung abrufen.
Der Angreifer muss den genauen Namen und Pfad der gewünschten Datei kennen; eine Liste der vorhandenen Dateien bekommt er nicht. Das klingt nach einer hohen Hürde, ist es aber kaum: Die Verzeichnisstruktur einer Standardinstallation ist dokumentiert und bei allen Instanzen gleich. Das Nuclei-Muster fragt zum Nachweis etwa die Datei WEB-INF/web.xml ab, die es in jeder Installation gibt.
Weil ein fertiges Prüfmuster öffentlich verfügbar ist, kann jeder mit einem verbreiteten Werkzeug ganze Adressbereiche nach verwundbaren Instanzen absuchen. Die US-Behörde CISA hat die Lage am 7. Oktober 2026 in ihrer Bewertung in der NVD so eingeordnet, dass ein Machbarkeitsnachweis existiert und die technischen Folgen vollständig sein können. Für Betreiber heißt das: Eine aus dem Internet erreichbare, ungepatchte Instanz wird gefunden, nicht nur vielleicht.
Wird die Lücke bereits angegriffen?
Ja, Angriffsversuche sind seit dem Abend des 6. Oktober 2026 beobachtet. Das Sicherheitsunternehmen Previdian meldet die ersten Versuche auf seinen Sensoren für 20:52 Uhr UTC, also einen Tag nach dem Hinweis des Herstellers. Bis zum 8. Oktober zählte es 187 Versuche von 31 IP-Adressen aus neun Ländern, darunter Deutschland, die Schweiz und die Niederlande.
Abgefragt wurden nach diesen Beobachtungen unter anderem die Datei WEB-INF/web.xml und die Datei crowd.properties. Die zweite ist der interessante Teil: Sie liegt in Installationen, die ihre Benutzer über Atlassian Crowd verwalten, und kann je nach Einrichtung die Zugangsdaten enthalten, mit denen sich die Anwendung beim Crowd-Server anmeldet. Crowd ist die zentrale Benutzerverwaltung mit Single Sign-on, an der oft mehrere Anwendungen gleichzeitig hängen.
Im Katalog aktiv ausgenutzter Lücken der CISA (öffnet in neuem Tab) stand CVE-2026-21589 bei Redaktionsschluss am 8. Oktober 2026 nicht. Das ist kein Entwarnungssignal, denn der Katalog führt nur Fälle, die die Behörde selbst bestätigt hat, und er hinkt den ersten Beobachtungen oft um Tage hinterher. Für Atlassians eigene Cloud-Instanzen meldet der Hersteller, keine Hinweise auf eine Ausnutzung gefunden zu haben.
Was tun, wenn das Update nicht sofort möglich ist?
Wenn das Update nicht sofort möglich ist, beschreibt Atlassian drei Übergangslösungen, die Anfragen mit der kritischen Pfadfolge abweisen. Die erste ist eine Regel in einer Web Application Firewall, die Adressen mit zwei Punkten neben einem Pfadtrenner blockiert – in jeder Kodierung, auch doppelt URL-kodiert. Den regulären Ausdruck dafür liefert der Sicherheitshinweis wörtlich mit.
Die zweite Lösung ist ein Rewrite-Ventil im Tomcat-Server, der unter Confluence, Jira, Jira Service Management, Bamboo und Crowd läuft: Dafür wird auf jedem Knoten des Clusters die Datei server.xml ergänzt, eine rewrite.config mit den Sperrregeln angelegt und der Knoten neu gestartet. Bei Bitbucket tritt an diese Stelle ein Eintrag in der Datei urlrewrite.xml, der passende Anfragen mit dem Status 404 beantwortet. Vor jedem dieser Eingriffe verlangt der Hersteller eine Sicherung der Instanz.
Diese Maßnahmen sind eine Brücke, kein Ersatz. Eine Filterregel deckt die bekannten Schreibweisen ab, und jede selbst gebaute Abweichung vom Wortlaut des Herstellers kann Lücken lassen oder legitime Anfragen blockieren. Wer seine Instanz ohnehin nur intern braucht, erreicht mit dem Abschotten vom Internet hinter VPN oder Firewall die größte Wirkung mit dem geringsten Risiko – und gewinnt Zeit für ein geplantes Update.
Wie erkennt man in den Logs, ob jemand zugegriffen hat?
Ob jemand die Lücke ausgenutzt hat, zeigen die Zugriffsprotokolle des Webservers oder Reverse-Proxys vor der Atlassian-Anwendung. Atlassian empfiehlt, die protokollierten Adressen bis zu zweimal URL-zu-dekodieren und danach nach zwei Punkten zu suchen, die direkt neben einem Schrägstrich, einem Backslash oder einer doppelten Doppelpunktfolge stehen. Alternativ lässt sich der reguläre Ausdruck aus der WAF-Regel direkt auf die Rohprotokolle anwenden.
Ein Treffer mit dem Statuscode 200 bedeutet, dass eine Datei ausgeliefert wurde. Dann reicht das Update allein nicht mehr: Alle Zugangsdaten, die in erreichbaren Dateien standen, gelten als bekannt und müssen gewechselt werden – allen voran das Anwendungspasswort für Crowd, aber auch Kennungen für Datenbank, E-Mail-Versand und angebundene Schnittstellen. Danach lohnt der Blick in die Benutzerverwaltung, ob seit dem 6. Oktober neue Konten mit Administratorrechten entstanden sind.
Wie man bei einem bestätigten Zugriff in der richtigen Reihenfolge vorgeht, beschreibt unser Beitrag Website gehackt: was jetzt zu tun ist – die Schritte gelten für eine Jira- oder Confluence-Instanz sinngemäß. Ohne dauerhaftes Monitoring der Zugriffe fällt so ein Vorfall oft erst Wochen später auf; eine einfache Alarmregel auf die genannten Muster kostet wenig und bleibt über diese eine Lücke hinaus nützlich.
Cloud oder Data Center: wer muss handeln?
Handeln muss nur, wer Atlassian-Produkte selbst betreibt, ob im eigenen Serverraum, in einem Rechenzentrum oder bei einem Hoster. Für die Cloud-Angebote schreibt Atlassian, die betroffenen Produkte seien bereits korrigiert und Kunden müssten nichts tun. Die Verantwortung für Data-Center-Installationen liegt dagegen vollständig beim Betreiber, einschließlich Wartungsfenster und Tests nach dem Update.
Die Lücke fällt in eine Phase, in der viele Betreiber ohnehin über die Zukunft ihrer Installation nachdenken. Atlassian beendet das Data-Center-Angebot laut seiner Seite zum Ende von Data Center (öffnet in neuem Tab) am 28. März 2029; Neukunden können seit 30. März 2026 keine Data-Center-Abonnements mehr abschließen. Bis zum Ende sagt der Hersteller technischen Support und Sicherheitskorrekturen für kritische Lücken zu.
Daraus folgt kein Zwang zum sofortigen Wechsel, aber eine klare Abwägung: Jede kritische Lücke bis 2029 erfordert dieselbe Reaktion wie diese. Wer die eigene Instanz nur noch aus Gewohnheit betreibt, kann den Anlass nutzen, eine geordnete Cloud-Migration oder einen anderen Weg zu planen. Wer bleibt, braucht eine verlässliche Wartung mit festen Update-Zyklen, damit der nächste Hinweis nicht wieder zur Suche nach der vergessenen Instanz wird.
Was die Lücke nicht kann – und wen sie nicht betrifft
CVE-2026-21589 erlaubt laut Hersteller nur das Lesen einzelner Dateien innerhalb des Verzeichnisses der Webanwendung, keine Codeausführung und kein Schreiben. Ob darüber auch Konfigurationsdateien aus dem separaten Datenverzeichnis einer Installation erreichbar sind, in dem etwa die Datenbankverbindung liegt, sagt der Sicherheitshinweis nicht. Behauptungen, die Lücke gebe „das ganze System" preis, gehen über das hinaus, was Atlassian bestätigt.
Nicht betroffen sind Kunden der Atlassian Cloud und Unternehmen, deren selbst gehostete Instanz bereits auf einer der korrigierten Versionen läuft. Ebenfalls deutlich geringer ist das Risiko, wenn eine Instanz nur aus dem internen Netz erreichbar ist – ausgeschlossen ist es dann aber nicht, denn ein Angreifer mit Zugang zu einem einzigen Arbeitsplatzrechner kann die Lücke ebenso nutzen.
Die eigentliche Gefahr liegt im zweiten Schritt: Erst wenn eine ausgelesene Datei verwertbare Zugangsdaten enthält, wird aus dem Lesezugriff ein Einbruch. Wer Passwörter nicht im Klartext in Konfigurationsdateien ablegt und Dienstkonten mit minimalen Rechten ausstattet, begrenzt den Schaden auch dann, wenn eine solche Lücke wieder auftaucht. Das ersetzt das Update nicht, verschiebt aber die Folgen von „kompromittiert" zu „ärgerlich".
Quellen
- Sicherheitshinweis des Herstellers(öffnet in neuem Tab)confluence.atlassian.com
- Eintrag in der NVD(öffnet in neuem Tab)nvd.nist.gov
- heise online über die Warnung(öffnet in neuem Tab)www.heise.de
- Prüfmuster für den Scanner Nuclei(öffnet in neuem Tab)github.com
- Katalog aktiv ausgenutzter Lücken der CISA(öffnet in neuem Tab)www.cisa.gov
- Seite zum Ende von Data Center(öffnet in neuem Tab)www.atlassian.com