SEKurity GmbH Logo
CVE-Forschung

InSEKurity of the Week (CW41/2026): Atlassian Data Center Pre-Auth Arbitrary File Read (CVE-2026-21589)

Ein unauthentifizierter Request an Jira, Confluence oder Bitbucket liest Dateien aus dem Webapp-Root -- inklusive WEB-INF, wo crowd.properties Klartext-Zugangsdaten preisgibt und daraus Admin auf der Instanz wird. CVSS 9.3, acht Produkte, alle Versionen, Angriffsversuche binnen Stunden nach dem oeffentlichen Writeup.

SEKurity Team

Offensive Security Experten

16 Min. Lesezeit
Teilen:

Diese Woche in unserer InSEKurity of the Week-Reihe: die Schwachstelle, die Ihre Geheimnisse aus genau dem Verzeichnis liest, das eine Webanwendung niemals ausliefern soll. Am 5. Oktober 2026 veröffentlichte Atlassian ein außerplanmäßiges Advisory zu CVE-2026-21589, einer Arbitrary-File-Access-Schwachstelle, die acht der selbstgehosteten Data-Center- und Server-Produkte betrifft — Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible und Fisheye. Bewertet mit CVSS 4.0 9.3, ohne Authentifizierung ausnutzbar und für alle bisherigen Versionen jedes dieser Produkte gültig.

Das Advisory ist vorsichtig in der Beschreibung: Ein Angreifer kann eine bestimmte Datei innerhalb des Web-Application-Roots lesen, wenn er deren exakten Namen und Pfad kennt, kann aber keine Verzeichnisse auflisten. Diese Formulierung untertreibt. Der Web-Application-Root umfasst WEB-INF, das Java-Servlet-Verzeichnis, in dem die Konfiguration liegt — und in gängigen Deployments auch Zugangsdaten. Unabhängige Forschung, die einen Tag nach dem Advisory veröffentlicht wurde, führte die Kette von “eine bekannte Datei lesen” über Crowd-Application-Zugangsdaten im Klartext bis zu Administrator auf der Instanz — ganz ohne Login.

Was dies zu einer InSEKurity statt einer Fußnote macht, sind die Verbreitung und die Uhr. Jira und Confluence sind das Standard-System-of-Record und die Build-Pipeline für einen sehr großen Anteil der Enterprise-IT. Atlassian veröffentlichte das Advisory außer der Reihe, nicht im üblichen Dienstags-Rhythmus. Und Angriffsversuche gegen Atlassian Data Center wurden binnen Stunden nach dem öffentlichen technischen Writeup gemeldet — der Abstand zwischen “Patch verfügbar” und “wird abgeklopft” betrug einen einzigen Arbeitstag.

🚨 Zusammenfassung

  • CVE-ID: CVE-2026-21589
  • CVSS-4.0-Score: 9.3 Critical (von Atlassian bewertet)
  • CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory (“Path Traversal”)
  • Vendor-Advisory: Außerplanmäßiges Atlassian-Advisory, veröffentlicht 2026-10-05
  • Betroffene Software: Bitbucket, Confluence, Jira Software, Jira Service Management, Bamboo, Crowd, Crucible und Fisheye — Data-Center- und Server-Editionen, alle bisherigen Versionen
  • Angriffsvektor: Netzwerk — überall dort, wo das Web-Interface antwortet
  • Authentifizierung erforderlich: Keine
  • Root Cause: Eine Path-Traversal-Sequenz überlebt den Request. Gemeinsam genutzter Web-Resource-Code wandelt :: in / um, und zwar nachdem der Request die Edge-Filterung passiert hat — ein als ..::..:: kodierter Traversal erreicht damit einen File-Read-Sink, ohne an slash-basierten Prüfungen aufzulaufen
  • Impact: Unauthentifiziertes Lesen von Dateien im Webapp-Root, inklusive WEB-INF. In Crowd-integrierten Deployments kann dies Klartext-Application-Zugangsdaten offenlegen, die sich über Crowds REST-API zu Administrator-Zugriff verketten
  • Patch-Status: Verfügbar — Fixed Releases für alle acht Produkte ausgeliefert (Tabelle unten)
  • Cloud: Nicht betroffen / bereits gepatcht. Atlassian-Cloud-Kunden müssen nichts unternehmen
  • Workarounds: Atlassian hat temporäre Mitigations veröffentlicht; sie ersetzen das Patchen nicht
  • Exploitation-Status: Angriffsversuche in freier Wildbahn beobachtet kurz nach Veröffentlichung der technischen Details; ein Detection-Tool und öffentliche Analysen existieren
  • CISA KEV: Zum Zeitpunkt des Schreibens nicht gelistet
  • Was die meisten übersehen: Das Advisory sagt “bestimmte Dateien”, was nach geringer Schwere klingt. Die bestimmte Datei, auf die es ankommt, ist WEB-INF/classes/crowd.properties, und auf einer Crowd-integrierten Instanz reicht diese eine Datei, um Admin zu werden

🖥️ Was ist Atlassian Data Center?

Atlassian Data Center (und die inzwischen weitgehend eingestellte Server-Linie) ist die selbstgehostete Edition der Atlassian-Produktsuite. Während Atlassian Cloud die Software für Sie betreibt, läuft Data Center auf Infrastruktur, die Ihnen gehört — hinter Ihrer Firewall, auf Ihrem Tomcat, mit Ihrer Datenbank. Organisationen wählen es aus Gründen von Datenresidenz, Regulatorik und Latenz, was bedeutet, dass Data-Center-Instanzen überproportional Banken, Behörden, Rüstungsunternehmen und Großunternehmen gehören: genau den Orten, an denen der Inhalt von WEB-INF das Stehlen wert ist.

Die acht betroffenen Produkte decken den Großteil des Bindegewebes einer Engineering-Organisation ab:

  • Jira Software / Jira Service Management — Issue-Tracking, Projektmanagement und IT-Service-Desk; das System-of-Record dafür, was eine Organisation baut und was kaputt ist.
  • Confluence — das Wiki und die Wissensdatenbank; in der Praxis der Ort, an dem sich Zugangsdaten, Runbooks, Architekturdiagramme und Incident-Notizen ansammeln.
  • Bitbucket — Git-Hosting und Source-of-Truth für Code und CI-Konfiguration.
  • Bamboo — Continuous Integration und Deployment.
  • Crowd — zentrale Identität und Single Sign-On für die anderen Produkte, oft auch für Drittanwendungen.
  • Crucible / Fisheye — Code-Review und Repository-Browsing.

Typische Einsatzszenarien

  • Hosting von Quellcode, Build-Pipelines und Deployment-Automatisierung on-premises
  • Zentralisierung von Benutzerverzeichnissen und SSO über das Atlassian-Estate hinweg via Crowd
  • Betrieb eines IT- und Kundenservice-Desks auf Jira Service Management
  • Ablage interner Dokumentation, inklusive sensibler Betriebsdetails, in Confluence

Warum ein File Read hier anders ist

Ein Pre-Auth Arbitrary File Read auf einer Broschüren-Website ist ein Informationsleck. Ein Pre-Auth File Read auf einem Crowd-integrierten Jira ist eine Offenlegung von Zugangsdaten, die zu Identity-Provider-Zugriff führt, denn die Aufgabe des Produkts ist es, die Schlüssel zu allem anderen zu halten. Die Schwere dieser Fehlerklasse wird fast ausschließlich davon bestimmt, was in dem Verzeichnis liegt, das der Angreifer jetzt erreichen kann — und auf einem gewachsenen Atlassian-Deployment ist dieses Verzeichnis voll.

🔍 Technische Analyse

Beschreibung der Schwachstelle

CVE-2026-21589 ist ein unauthentifizierter Path Traversal in einer Komponente, die über die Atlassian-Produktlinie hinweg geteilt wird und über die Static-Resource-Download-Endpunkte exponiert ist, die jedes Produkt zum Ausliefern von CSS, JavaScript und Bildern nutzt. Weil der Fehler im geteilten Web-Resource-Handling steckt und nicht in einem einzelnen Produkt, tritt eine einzige Root Cause gleichzeitig in allen acht betroffenen Produkten auf, unter leicht unterschiedlichen URL-Präfixen.

Root-Cause-Analyse

  1. Geteilter Resource-Router. Die Komponente atlassian-plugins-webresource löst Static-Resource-Requests auf. Um Pfadsegmente sicher innerhalb eines einzelnen URL-Segments zu transportieren, escaped sie / als :: und unescaped :: später wieder zu /.
  2. Unescaping passiert nach der Filterung. Der Unescape-Schritt läuft auf benutzergelieferten Pfadsegmenten innerhalb der Anwendung, nachdem der Request bereits jegliche Edge-Filterung passiert hat, die nach /, \ oder klassischem ../ sucht. Ein als ..::..:: geschriebener Traversal enthält keinen Slash, der an der Edge abgefangen würde, und wird erst zu ../../, nachdem der Router ihn bereits akzeptiert hat.
  3. Wirkungslose Sanitisierung am Sink. Der veraltete Resource-Serving-Pfad, der diese Requests behandelt, versucht, Traversal zu entfernen, berücksichtigt dabei aber die ::-Kodierung nicht, sodass die normalisierten ../-Sequenzen bis zur File-Read-Operation überleben.
  4. Ein Resource-Mapping, das an einem echten Verzeichnis verankert ist. Eine eingebaute Plugin-Ressource mappt einen images/-Pfad auf ein festes lokales Verzeichnis mit abschließendem Slash und gibt dem Traversal einen konkreten Ankerpunkt, von dem aus er aus dem vorgesehenen Verzeichnis heraus- und nach WEB-INF hineinklettern kann.

Das Nettoresultat ist ein Lehrbuch-CWE-22: Benutzereingaben entscheiden, welche Datei auf der Platte der Server liest, und die Kontrolle, die ihn auf ein sicheres Verzeichnis beschränken sollte, tut es nicht.

Angriffsvektor

Die öffentliche Forschung von watchTowr demonstrierte die Kette gegen Jira, Confluence und Bitbucket, jeweils über das eigene Static-Resource-Download-Präfix. Die Gestalt eines Requests — hier zum Verständnis und zur Detection gezeigt, nicht als Copy-paste-Exploit — ist ein normal aussehender Resource-Download, dessen letztes Pfadsegment den ::-kodierten Traversal nach WEB-INF trägt:

# ILLUSTRATIV -- Request-GESTALT nur zur Detection und Log-Auswertung.
# Basiert auf oeffentlicher watchTowr-Forschung; KEIN funktionsfaehiger Exploit.
# Das zu suchende Signal ist die Kombination aus einem /download/resources/-
# Pfad, "::"-kodiertem Traversal und einem WEB-INF-Ziel in einem Request.

GET /download/resources/<plugin-key>/images/..::..::..::..::WEB-INF::web.xml HTTP/1.1
Host: jira.example.com

Der Angreifer muss den exakten Pfad der gewünschten Datei kennen — der Bug liest eine benannte Datei, er listet keine Verzeichnisse auf. In der Praxis ist das kaum eine Hürde, weil die interessanten Dateien an wohlbekannten, produktstandard-konformen Pfaden liegen:

  • WEB-INF/web.xml — bestätigt, dass der Read funktioniert, und zeigt das App-Layout.
  • WEB-INF/classes/crowd.properties — hält auf einer Crowd-integrierten Instanz den Application-Namen, die Crowd-URL und ein Klartext-Application-Passwort.

Ausnutzung in freier Wildbahn

  • 2026-10-05 — Atlassian veröffentlicht das Advisory außer der Reihe und liefert Fixes aus.
  • 2026-10-06 — Öffentliche technische Analyse wird veröffentlicht, inklusive eines Detection-Artifact-Generators.
  • Binnen Stunden nach den öffentlichen Details melden Security-Anbieter Angriffsversuche gegen Atlassian-Data-Center-Instanzen. Die Forschung selbst vermerkte zum Zeitpunkt der Veröffentlichung keine bestätigte Ausnutzung in freier Wildbahn; Meldungen über Versuche folgten rasch danach — das ist das Muster, auf das man sich einstellen sollte.
  • Keine CISA-KEV-Listung zum Zeitpunkt des Schreibens, und keine Bestätigung von Atlassian, dass eine Data-Center-Instanz erfolgreich ausgenutzt wurde — Atlassians eigene Hinweise lauten, man könne es nicht ausschließen und Kunden sollten auf Kompromittierungsspuren prüfen.

Post-Exploitation-Impact

  1. Offenlegung von WEB-INF-Inhalten — Konfigurationsdateien und alles andere, was eine Anwendung zufällig in ihrem Servlet-Verzeichnis ablegt.
  2. Klartext-Crowd-Application-Zugangsdaten aus crowd.properties auf integrierten Deployments.
  3. Crowd-REST-API-Zugriff mit diesen Zugangsdaten — die Forschung nutzte ihn, um einen Benutzer anzulegen und ihn der Gruppe jira-administrators hinzuzufügen.
  4. Administrator auf dem Atlassian-Produkt, erreicht ohne einen einzigen gültigen Login, falls Crowd von der Position des Angreifers aus erreichbar ist.
  5. Nachgelagerte Offenlegung dessen, was das kompromittierte Produkt verwaltet: Quellcode und CI-Secrets in Bitbucket/Bamboo, Betriebsdokumentation und Secrets in Confluence, Ticketing- und Kundendaten in Jira.

📊 Impact-Bewertung

Unmittelbarer Impact

  • Unauthentifizierter, remote ausnutzbarer File Read mit geringer Komplexität gegen den Webapp-Root jeder ungepatchten Instanz, die im Netzwerk antwortet.
  • Offenlegung von Zugangsdaten überall dort, wo sensible Dateien im Webroot liegen — crowd.properties ist die Schlagzeile, aber jedes Secret, das ein Betreiber unter WEB-INF abgelegt hat, fällt in den Scope.
  • Eskalation zu Instanz-Admin auf Crowd-integrierten Deployments, bei denen Crowds REST-API erreichbar ist.
  • Keine Authentifizierungs-Logs, die helfen — der Request authentifiziert sich nie, also erscheint er nicht in Ihren Login- oder Audit-Trails. Der Beweis steckt im Web-/Access-Log, nicht im Application-Audit-Log.

Betroffene Versionen

Alle bisherigen Versionen jedes Produkts sind betroffen. Fixed Releases:

ProduktFixed-Versionen
Bitbucket Data Center9.4.26, 10.2.8, 10.5.1
Confluence Data Center9.2.26, 10.2.19
Jira Software Data Center9.12.40, 10.3.26, 11.3.12
Jira Service Management Data Center5.12.40, 10.3.26, 11.3.12
Bamboo Data Center10.2.24, 12.1.12
Crowd Data Center6.3.7, 7.0.3, 7.1.7, 7.2.4
Crucible4.9.15
Fisheye4.9.15

Atlassian-Cloud-Produkte sind nicht betroffen und wurden bereits gepatcht.

Betroffene Umgebungen

  • Selbstgehostetes Atlassian Data Center / Server eines der acht Produkte, in jeder Version vor den obigen Fixes.
  • Internet-exponierte Instanzen sind am stärksten gefährdet, aber jede Instanz, die von einem Angreifer mit bestehendem Fuß in der Tür (User-VLAN, VPN, kompromittierte Workstation) erreichbar ist, ist exponiert — der Bug braucht keine Zugangsdaten.
  • Crowd-integrierte Deployments tragen das zusätzliche Eskalationsrisiko, besonders dort, wo Crowd nicht per IP-Allowlist beschränkt ist.

Angreiferprofile

  • Opportunistische Akteure, die internetweite Scans nach /download/resources/-Traversal fahren und crowd.properties im großen Stil einsammeln, sobald ein PoC kursiert.
  • Ransomware-Affiliates und Access Broker, für die Admin auf einem Jira-/Confluence-/Bitbucket-Estate sowohl ein Datendiebstahl-Ziel als auch ein Sprungbrett ist.
  • Gezielte Intrusion-Sets, die am spezifischen Quellcode, an Tickets und Dokumentation interessiert sind, die eine bestimmte Organisation in Atlassian hält — die Data-Center-Population tendiert genau zu diesen Zielen.

🛡️ Mitigationsstrategien

Sofortmaßnahmen (Priorität 1)

  1. Jede betroffene Instanz und ihre Version identifizieren. Vergleichen Sie die gemeldete Produktversion mit der Fixed-Release-Tabelle oben. Diese REST-Endpunkte geben die laufende Version zurück und sind häufig ohne Authentifizierung erreichbar — nutzen Sie sie zur schnellen Inventarisierung:

    # Jira -- serverInfo gibt die laufende Version als JSON zurueck.
    # -s still, -k nur falls Sie auf einem internen Host die TLS-Pruefung ueberspringen muessen.
    curl -s https://jira.example.com/rest/api/2/serverInfo | grep -o '"version":"[^"]*"'
    
    # Confluence -- das applinks-Manifest exponiert <version> in seinem XML.
    curl -s https://confluence.example.com/rest/applinks/latest/manifest | grep -o '<version>[^<]*</version>'
    
    # Bitbucket -- application-properties gibt den Versionsstring zurueck.
    curl -s https://bitbucket.example.com/rest/api/1.0/application-properties | grep -o '"version":"[^"]*"'
  2. Auf ein Fixed Release aktualisieren für jedes Produkt (Tabelle oben). Das ist der einzige Fix; die temporären Mitigations kaufen Zeit, sie schließen das Loch nicht.

  3. Öffentlich erreichbare Instanzen vom öffentlichen Internet nehmen, bis gepatcht, wie Atlassian empfiehlt — einschließlich Instanzen hinter einer Login-Seite, denn dieser Bug braucht den Login nicht.

  4. Atlassians veröffentlichte temporäre Mitigations anwenden auf allem, was Sie nicht sofort patchen können, exakt wie im Advisory beschrieben. Beachten Sie: Naive WAF-Regeln, die nur auf /, \ oder ../ triggern, fangen die ..::..::-Kodierung nicht von sich aus; verlassen Sie sich auf die aktuelle Vendor-Guidance, nicht auf einen selbstgebauten Slash-Filter.

Detection-Maßnahmen

Der Bug hinterlässt seine Spur im Web-/Access-Log, nicht im Application-Audit-Log, weil der Request sich nie authentifiziert. Suchen Sie nach Resource-Download-Requests, die Traversal tragen oder WEB-INF erreichen:

# Tomcat-/Reverse-Proxy-Access-Logs nach der Exploit-GESTALT durchsuchen:
# ein /download/resources/-Request mit "::"-kodiertem Traversal,
# einem klassischen "../" oder einer expliziten WEB-INF-Referenz.
# -E Extended Regex, -i case-insensitive, -r rekursiv durch das Log-Verzeichnis.
grep -E -i -r '/download/resources/.*(::|\.\.|%2e%2e|WEB-INF)' /var/atlassian/*/logs/
# Splunk SPL -- dieselbe Frage ueber Web-Access-Logs mit Index "web".
# Index, Feldnamen und Host-Filter durch Ihre eigenen ersetzen.
index=web uri_path="/download/resources/*"
  (uri="*::*" OR uri="*..*" OR uri="*WEB-INF*")
| stats count AS hits, values(status) AS statuses, earliest(_time) AS first_seen
        BY src_ip, uri
| sort - hits
# Microsoft Sentinel / Defender KQL -- normalisierte Web-Logs.
# Tabelle und Spaltennamen an Ihr Schema anpassen.
W3CIISLog
| where csUriStem startswith "/download/resources/"
| where csUriQuery has "::" or csUriStem has ".." or csUriStem has "WEB-INF"
| summarize Hits = count(), FirstSeen = min(TimeGenerated) by cIP, csUriStem
| order by Hits desc

Führen Sie den öffentlichen Detection-Artifact-Generator aus (watchTowr veröffentlichte watchTowr-vs-Atlassian-CVE-2026-21589) gegen Ihre eigenen Instanzen, um den Patch-Stand zu bestätigen, und wenn Sie eine Exposition vermuten, rotieren Sie das Crowd-Application-Passwort und jedes Secret, das unter WEB-INF lag — eine Datei, die lesbar war, muss als gelesen behandelt werden.

Langfristige Sicherheitsverbesserungen

  1. Das Atlassian-Estate als Tier-0-nah behandeln. Crowd ist ein Identity Provider; Bitbucket hält Ihren Quellcode und Ihre CI-Secrets; Confluence hält Ihr Betriebswissen. Überwachen, segmentieren und change-controllen Sie sie entsprechend, nicht als “interne Web-Apps”.
  2. Instanzen niemals standardmäßig ins offene Internet stellen. Data Center ist gerade deshalb selbstgehostet, damit Sie die Exposition kontrollieren; erreichen Sie es über VPN oder einen Reverse-Proxy mit vorgelagerter Authentifizierung, nicht über einen öffentlichen DNS-Eintrag.
  3. Crowd per IP-Allowlist beschränken. Der Eskalationspfad in dieser CVE hängt davon ab, dass Crowds REST-API erreichbar ist. Einzuschränken, welche Hosts Crowd aufrufen dürfen, verwandelt ein Credential-Leck in eine Sackgasse.
  4. Secrets aus WEB-INF heraushalten, wo möglich, und inventarisieren, was dort liegt, wo nicht. Der Blast Radius jedes File-Read-Bugs ist das, was Sie im Webroot hinterlassen haben.
  5. Web-/Access-Logs in Echtzeit vom Host wegschicken. Die einzige Spur dieses Angriffs liegt in Logs, die ein Angreifer mit File Read nicht sehen kann — die ein Angreifer, der später Admin wird, aber schon. Zentralisiertes, append-only Logging bewahrt die Beweise.
  6. Atlassian-Security-Advisories abonnieren und an jemanden routen, der einen Notfall-Patch einplanen kann. Ein außerplanmäßiges Advisory ist der Vendor, der Ihnen sagt, nicht auf das Wartungsfenster zu warten.

⚠️ Warum ist das kritisch?

  1. Unauthentifiziert und geringe Komplexität. Ein präparierter Request, keine Zugangsdaten, von überall dort, wo die Instanz antwortet.
  2. Acht Produkte, alle Versionen. Der übliche Triage-Schritt, bei dem sich die Hälfte des Estates als nicht betroffen herausstellt, greift hier nicht.
  3. Es erreicht WEB-INF. Das eine Verzeichnis, das eine Java-Web-App niemals ausliefern darf, ist genau dort, wo der Traversal landet.
  4. “Eine Datei lesen” wird zu “Admin werden”. crowd.properties zu Klartext-Zugangsdaten zu Crowds REST-API zu jira-administrators ist eine dokumentierte, demonstrierte Kette.
  5. Die Verbreitung ist das Enterprise. Data Center ist dort, wo die regulierten, hochwertigen Organisationen ihren Code, ihre Tickets und ihre Dokumentation halten.
  6. Außerplanmäßige Veröffentlichung. Atlassian brach seinen eigenen Release-Rhythmus, was es nur tut, wenn es das Risiko als nicht aufschiebbar einschätzt.
  7. Das Fenster waren Stunden. Angriffsversuche wurden innerhalb eines Arbeitstags nach dem öffentlichen Writeup gemeldet. Es gab keine ruhige Phase zum Patchen.
  8. Es versteckt sich vor Ihrem Audit-Log. Der Request authentifiziert sich nie, also steckt der Beweis im Access-Log, nicht an der Stelle, an der die meisten Teams zuerst schauen.

📅 Timeline und Disclosure

  • 2026-10-05 — Atlassian veröffentlicht ein außerplanmäßiges Security-Advisory zu CVE-2026-21589 (CVSS 4.0 9.3) und liefert Fixed Releases für alle acht Produkte aus.
  • 2026-10-06 — watchTowr veröffentlicht die öffentliche technische Analyse, inklusive Root-Cause-Aufschlüsselung und einem Detection-Artifact-Generator; Help Net Security und weitere Medien berichten über das Advisory.
  • Kurz nach 2026-10-06 — Security-Anbieter melden Angriffsversuche gegen Atlassian-Data-Center-Instanzen in freier Wildbahn.
  • 2026-10-13 — Keine CISA-KEV-Listung; Atlassian hat keine erfolgreiche Data-Center-Kompromittierung bestätigt und rät Kunden, auf Anzeichen dafür zu prüfen.

📚 Ressourcen und Referenzen

🤝 SEKurity Unterstützt Sie

Es gibt eine wiederkehrende Gestalt in diesen Beiträgen: Das System, dem alles andere vertraut, stellt sich als das am wenigsten untersuchte im Gebäude heraus. Ein VPN-Konzentrator, eine NAC-Plattform und jetzt das Wiki, der Issue-Tracker und der Git-Host. Niemand plant einen Penetrationstest gegen Confluence, weil Confluence “nur das Wiki” ist — bis zu dem Moment, in dem es zum Verzeichnis wird, aus dem ein Angreifer Ihr Crowd-Passwort liest.

Die Fragen für Ihr Atlassian-Estate sind kurz und unbequem. Welche der acht Produkte betreiben Sie tatsächlich, und in welcher Version — jeder Knoten, nicht der eine, an den sich jemand erinnert? Welche davon sind aus dem Internet oder aus einem User-VLAN ohne vorgelagertes VPN erreichbar? Ist Crowd per IP-Allowlist beschränkt, oder kann jeder, der ein geleaktes Application-Passwort findet, dessen REST-API aufrufen? Und wenn das Access-Log letzte Woche einen /download/resources/-Request mit :: darin zeigte, hätte es jemand bemerkt?

Wir testen diese Systeme aus der Netzwerkposition, die ein Angreifer wirklich hätte — von innen, gegen das Appliance, das niemand für ein Testfenster offline nehmen will — und wir behandeln die Identity-Plane als den Preis, der sie ist. Wenn Ihr Confluence oder Jira noch nie aus einem nicht vertrauenswürdigen Segment betrachtet wurde, ist das die Lücke, die zu schließen sich lohnt, bevor das nächste außerplanmäßige Advisory eintrifft.

Unsere Leistungen

  • Penetration Testing: Webanwendungen, Mobile Apps (Android & iOS), SAP-Systeme, Active Directory
  • Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
  • Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.


Kontakt:

Website: www.sekurity.de

Anfragen: www.sekurity.de/kontakt

LinkedIn: SEKurity GmbH


Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Collaboration- und Identity-Infrastruktur ist unser Antrieb.


Quellen

Über den Autor

SEKurity Team

Offensive Security Experten

Das SEKurity GmbH Team besteht aus erfahrenen Penetrationstestern, Security-Forschern und Cybersecurity-Beratern. Unter dem Motto 'Your Trusted Adversaries' unterstützen wir Organisationen dabei, ihre IT-Sicherheit aus der Perspektive eines Angreifers zu bewerten und zu verbessern.

Verwandte Artikel