Atlassian-Schwachstellen: CVSS 9,8 – Lücke wird ausgenutzt

Sechs Atlassian-Produkte und ein Base Score von 9,8: Mehrere Atlassian-Schwachstellen in Bamboo, Bitbucket, Confluence, Crucible, Fisheye und Jira sind in WID-SEC-2026-4056 vom 21. Oktober 2026 gebündelt. Ein Angriff aus der Ferne ist möglich, für jeden genannten Produktzweig existiert eine Fix-Version. Dringend wird die Lage durch eine Lücke, die seit dem 15. Oktober 2026 in der CISA-KEV-Datenbank steht.

Der temporale Score liegt bei 8,5, betroffen sind Linux, UNIX, Windows und sonstige Serverumgebungen. Die beschriebene Wirkung reicht von Datenmanipulation und der Offenlegung von Informationen über Cross-Site Scripting und Privilegienerhöhung bis zu Denial of Service und der Ausführung beliebigen Programmcodes.

Atlassian-Schwachstellen: Diese Versionen sind betroffen

Die genannten Schwellen sind keine vagen Empfehlungen, sondern Fix-Versionen. Wer darunter liegt, muss aktualisieren.

In WID-SEC-W-2026-3755 vom 5. und 6. Oktober 2026 sind 15 Produkte aufgeführt, darunter zusätzlich Jira Software unter 9.12.40 sowie Jira Service Management unter 11.3.12, 10.3.26 und 5.12.40. Wer Jira Service Management betreibt, sollte die eigene Version deshalb gesondert prüfen – in der aktuellen Liste taucht der Zweig nicht auf.

CVE-2026-21589: Dateien ohne Anmeldung lesbar

Hinter der dringlichsten Einzellücke steckt CVE-2026-21589: Ein nicht authentifizierter Angreifer kann auf bestimmte Dateien im Web-Application-Root zugreifen. Der Score liegt bei 9,3. In der Praxis verlangt die Lücke die exakte Kenntnis des Dateipfads, ein Directory Listing gibt es nicht – das senkt das Risiko eines blinden Massenangriffs, nicht aber das einer gezielten Attacke auf eine bekannte Installation.

Selbst betriebene Instanzen sind betroffen, Atlassian Cloud dagegen nicht. Eine CVE-Nummer ist nicht genannt; die Zuordnung zu CVE-2026-21589 stützt sich auf die deckungsgleichen Versionsschwellen und eine explizite Verknüpfung in der maschinenlesbaren Aufbereitung. Die Score-Werte bleiben dabei unterschiedlich: 9,8 für die gebündelte Warnung, 9,3 für die Einzellücke, „CRITICAL" als Einstufung vom 12. Oktober 2026. Wer die Zahlen nebeneinanderlegt, sollte sie nicht zu einem einzigen Wert glätten.

Ausnutzung: vom fehlenden Nachweis zum KEV-Eintrag

Am 8. Oktober 2026 war keine Ausnutzung nachgewiesen (ThaiCERT). Am 15. Oktober 2026 waren die Ausnutzung in der Wildnis und die Aufnahme in die CISA-KEV-Datenbank bestätigt. Das ist kein Widerspruch, sondern eine Frage des Zeitpunkts: fehlende Nachweise sind kein Nachweis der Abwesenheit.

Lücken in der KEV-Liste gelten als tatsächlich ausgenutzt; US-Bundesbehörden müssen sie binnen einer gesetzten Frist schließen. Für europäische Betreiber ist das kein bindender Rahmen, aber ein belastbares Signal: Der Exploit existiert, er ist nicht mehr theoretisch, und die Wahrscheinlichkeit, dass Nachahmer nachziehen, steigt mit jedem Tag ohne Patch.

Warum die Lücken DevSecOps-Teams treffen

Bitbucket ist ein Git-Server, Bamboo ein CI/CD-Werkzeug, Confluence ein Wiki für interne Dokumentation, Jira die Steuerzentrale der Softwareentwicklung. Diese Systeme stehen selten isoliert: Sie hängen an Build-Agenten, Deployment-Pipelines und Identitätsverzeichnissen. Wer dort Dateien lesen oder Code ausführen kann, landet fast immer auf einem Host mit Netzwerkzugriff auf weitere interne Dienste – und trifft auf Zugangsdaten, die für Automatisierung hinterlegt wurden. Genau das macht eine Lücke mit Datei- oder Codezugriff in dieser Produktfamilie unangenehmer als ihr Score vermuten lässt.

Was Admins jetzt tun sollten

Priorität eins ist das Update auf die genannten Fix-Versionen, beginnend mit öffentlich erreichbaren Instanzen. Ist ein sofortiger Patch nicht möglich, sind Übergangslösungen verfügbar: eine WAF-Regel per Regex, ein Tomcat-RewriteValve und eine urlrewrite.xml-Regel für Bitbucket. Diese Regeln filtern die bekannten Angriffsmuster, sie ersetzen den Patch nicht.

Bei Instanzen, die vor dem Update aus dem Internet erreichbar waren, ist eine Prüfung auf Kompromittierung sinnvoll – auffällige Zugriffe auf Dateien außerhalb der erwarteten Pfade, ungewöhnliche Prozesse auf dem Applikationsserver, neue Konten. Wer mehrere Produkte der Familie betreibt, sollte den Patch-Stand je Instanz getrennt erfassen; die Versionszweige laufen auseinander, und LTS-Installationen bleiben oft länger unangetastet als geplant.

Fazit

Die technischen Voraussetzungen für einen Angriff sind eng, die Einstufung ist es nicht: 9,8 auf der Sammelwarnung, 9,3 für die Einzellücke, dazu ein KEV-Eintrag und eine Wildnis-Ausnutzung seit Mitte Oktober. Wer Bitbucket, Confluence oder Jira selbst betreibt, hat jetzt zwei Aufgaben – patchen und anschließend prüfen, ob der Patch zu spät kam. Atlassian Cloud ist nicht betroffen, was den Kreis der Betroffenen verkleinert, aber nicht die Dringlichkeit für die verbleibenden Instanzen.

Quellen

1. BSI Security Advisor – WID-SEC-2026-4056
2. CERT-EU Security Advisory 2026-015 – Critical Vulnerability in Multiple Atlassian Products
3. Canadian Centre for Cyber Security – Atlassian security advisory (AV26-1002), Update 2
4. ThaiCERT – Atlassian Product Vulnerability Could Allow Unauthorized Access to System Files
5. Vulnerability-Lookup (CIRCL) – WID-SEC-W-2026-3755