Atlassian-Lücke CVE-2026-21589: Ein Dateilesen ohne Anmeldung, der zum Jira-Administrator macht

Atlassian hat am 5. Oktober 2026, außerhalb seiner regulären Security-Bulletins, ein Advisory für acht On-prem-Produkte veröffentlicht. CVE-2026-21589 erlaubt einer Anfrage, Dateien aus dem Verzeichnis der Webanwendung zu lesen, ohne dass sie sich irgendwo angemeldet hätte. Atlassian rechnet die Schwere mit 9,3 nach CVSS 4.0 und liefert Fix-Versionen für alle betroffenen Linien. Am Folgetag legte watchTowr Labs die Mechanik offen, beschrieb einen Angriffsweg bis zur Administrator-Rolle in Jira und stellte ein Prüfmittel für den eigenen Bestand dazu.

Was die Lücke genau tut

Gelesen werden Dateien innerhalb des Anwendungs-Wurzelverzeichnisses der Instanz. Ein Zugang, ein Konto, ein Token sind dafür nicht nötig; die Anfrage läuft über Routen, die Web-Ressourcen ausliefern und in allen genannten Produkten auf denselben geteilten Code bauen. Atlassian schränkt im Advisory ein: Der Angreifer muss Namen und Pfad der Zieldatei kennen, ein Verzeichnis durchsuchen kann er über die Schwachstelle nicht. Das nimmt der Meldung wenig ab, denn die interessanten Dateien heißen in jeder Installation gleich. Der Nachweis von watchTowr liest die WEB-INF/web.xml einer Jira-Instanz, eine Datei, die Tomcat normalerweise vor direkter Anfrage schützt.

Betroffen sind laut Advisory alle Versionen vor den Fix-Releases von Bitbucket Data Center, Confluence Data Center, Jira Service Management Data Center, Jira Software Data Center, Bamboo Data Center, Crowd Data Center, Crucible und Fisheye. Die als Fix genannten Stände nennt das Advisory in voller Länge; für den deutschen Betriebshandbuch-Auszug reichen die LTS-Linien: Bitbucket ab 9.4.26, Confluence ab 9.2.26, Jira und Jira Service Management ab 9.12.40 beziehungsweise 5.12.40, Bamboo ab 10.2.24, Crowd ab 6.3.7, Crucible und Fisheye ab 4.9.15. Auf der sicheren Seite ist, wer auf die jeweils aktuelle gepflegte Linie hebt, denn betroffen sind ausdrücklich alle früheren Versionen.

Der Mechanismus: zwei Doppelpunkte machen den Schrägstrich

watchTowr verglich die Jar-Dateien atlassian-plugins-webresource der ungepatchten und der gepatchten Stände und stieß in der Klasse Router auf ein Funktionenpaar, das in Pfadteilen zwei Doppelpunkte gegen einfache Schrägstriche tauscht. Die Web-Ressourcen-Routen nutzen dieses Escaping, damit ein Ressourcenname in der URL nicht als Pfad gelesen wird. Die Filter vor der Anwendung kennen Doppelpunkte nicht als Trennzeichen, die Anwendung danach tut es genau das. Aus ..::..::..::..::WEB-INF::web.xml wird nach dem Entescapen eine Folge von Punkt-Punkt-Segmenten, und ein Traversal, den jede normale Prüfung für Schrägstrich und Backslash erwartet hätte. Der Einstieg führt über unscheinbare Download-Routen der mitgelieferten Plugins, in Jira über die Bildersammlung des Farbpicker-Plugins. watchTowr dokumentiert die fertigen URIs für Jira, Confluence und Bitbucket und merkt an, dass der Weg sich über die Tomcat-Kontextgrenze hinaus nicht fortsetzen lässt: gelesen wird der Anwendungsbereich, nicht die ganze Festplatte.

Vom gelesenen File zum Jira-Administrator

Das Advisory selbst beschreibt die Wirkung in einem Satz, den man als Betreiber wörtlich nehmen sollte: „In some configurations, there may be sensitive files present that increase your risk.“ watchTowr zeigt, welche Konfigurationen gemeint sind. Wer seine Atlassian-Produkte über Atlassian Crowd an ein zentrales Single Sign-on hängt, legt die Anwendungsdaten in der Datei crowd.properties im Ordner WEB-INF/classes ab, dort stehen Anwendungsname und Anwendungs-Passwort im Klartext. Diese Datei ist eine der Dateien, deren Namen man als Angreifer kennen muss, und die öffentliche Analyse nennt den Pfad.

Mit Namen und Passwort lässt sich die Crowd-REST-Schnittstelle als berechtigte Anwendung ansprechen. Die dokumentierte Proof-of-Concept-Kette liest die Nutzerliste, legt einen eigenen Nutzer an und hängt ihn in die Gruppe jira-administrators. Danach liegt die Administrator-Rolle in Jira vor, erreicht über eine einzige Schwachstelle, die formal nur Dateien liest. Der CVSS-Vektor von Atlassian trägt genau diese Richtung, er setzt die Vertraulichkeit im primären wie im sekundären Bereich auf High. Der praktische Unterschied zwischen Dateilesen und Rechteübernahme hängt an einer Konfigurationsdatei.

Stand der Dinge: Zahlen und Ausnutzung

Der CVSS-Vektor im Wortlaut: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H. Die Hochstufung sitzt im sekundären Bereich, also bei den Systemen, die über die gelesenen Daten erreichbar werden, bei einer Crowd-Installation mit Anbindung an mehrere Produkte ein beträchtlicher Kreis. Atlassian meldet für die Cloud Entwarnung: Die Cloud-Produkte sind laut Advisory gepatcht, die Untersuchung fand keinen Hinweis auf Ausnutzung, Cloud-Kunden müssen nichts tun. Für die selbst betriebenen Instanzen schließt der Hersteller eine Beeinträchtigung nicht aus, der Satz im Advisory lautet, dass Atlassian nicht bestätigen kann, ob die eigenen Instanzen betroffen sind.

Bei den Bewertungen bleiben zwei Zahlen stehen, weil zwei Stellen nachgerechnet haben. Atlassian führt die Schwachstelle mit 9,3 nach CVSS 4.0. Das BSI kommt in seiner Meldung WID-SEC-2026-3755 auf 8,6 in der Basis und 8,2 zeitabhängig, beides als hoch eingestuft, datiert auf den 5. Oktober 2026 und am 8. Oktober nachgezogen; sein Produktkreis nennt Bamboo, Bitbucket, Confluence, Crucible, Fisheye und Jira, Crowd fehlt dort, obwohl Atlassian für Crowd Data Center vier Fix-Versionen aufführt. Das niederländische NCSC übernahm am 6. Oktober 2026 um 18:47 die 9,3 von Atlassian, Priorität Normaal. Keine der beiden Meldungen nennt eine Frist, bis wann gepatcht sein muss.

Ausnutzung ist inzwischen gemeldet, vier Tage nach Veröffentlichung. Nach den Telemetriedaten des Anbieters Previdian, ausgewertet von The Hacker News, gingen in dessen Honeypot-Netzwerk 15 Angriffsversuche von drei Adressen aus Japan und den USA ein, der erste davon zwei Stunden nachdem watchTowr die technischen Details veröffentlicht hatte. watchTowr bestätigte gegenüber demselben Blatt, aktive Ausnutzung zu beobachten, die meisten Versuche zielten auf das Abtasten bekannter Konfigurationsdateien; eine Zeit nach einem Einbruch, in der erbeutete Anmeldungen benutzt wurden, sei bislang nicht zu sehen. Es sind Anbietermeldungen über einen Bericht, keine Hersteller- und keine Behördenzahl, und kein Bericht meldet einen bestätigten Einbruch. Der offene Prüfschritt für Betreiber bleibt deshalb der Log-Eintrag, nicht die Schlagzeile.

Nicht drin steht der Fall bislang im offiziellen Katalog ausgenutzter Schwachstellen der amerikanischen Cybersecurity-Behörde CISA: gemessen an der Ausgabe vom 8. Oktober 2026 mit 6231 Einträgen, kein Treffer. Über das Wochenende ist der Katalog nicht neu erschienen, ein späterer Eintrag lässt sich damit nicht ausschließen.

Die Größenordnung des betroffenen Bestands schätzen die Forscher anhand der Plattform FOFA, und die Zahl ist schmaler als ihr Ruf. Ihr Satz lautet, eine Internetsuche ergebe knapp 700.000 Instanzen von Confluence allein, gesucht ist dabei der Titel des Anmeldebildschirms, gezählt wird also der sichtbar antwortende Dienst und nicht die verwundbare Installation. Jira kommt in dieser Zählung nicht vor, und die Größe der tatsächlich betroffenen Menge ordnen dieselben Autoren nur breit ein, im sechs- bis siebenstelligen Bereich. Eine Herstellerstatistik ist das nicht, und sie sagt nichts darüber, wie viele davon ungepatcht sind. Zum Prüfen liegt seit 6. Oktober ein Prüfmittel offen auf GitHub, ein Detection Artefact Generator, zwei Dateien, drei vorgegebene Pfade und eine Antwortprüfung ohne Anmeldung; die vollständige Kette bis zur Administrator-Rolle zeigen die Autoren als Abbild im Beitrag, das Skript dazu bleibt unter Verschluss. Dasselbe gilt für ein Nuclei-Template: der genannte Bericht zitiert die Erwartung, dass dessen Veröffentlichung das massenhafte automatische Abtasten noch leichter macht. Für Betreiber ist beides nützlich und unangenehm zugleich, die eigene Instanz ist in Sekunden geprüft, jede andere auch.

Was Betreiber jetzt tun

1. Auf die Fix-Versionen patchen, die das Advisory je Produkt und Linie nennt. Atlassian empfiehlt den nächsten gepflegten LTS-Stand; die vollständige Tabelle steht im Advisory verlinkt.

2. Was heute nicht zu patchen ist, vom Internet nehmen. Atlassian nennt als ersten Workaround, öffentliche Erreichbarkeit ganz abzuschalten, auch hinter Login, bis der Patch steht.

3. Bis dahin die WAF-Regel aus dem Advisory setzen. Sie blockt URLs, in denen Punkt-Punkt unmittelbar neben Schrägstrich, Backslash, Doppelpunkt oder deren Prozent-Schreibweisen steht. Die Regel im Wortlaut:

   (?is).*(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2})(?:\.|%(?:25)*2e){2}(?:/|\\|::|%(?:25)*(?:2f|5c)|(?::|%(?:25)*3a){2}|;|%(?:25)*3b|$).*

   Getestet wird die Regel gegen beide Hälften: die rohe Form ..:: und die kodierten Varianten. Wer Tomcat lieber auf dem Host selbst dichten lässt, findet im Advisory den Weg über den RewriteValve mit einer rewrite.config für Confluence, Jira Service Management, Jira, Bamboo und Crowd.

4. Access-Logs absuchen nach ..::, nach %3a%3a und nach Punkt-Punkt-Segmenten auf den Web-Ressourcen-Routen. Ein Treffer heißt: Jemand hat genau den Pfad ausprobiert, den die öffentliche Analyse beschreibt, ab dann zählt der Bestand als potenziell kompromittiert.

5. Crowd-Anwendungspasswörter drehen, auf allen angebundenen Produkten, sobald eine Instanz länger unpatcht erreichbar war, auch ohne Log-Treffer. Das Passwort steht im Klartext in einer Datei, die die Lücke lesbar macht, ein Log-Eintrag wäre dafür die schlechteste aller Spuren.

Unser eigener Betrieb

Wir betreiben keines der acht Produkte, und seit dem 11. Oktober ruht dieser Satz auf drei gemessenen Ebenen statt auf einer Vermutung aus Betriebsnotizen. Erste Ebene, die Gästeschaft: Über die Verwaltungsschnittstelle unserer Proxmox-Cluster haben wir die Namen aller Gäste beider Cluster durchsucht, 65 produktive und 20 weitere im Homelab, kein Treffer für Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible oder Fisheye. Zweite Ebene, der Rand: Auf unserem internen Edge stehen 36 Konfigurationsdateien mit 33 Server-Namen für senn-gruppe.com, kein Atlassian-Produkt darunter; das interne Wiki, das man dafür halten könnte, antwortet mit einer Weiterleitung auf den Hilfebereich unseres Zammad-Ticketsystems und ist kein Confluence. Dritte Ebene, das DNS: Die interne Zone mit 101 Einträgen trägt ebenso wenig einen Treffer.

Was diese Messung nicht leistet, gehört ebenso in den Satz: Sie prüft Namen, keine Laufwerke. Ein Atlassian-Produkt, das über keinen DNS-Namen bekannt gemacht wird und keinen Vhost am Rand braucht, ist mit dieser Messung nicht gefunden. Wer eines der Produkte laufen hat und nicht weiß, ob es die betroffene Linie erwischt, prüft es mit dem offenen Prüfmittel der Forscher gegen die eigene Instanz; der Test schickt nur Anfragen an die eigene Adresse.

Weiterführende Quellen

• Advisory CVE-2026-21589, Atlassian, 5. Oktober 2026: confluence.atlassian.com
• Recherche „You Won’t Hear About These, Even In Myths“, watchTowr Labs, 6. Oktober 2026: labs.watchtowr.com
• Prüfmittel (Detection Artefact Generator), watchTowr Labs auf GitHub, 6. Oktober 2026: github.com/watchtowrlabs
• WID-SEC-2026-3755, BSI CERT-Bund, 5. Oktober 2026, nachgezogen am 8. Oktober 2026: wid.cert-bund.de
• NCSC-2026-0402, NCSC-Niederlande, Stand 6. Oktober 2026 18:47: advisories.ncsc.nl
• „Atlassian Data Center Flaw Draws Exploitation Attempts Within Two Hours of Public Details“, The Hacker News, 7. Oktober 2026, mit den Telemetriedaten von Previdian: thehackernews.com
• Katalog ausgenutzter Schwachstellen (Known Exploited Vulnerabilities), Cybersecurity and Infrastructure Security Agency, maschinenlesbare Ausgabe vom 8. Oktober 2026 mit 6231 Einträgen: cisa.gov