JFrog Artifactory: Angreifer verketten drei Schwachstellen und setzen Rust-Backdoor ein

Selbst gehostete Server von JFrog Artifactory stehen seit Mitte August 2026 unter aktivem Beschuss. Angreifer verketten mehrere Schwachstellen, um die Authentifizierung zu umgehen, sich Administratorrechte zu verschaffen und anschließend eine in der Programmiersprache Rust geschriebene Backdoor zu installieren. Der Cloud-Security-Anbieter Wiz hat die Angriffe in einem im September 2026 veröffentlichten Bericht beschrieben und bestätigt die Ausnutzung in mehreren Umgebungen. Wer eine eigene Artifactory-Instanz betreibt, muss den Patchstand heute prüfen und nicht erst im nächsten Wartungsfenster.

Handeln muss jeder, der Artifactory selbst hostet und dessen Weboberfläche oder API von außen oder aus einem größeren internen Netz erreichbar ist. Das gilt auch dann, wenn der anonyme Zugriff bewusst deaktiviert wurde, denn genau diese Annahme hält der Angriffskette nicht stand. Die Berichte beziehen sich ausdrücklich auf selbst gehostete Instanzen. Betreiber, die Artifactory ausschließlich als Cloud- oder SaaS-Dienst nutzen, sind nach der derzeitigen Berichtslage nicht Gegenstand dieser Meldung. Wer weder eine eigene Artifactory-Installation betreibt noch eine Build-Kette daran angebunden hat, muss nichts unternehmen.

Was ist passiert?

Nach den Beobachtungen von Wiz beginnt der Angriff mit CVE-2026-42018. Über diese Schwachstelle erlangen Angreifer ein JSON Web Token (JWT) des internen anonymen Artifactory-Nutzers, und zwar auch dann, wenn der anonyme Zugriff in der Konfiguration abgeschaltet ist. Dieses Token hat zunächst nur niedrige Rechte und wäre für sich genommen kaum gefährlich.

Der zweite Schritt macht daraus ein ernstes Problem. CVE-2026-42016 beschreibt eine unzureichende Token-Validierung. Angreifer tauschen das eingeschränkte Token gegen ein Admin-Token und stehen damit vollständig in der Registry. In einigen der von Wiz untersuchten Fälle vergingen zwischen dem ersten Zugriff und dem Anlegen eines Administratorkontos weniger als fünf Minuten.

Unabhängig davon existiert mit CVE-2026-82329 eine dritte, als kritisch eingestufte Lücke, die einen Authentifizierungs-Bypass erlaubt. Das Offensive-Security-Unternehmen watchTowr beobachtete Anfang September 2026, wie über diesen Weg ebenfalls Admin-Tokens erzeugt wurden. Der beobachtete Angriffszeitraum reicht vom 15. August bis zum 8. September 2026, und die Aktivität geht auf mehrere verschiedene Akteure zurück. Es handelt sich also nicht um eine einzelne Kampagne einer einzelnen Gruppe.

CVE	Art der Schwachstelle	Wirkung im Angriff
CVE-2026-42018	Ausgabe eines Tokens für den internen anonymen Nutzer	Einstieg mit niedrigen Rechten, auch bei deaktiviertem anonymem Zugriff
CVE-2026-42016	Unzureichende Token-Validierung	Tausch des schwachen Tokens gegen ein Admin-Token
CVE-2026-82329	Kritischer Authentifizierungs-Bypass	Direkte Erzeugung von Admin-Tokens, von watchTowr Anfang September 2026 beobachtet

Wer ist betroffen?

Betroffen sind selbst gehostete JFrog-Artifactory-Instanzen unterhalb der unten genannten Zielversionen. Wiz gibt an, dass zwischen 49 und 62 Prozent der erreichbaren Artifactory-Instanzen für mindestens eine der drei Lücken anfällig sind. Das ist eine sehr breite Angriffsfläche für ein System, das in vielen Unternehmen an zentraler Stelle in der Softwarelieferkette steht.

• Selbst betriebene Artifactory-Server in Rechenzentrum, Colocation oder eigener Cloud-VM.
• Instanzen, deren Oberfläche oder REST-API aus dem Internet erreichbar ist.
• Instanzen im internen Netz, die von vielen Build-Agents, Entwicklerrechnern oder Runnern erreicht werden.
• Cluster-Installationen, weil dort zusätzlich Cluster-Join-Keys im Spiel sind.
• Nach derzeitiger Berichtslage nicht Gegenstand der Meldung: reine Cloud- und SaaS-Nutzung von Artifactory.

Eine offene Frage bleibt die Reaktion des Herstellers. BleepingComputer hat JFrog um eine Bestätigung gebeten und bis Redaktionsschluss keine Antwort erhalten. Eine eigene öffentliche Einordnung des Herstellers zu den beobachteten Angriffen liegt damit nicht vor. Das ändert nichts an der Dringlichkeit der Updates, sollte aber bei der internen Bewertung offen benannt werden.

Wie kritisch ist das?

Die Lage ist ernst, weil drei Faktoren zusammenkommen: Es gibt eine funktionierende Kette bis zu vollen Administratorrechten, sie wird nachweislich aktiv genutzt, und das Ziel ist ein System mit hohem Vertrauensstatus. Eine Artifactory-Instanz verteilt Artefakte, Container-Images und Abhängigkeiten an Build-Systeme und Produktionsumgebungen. Wer sie kontrolliert, kann Software manipulieren, bevor sie überhaupt ausgeliefert wird.

Nach der Übernahme legten die Angreifer laut Wiz Administratorkonten und langlebige Access-Tokens an, installierten bösartige Groovy-Plugins zur Befehlsausführung und etablierten Persistenz über eine Rust-basierte Backdoor mit Command-and-Control-Funktionen. Die weiteren beobachteten Schritte zeigen ein klares Interesse an dauerhaftem Zugriff und an Daten:

• Nachladen von Payloads in die Verzeichnisse /dev/shm, /tmp und /var/tmp.
• Upload von Webshells für späteren Zugriff.
• Diebstahl von Artifactory-Konfigurationsdaten und Cluster-Join-Keys.
• Enumeration von Repositories, Tokens und Nutzern.
• Hinterlegen eigener SSH-Keys in neu angelegten Konten.
• Anlegen langlebiger Access-Tokens, die ein bloßes Update allein nicht entwertet.

Wichtig für die Bewertung: Ein Update schließt die Lücken, entfernt aber keine bereits angelegten Konten, Tokens, Plugins oder SSH-Keys. Wer nur patcht und danach nichts prüft, kann einen Angreifer mit gültigen Zugangsdaten im System behalten.

Was sollten Admins jetzt tun?

Die folgenden Schritte sind nach Dringlichkeit sortiert. Punkt eins und zwei gehören in die laufende Woche, die Prüfschritte danach direkt im Anschluss an das Update.

1. Version feststellen. Ermitteln Sie für jede selbst gehostete Instanz die genaue Artifactory-Version und notieren Sie, ob die Oberfläche oder API von außen erreichbar ist.
2. Sofort aktualisieren. Ziel sind die Versionen 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 oder 7.161.20, jeweils diese oder neuer. Welche Zeile passt, hängt vom eingesetzten Release-Zweig ab.
3. Administratorkonten auditieren. Suchen Sie nach unbekannten Administratorkonten und nach Konten, die im Zeitraum ab dem 15. August 2026 entstanden sind.
4. Tokens prüfen und rotieren. Achten Sie auf unerwartete Token-Erstellung und auf langlebige Access-Tokens. Nicht zuordenbare Tokens widerrufen.
5. Groovy-Plugins kontrollieren. Prüfen Sie das Plugin-Verzeichnis auf unbekannte oder kurzfristig hinzugefügte Groovy-Plugins und auf verdächtige Plugin-Aktivität in den Logs.
6. SSH-Keys prüfen. Kontrollieren Sie hinterlegte SSH-Keys, insbesondere in neu angelegten Konten, und entfernen Sie nicht zuordenbare Schlüssel.
7. Auf Enumeration und Dateiablagen achten. Suchen Sie in den Logs nach auffälligen Enumerations-Requests auf Repositories, Tokens und Nutzer und prüfen Sie /dev/shm, /tmp und /var/tmp auf unerwartete Dateien.
8. Zugriff einschränken. Beschränken Sie den Zugriff auf die Instanz auf vertrauenswürdige Systeme und Netze. Eine öffentlich erreichbare Registry ohne Notwendigkeit ist ein vermeidbares Risiko.
9. Cluster-Join-Keys erneuern, wenn ein Cluster betrieben wird und ein Zugriff nicht sicher ausgeschlossen werden kann.
10. IoCs abgleichen. Wiz hat Indicators of Compromise veröffentlicht. Diese lassen sich gegen Logs, EDR-Daten und Netzwerkaufzeichnungen prüfen.

Wenn sich bei diesen Prüfungen ein Treffer ergibt, ist das Update allein keine Bereinigung mehr. Dann gehört die Instanz in eine geordnete Incident-Bearbeitung mit Sicherung der Logs, Neuaufbau des Systems und Rotation aller Zugangsdaten, die dort gespeichert waren.

Einordnung für Unternehmen

Eine Artefakt-Registry ist selten prominent im Risikoregister, tatsächlich aber ein Single Point of Failure für die gesamte Softwarelieferkette. Sie liefert Container-Images, Pakete und Bibliotheken an Build-Server und Produktionssysteme. Diese Systeme vertrauen der Registry per Konstruktion, sie prüfen normalerweise nicht, ob ein Image unterwegs verändert wurde. Ein Angreifer mit Admin-Rechten in der Registry braucht deshalb keinen weiteren Exploit, um Schadcode in laufende Umgebungen zu bringen.

Hinzu kommt der Wert der dort gespeicherten Geheimnisse. Registries halten Zugangsdaten zu Upstream-Repositories, Signaturschlüssel, Cluster-Informationen und Tokens. Der von Wiz beschriebene Diebstahl von Konfigurationsdaten und Cluster-Join-Keys passt genau in dieses Muster. Auch kleinere Unternehmen mit einer einzigen Registry-Instanz sollten daraus zwei Konsequenzen ziehen: Die Registry gehört in dieselbe Schutzklasse wie ein Domain-Controller, und ihr Patchstand gehört in eine feste, dokumentierte Routine.

Praktisch heißt das: Netzzugriff begrenzen, Administratorrechte auf wenige benannte Konten reduzieren, Tokens mit Ablaufdatum statt langlebiger Dauertokens verwenden und Veränderungen an Konten, Tokens und Plugins in ein Monitoring aufnehmen, das jemand tatsächlich liest. Wer diese vier Punkte umgesetzt hat, hätte die beschriebene Angriffskette zumindest deutlich früher bemerkt.

Passende Anleitungen auf S-EDV

• Harbor als Docker-Container-Registry betreiben: zeigt, wie eine eigene Registry aufgesetzt und abgesichert wird, inklusive Nutzer- und Rechteverwaltung.
• Docker-Images mit Trivy auf Schwachstellen scannen und SBOM erzeugen: hilft dabei, ausgelieferte Images unabhängig von der Registry zu prüfen.
• Secrets mit Gitleaks im Docker-Umfeld aufspüren: nützlich, um nach einem Vorfall gestohlene oder verstreute Zugangsdaten zu finden.

Quellen

• Wiz: Bericht zur aktiven Ausnutzung der Artifactory-Schwachstellen (Primärquelle, September 2026)
• BleepingComputer: Artifactory flaws chained in attacks deploying backdoor malware (11.09.2026)
• The Hacker News: Attackers chain JFrog Artifactory flaws (11.09.2026)
• JFrog: Übersicht der Security Advisories (Herstellerseite)