Atlassian Sicherheitslücke CVE-2026-21589: Angriffe nach PoC-Veröffentlichung

Hinweis: Dieser Beitrag wurde mit KI-Unterstützung erstellt und automatisiert veröffentlicht.

Die Atlassian Sicherheitslücke CVE-2026-21589 ist seit dem 5. Oktober 2026 bekannt — und seit dem 7. Oktober wird sie angegriffen. Betroffen sind nach Herstellerangabe alle Versionen von acht selbst gehosteten Produkten: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo und Crowd — jeweils in der Data-Center-Edition — sowie Crucible und Fisheye. Atlassian bewertet die Lücke mit CVSS 4.0 9.3 als kritisch.

Was CVE-2026-21589 technisch möglich macht

Die Schwachstelle erlaubt es einem Angreifer ohne Anmeldung, einzelne Dateien im Web-Root der Anwendung zu lesen. Enumerieren oder Verzeichnisse auflisten geht laut Advisory nicht. Der Angreifer muss Namen und Pfad der Zieldatei also kennen. Das klingt nach einer Hürde — ist aber keine, denn in Standardinstallationen liegen diese Pfade fest.

Als Ursache nennt das Sicherheitsunternehmen watchTowr eine gemeinsam genutzte Web-Resource-Bibliothek, die doppelte Doppelpunkte („::") in Schrägstriche umwandelt. Darüber ließen sich Traversal-Anfragen über Plugin-Endpunkte bauen. In Deployments mit angebundenem Crowd konnten die Forscher die Datei WEB-INF/classes/crowd.properties auslesen — dort stehen Anwendungs-Zugangsdaten im Klartext. Mit diesen Daten legten sie über die Crowd-API ein Jira-Administratorkonto an. Das gilt allerdings nur, wenn Crowd erreichbar ist und die Anwendung ausreichende Rechte hat; andernfalls müsste ein Angreifer erst über andere Systeme pivotieren. Aus dem Tomcat-Anwendungskontext heraus kamen die Forscher nach eigenen Angaben nicht. Unter diesen Bedingungen wird aus „liest eine Datei" aber „ist Admin".

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Vom Advisory zum Angriff in zwei Tagen

Wichtig zur Einordnung: Ob Data-Center-Instanzen angegriffen werden, sagt das Atlassian-Advisory nicht — die Entwarnung „keine Hinweise auf Ausnutzung" bezieht sich dort ausdrücklich nur auf die Cloud-Produkte. Am 6. Oktober war noch keine Ausnutzung bekannt. Dann veröffentlichte watchTowr einen technischen Bericht samt Proof of Concept. Rund zwei Stunden später sah das Honeypot-Netz der Firma Previdian die ersten Exploit-Versuche, wie deren Ryan Dewhurst gegenüber BleepingComputer erklärte. Inzwischen existiert auch ein Nuclei-Template, das das Scannen automatisiert. Previdian nennt drei auffällige IP-Adressen und erwartet, dass die Aktivität in den kommenden Tagen deutlich zunimmt.

Was das für dich bedeutet: die Atlassian Sicherheitslücke im Praxis-Check

Aus CISO-Sicht ist das ein Lehrstück über zwei Dinge. Erstens: Eine „nur" lesende Lücke ist kein kleines Problem, wenn im Web-Root Geheimnisse liegen. Genau das ist bei gewachsenen Atlassian-Installationen der Normalfall — Properties-Dateien, Keystores, Konfigurationen mit Klartext-Passwörtern. Die eigentliche Schwachstelle sitzt hier in der Architektur: Zugangsdaten gehören nicht in Dateien, die der Webserver ausliefern kann. Dasselbe Muster haben wir vor wenigen Tagen schon bei den hunderttausenden gültigen Secrets in öffentlichen GitHub-Repos gesehen.

Zweitens: Das Zeitfenster schrumpft. Zwischen Advisory und ersten Scans lagen zwei Tage, zwischen PoC und Angriffsversuchen zwei Stunden. Wer sein Patch-Fenster in Wochen plant, plant an der Realität vorbei. Für kleine Betriebe mit einem selbst gehosteten Confluence oder Jira heißt das konkret: Diese Systeme brauchen dieselbe Behandlung wie ein Internet-Gateway — und sie brauchen jemanden, der sich zuständig fühlt. Erfahrungsgemäß ist genau das das Problem: Der Jira-Server gehört „der Entwicklung", nicht der IT.

Was du jetzt tun solltest

• Patchen, heute. Fixe Versionen sind laut Advisory u. a. Confluence Data Center 9.2.26 und 10.2.19, Jira Software und Jira Service Management 10.3.26 und 11.3.12 (dazu Jira Software 9.12.40 und Jira Service Management 5.12.40 für die älteren LTS-Linien), Bitbucket 9.4.26, 10.2.8 und 10.5.1, Bamboo 10.2.24 und 12.1.12, Crowd 6.3.7, 7.0.3, 7.1.7 und 7.2.4 sowie Crucible und Fisheye 4.9.15. Die vollständige Liste steht im Atlassian-Bulletin.
• Vom Internet nehmen, wenn du nicht sofort patchen kannst. Atlassian empfiehlt das ausdrücklich — auch für Instanzen, die hinter einem Login stehen.
• Übergangsweise filtern. Atlassian liefert eine WAF-Regel, eine Tomcat-RewriteValve-Konfiguration für Confluence, Jira, JSM, Bamboo und Crowd sowie eine urlrewrite.xml-Regel für Bitbucket. Alle blocken .. direkt neben Schrägstrich, Backslash oder ::. Teste die Regel danach wirklich, auch URL-kodiert.
• Verwundbarkeit messen statt schätzen. watchTowr hat ein kostenloses Scanner-Tool veröffentlicht, mit dem du deine Instanzen gegen CVE-2026-21589 prüfen kannst. Nutze es gegen eine Testinstanz, bevor du es gegen die Produktion richtest.
• Logs prüfen, nicht nur patchen. Atlassian kann nicht feststellen, ob deine Instanz kompromittiert wurde. Dekodiere die Zugriffslogs (bis zu zwei Durchgänge) und suche nach denselben Mustern.
• Nach dem Patch die Geheimnisse rotieren. Wenn Crowd angebunden ist: Zugangsdaten in crowd.properties erneuern und die Crowd-Benutzerliste auf neue Konten durchsehen. Ein Patch nimmt dem Angreifer den Weg, nicht die schon gelesene Datei.
• Danach aufräumen. IP-Allowlist vor Crowd, Secrets aus dem Web-Root heraus, und eine klare Zuständigkeit für jede selbst gehostete Anwendung. Wer solche Dienste im eigenen Netz betreibt, findet in meinem Ratgeber zu NAS und Heimserver die Grundlagen für einen sauberen Aufbau.

Cloud-Kunden müssen nichts tun: Die betroffenen Atlassian-Cloud-Produkte sind laut Hersteller gepatcht, Hinweise auf Ausnutzung gab es dort nicht. Das ist der unangenehme Teil der Nachricht für alle, die aus guten Gründen selbst hosten — die Patch-Last liegt bei dir.

Quellen

• Atlassian: CVE-2026-21589 – Arbitrary File Access Vulnerability impacts Multiple Products (Advisory, 5. Oktober 2026)
• BleepingComputer: Hackers exploit critical Atlassian flaw after public PoC release (7. Oktober 2026)
• Help Net Security: Atlassian urges immediate patching of critical Data Center file access vulnerability (6. Oktober 2026)
• watchTowr Labs: Pre-Auth Arbitrary File Read – CVE-2026-21589
• CVE-Eintrag CVE-2026-21589