Zum Hauptinhalt springen
S-EDV news
Schönfelder EDV
← Alle News
Sicherheit & Datenschutz 09.10.2026 · 4 min Lesezeit

Atlassian Data Center: Kritische Lücke CVE-2026-21589 wird binnen Stunden nach PoC angegriffen

Für CVE-2026-21589 in Atlassians Data-Center-Produkten laufen seit dem 6. Oktober Angriffsversuche, rund zwei Stunden nach Veröffentlichung eines Proof of Concept. Betroffen sind alle Versionen von Jira, Confluence, Bitbucket, Bamboo, Crowd, Crucible und Fisheye vor den Fix-Ständen. Cloud-Kunden müssen nichts tun.

MS
Marcel Schönfelder
IT-Freelancer & Inhaber

Mit KI erstellt – redaktionelle Prüfung ausstehend

Illustration: gesprungenes Schloss vor einem Server, aus dem Dokumente abfließen, mit der Headline Atlassian-Lücke wird angegriffen

Für die kritische Lücke CVE-2026-21589 in Atlassians selbst betriebenen Data-Center-Produkten laufen inzwischen echte Angriffsversuche. Der Sicherheitsdienstleister Previdian registrierte die ersten Zugriffe auf seine Honeypots rund zwei Stunden, nachdem watchTowr am 6. Oktober eine technische Analyse samt Proof of Concept veröffentlicht hatte. Betroffen sind alle Versionen von Jira Software, Jira Service Management, Confluence, Bitbucket, Bamboo, Crowd, Crucible und Fisheye im Data-Center-Betrieb, solange sie nicht auf einem der am 5. Oktober veröffentlichten Fix-Stände laufen.

Nicht betroffen sind Kunden der Atlassian Cloud: Atlassian hat die Cloud-Dienste nach eigenen Angaben bereits gepatcht und dort keine Ausnutzung gefunden. Wer dagegen eine der acht Anwendungen selbst hostet und sie aus dem Internet erreichbar macht, sollte heute aktualisieren oder die Instanz bis zum Update vom Netz nehmen. Das ältere Juni-Bulletin ist ein separates Ereignis.

Was ist passiert?

Atlassian hat am 5. Oktober 2026 ein eigenes Advisory zu CVE-2026-21589 veröffentlicht. Es handelt sich um eine Schwachstelle für beliebigen Dateizugriff: Ein nicht angemeldeter Angreifer kann bestimmte Dateien innerhalb des Wurzelverzeichnisses der Webanwendung abrufen. Er muss dafür Namen und Pfad der Zieldatei kennen, Verzeichnisse auflisten kann er nicht. In manchen Konfigurationen liegen dort laut Atlassian sensible Dateien.

Einen Tag später legte watchTowr die Ursache offen. Laut Analyse wandelt eine gemeinsam genutzte Web-Resource-Bibliothek doppelte Doppelpunkte in Schrägstriche um. Über Plugin-Ressourcen unter /download/resources/ lassen sich so Pfade wie ..::..::WEB-INF::web.xml bauen, die geschützte Dateien der Anwendung ohne Anmeldung liefern. Aus dem Tomcat-Anwendungskontext kamen die Forscher nach eigenen Angaben nicht heraus. Seit dem 7. Oktober erleichtert laut Previdian ein Nuclei-Template das automatisierte Scannen.

Wer ist betroffen?

Betroffen sind alle Versionen vor den folgenden Fix-Ständen, die Atlassian im Advisory nennt:

  • 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: jeweils 4.9.15

Besonders exponiert sind Jira-Installationen, die an Crowd angebunden sind. Dort liegt in WEB-INF/classes/crowd.properties das Anwendungskennwort für Crowd im Klartext. watchTowr nutzte diese Zugangsdaten im Test, um über die Crowd-API einen neuen Benutzer anzulegen und ihn in die Jira-Administratorengruppe zu heben. Voraussetzung ist, dass Crowd für den Angreifer erreichbar ist.

Wie kritisch ist das?

Atlassian bewertet die Lücke mit CVSS 4.0 9.3 als kritisch. Technisch ist sie zunächst ein Datenabfluss ohne Anmeldung, keine direkte Codeausführung. Gefährlich wird sie durch lesbare Tokens, Schlüssel und Zugangsdaten. Previdian führt die Ausnutzung als bestätigt und meldete mit Stand 9. Oktober 221 Versuche von 38 IP-Adressen aus 13 Ländern. SecurityWeek hatte am 8. Oktober noch 190 Versuche von 32 Adressen gezählt, die Aktivität wächst also weiter. Erfolgreich kompromittierte Kundeninstanzen sind öffentlich bislang nicht belegt. In den KEV-Katalog der CISA ist die Lücke mit Stand 8. Oktober nicht aufgenommen. Fazit: Aus dem Internet erreichbare Instanzen heute patchen, rein interne Systeme in den nächsten Tagen statt im Monatszyklus.

Was sollten Admins jetzt tun?

  • Alle selbst betriebenen Atlassian-Instanzen inventarisieren, einschließlich Bitbucket-Mirrors und Testsystemen, und die laufende Version mit den Fix-Ständen oben abgleichen.
  • Aus dem Internet erreichbare Systeme zuerst aktualisieren. Binärpatches gibt es nicht.
  • Ist kein sofortiges Update möglich, die Instanz vom Internet trennen oder eine der Übergangslösungen aus dem Advisory umsetzen: die WAF- beziehungsweise Proxy-Regex, die Tomcat-RewriteValve-Regel für Confluence, Jira, JSM, Bamboo und Crowd oder die Regel in urlrewrite.xml für Bitbucket. In Clustern gilt das für jeden Knoten.
  • Zugriffslogs rückwirkend ab dem 5. Oktober prüfen. Atlassian rät, jede Zeile bis zu zweimal zu URL-dekodieren und nach zwei Punkten direkt neben einem Schrägstrich, Backslash oder :: zu suchen. Anfragen auf /download/resources/ mit ..:: sind ein deutliches Indiz.
  • Bei Jira mit Crowd-Anbindung und Auffälligkeiten im Log das Crowd-Anwendungskennwort wechseln, die Administratorgruppen in Jira und Crowd auf unbekannte Konten prüfen und eine IP-Allowlist für die Anwendung in Crowd setzen.
  • Die von Previdian gemeldeten Quell-IPs am Perimeter sperren. Das ersetzt das Update nicht.

Einordnung für Unternehmen

Viele Mittelständler betreiben Jira und Confluence weiterhin selbst, oft aus Datenschutzgründen. Genau diese Installationen sind jetzt das Ziel. Zwischen öffentlichem Exploit und ersten Scans lagen hier zwei Stunden; wer Wiki und Ticketsystem direkt im Internet betreibt, hat faktisch kein Zeitfenster mehr. Mittelfristig sollten Admins klären, ob Jira und Confluence öffentlich erreichbar sein müssen oder ob VPN oder ein vorgeschalteter Login am Reverse Proxy reichen.

Passende Anleitungen auf S-EDV

Quellen

AtlassianJiraConfluenceBitbucketCVE-2026-21589SicherheitslückeData Center
Verwandt

Weiter lesen

Alle Artikel →
Hero-Grafik: Warpgate als Bastion-Host mit SSH, HTTP und Datenbank
09.10.2026 ·10 min

Warpgate mit Docker Compose: SSH-, HTTP- und Datenbank-Bastion ohne Client-Agent

Warpgate leitet SSH-, HTTP-, MySQL- und PostgreSQL-Verbindungen über einen zentralen Bastion-Host, ohne Software auf den Clients. Die Anleitung zeigt Einrichtung mit Docker Compose, Ziele, Rollen, Backup, Restore und Update.
Illustration mit Schutzschild, Schlüssel und Richtlinienschaltern zur neuen Windows-Baseline mit Adminschutz
09.10.2026 ·4 min

Windows 11 26H2: Security Baseline v2 schaltet Administrator Protection ein

Microsoft hat das Security Baseline für Windows 11 26H2 als v2-Paket neu veröffentlicht. Es aktiviert Administrator Protection mit Anmeldeabfrage bei jeder Rechteerhöhung, bevorzugt IPP-Druckertreiber und erlaubt nur noch TLS 1.2 und 1.3. Wer die Baselines per GPO oder Intune verteilt, sollte Grenzen wie fehlendes SSO, Netzlaufwerke und AVD vorab im Pilotring prüfen.
Illustration: mehrere KI-Agenten als Würfel in einer Cloud, einer ist aufgebrochen und gibt einen Schlüssel frei, Headline KI-Agenten übernommen
09.10.2026 ·4 min

Amazon Bedrock AgentCore: Ein Prompt reichte zur Übernahme aller KI-Agenten

Über den Metadatendienst gab ein AgentCore-Agent auf einen einzigen Prompt hin seine AWS-Zugangsdaten heraus. Mit der regionsweit gültigen Standardrolle konnten Forscher von Zenity Labs alle Agenten derselben Region übernehmen, private Gespräche lesen, das Gedächtnis vergiften und Secrets abrufen. AWS hat nachgebessert, Admins sollten Rollen und ältere Deployments trotzdem prüfen.