Eine Kette aus zwei Sicherheitslücken in JFrog Artifactory, dem Repository, aus dem Software-Build-Pipelines ihre Abhängigkeiten beziehen, hat Angreifern ermöglicht, auf selbst gehosteten Servern die Administrator-Kontrolle zu übernehmen und Hintertüren zu installieren. Das berichtet die Cloud-Sicherheitsfirma Wiz auf Grundlage von Angriffen, die zwischen dem 15. August und dem 8. September beobachtet wurden. JFrog hatte beide Schwachstellen bereits vor diesem Zeitraum geschlossen, sodass nur nicht aktualisierte Server angreifbar waren.
Die Schwachstellenkette im Detail
Keine der beiden Lücken verschafft für sich allein volle Administratorrechte. Die Angreifer nutzten sie nacheinander aus. Die erste Schwachstelle, CVE-2026-42018, bewirkt, dass Artifactory einem nicht authentifizierten Aufrufer ein internes Token des anonymen Benutzers aushändigt – selbst wenn der anonyme Zugriff deaktiviert ist. Dieses Token besitzt nur geringe Privilegien.
Die zweite Lücke, CVE-2026-42016, erlaubt es dann, dieses niedrig privilegierte Token gegen eines mit Administrator-Umfang einzutauschen. Der Grund: Artifactory prüft zwar die Signatur des Tokens und wer es ausgestellt hat, aber nicht, welche Aktionen das Token eigentlich erlauben darf. Dadurch kann ein Token des anonymen Benutzers auf die Administrator-Ebene gehoben werden.
Der dadurch erlangte Administrator-Token behält den Benutzernamen anonymous. Alle damit ausgeführten Aktionen erscheinen in den Logs als token:anonymous und lassen sich keinem realen Konto zuordnen.
Ablauf der Angriffe
Jeder von Wiz dokumentierte Fall folgte dem gleichen Muster: Der Angreifer sendete eine unauthentifizierte Anfrage an einen Token-Endpunkt und erhielt ein Token für den internen anonymen Benutzer. Im nächsten Schritt tauschte er dieses Token an Artifactorys Endpunkt zur Token-Erstellung gegen ein Token mit Administrator-Umfang. In einigen Fällen vergingen vom ersten Request bis zur Erstellung eines neuen Administratorkontos weniger als fünf Minuten.
Die Angriffskette betrifft nur jene Server, die beide Lücken aufweisen – das Schließen einer einzigen unterbricht die Kette. Nach den veröffentlichten Versionstabellen von JFrog endet der betroffene Bereich für CVE-2026-42016 bei Version 7.133.11. Die Branches 7.146 und 7.161 liegen außerhalb dieses Bereichs.
JFrog lieferte den Fix für CVE-2026-42018 im Branch 7.146 am 28. April aus, im Branch 7.133 am 12. August – drei Tage bevor die von Wiz beobachteten Angriffe einsetzten.
Die Angreifer nutzten ihre Administratorrechte unterschiedlich. In allen Fällen erstellten sie Administratorkonten und beließen sie auf dem System. Über das Plugin-Framework von Artifactory installierten sie schadhafte Groovy-Plugins, die ihnen Codeausführung auf dem Server ermöglichten. In weiteren Schritten führten sie über den Plugin-Ausführungs-Endpunkt Shell-Befehle aus, um das System zu erkunden und Dateien aufzulisten.
Ein Dropper lud eine Binärdatei per HTTP herunter, schrieb sie in ein weltweit beschreibbares Verzeichnis wie /tmpcodecodecodecode und öffnete einen Command-and-Control-Kanal. In mehreren Fällen wurde zudem eine eigens entwickelte Rust-Backdoor mit C2-Funktionen abgelegt.
Dritte Schwachstelle: CVE-2026-82329
Eine weitere Schwachstelle, CVE-2026-82329, wurde zwischen dem 1. und 8. September separat ausgebeutet. Sie ist der Grund, warum auch Server auf neueren Branches noch verwundbar sein können. Mit einem CVSS-Score von 9,8 gilt sie als kritisch. Sie umgeht die Authentifizierung in der Standardkonfiguration von Artifactory, ohne dass eine zusätzliche Lücke nötig ist: Ein nicht authentifizierter Angreifer mit Netzwerkzugriff kann allein durch Ausnutzen dieser Schwachstelle Administratorrechte erlangen. Betroffen sind sechs Release-Branches bis einschließlich 7.161.
Bereits am 1. September wurde bekannt, dass Angreifer begannen, sich über diese Lücke selbst Administrator-Token auszustellen, nur Tage nachdem JFrog sie offengelegt hatte. Die US-Behörde CISA nahm die Schwachstelle am 2. September in ihren Katalog bekannter ausgenutzter Sicherheitslücken auf und setzte eine Frist bis zum 5. September für Bundesbehörden zur Behebung.
Der Content-Delivery-Dienst Fastly verzeichnete am 2. September rund 406.000 Exploit-Versuche über seine Plattform – gemessen am Verkehr, nicht an tatsächlichen Kompromittierungen. Auf Servern, die durch diese Lücke eingenommen wurden, lasen Angreifer die Systemkonfiguration aus und entwendeten in mehreren Fällen den Cluster-Join-Key, das gemeinsame Geheimnis, mit dem sich Artifactory-Knoten untereinander registrieren.
Betroffene Versionen und Patches
JFrog hat für jede CVE spezifische Fixversionen veröffentlicht. Für CVE-2026-42018 sind folgende Versionen als sicher markiert: 7.111.20, 7.117.27, 7.125.19, 7.133.28, 7.146.8. Für CVE-2026-42016 gilt ausschließlich 7.133.11 als behoben – in den Sicherheitshinweisen wird kein separater Fix für andere Branches aufgeführt. Ob ein späterer Build auf einem älteren Branch, etwa 7.117.28, ebenfalls die Lücke schließt, ist nicht klar dokumentiert.
Für CVE-2026-82329 empfiehlt JFrog die Aktualisierung auf die entsprechenden Fixversionen: 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38, 7.161.20. Als Workaround für nicht sofort aktualisierbare Systeme kann ein zufällig generierter Wert als zusätzlicher Join-Key in der Datei system.yamlcodecodecodecode eingetragen werden, sodass nur eigene Schlüssel bei der Registrierung eines Dienstes akzeptiert werden. Für die beiden geketteten Lücken gibt es in den aktuellen Sicherheitshinweisen keinen solchen Workaround.
Was Patching nicht rückgängig macht
Ein Update der Software entfernt nicht automatisch bereits erstellte Administratorkonten oder widerruft ausgestellte Token. Die Angreifer haben sowohl über die Zwei-Lücken-Kette als auch über CVE-2026-82329 solche Konten angelegt. Fastly rät daher, jeden exponierten Server als vollständig kompromittiert zu betrachten: Ein Patch widerruft nicht bereits gemünzte Token. Zusätzlich sollten der Plattform-Join-Key rotiert, alle seit dem 28. August ausgestellten Zugangs-Token widerrufen sowie Administratorkonten, Repositories und Konfigurationsänderungen überprüft werden.
Erkennungsmöglichkeiten
Das deutlichste Indiz für eine Kompromittierung ist ein Konto, das Aktionen ausführt, die seine Berechtigungen nicht erlauben sollten: etwa der interne anonyme Benutzer oder ein niedrig privilegiertes Konto, das Token erstellt, Benutzer auflistet oder Plugins liest und schreibt. Danach sollte nach Administratorkonten gesucht werden, die nicht absichtlich angelegt wurden. Viele der von Wiz beobachteten Konten trugen typische Proof-of-Concept-Namen wie 0xTerror oder Kombinationen aus svc_ bzw. labadmin_ mit zufälligen Zeichen. Einige waren jedoch getarnt und hießen etwa jfrog-distribution, jfrog-insight oder repo-service. Der Wiz-Bericht listet konkrete Angreifer-Adressen sowie einen Payload-Hash auf.
CVE-2026-42016 wurde am 27. Juli im Rahmen einer Reihe von Artifactory-Sicherheitshinweisen veröffentlicht, bei deren Analyse mehrere OpenAI-Forscher beteiligt waren. JFrog bestätigte im Juli, dass OpenAI-Modelle während einer internen Evaluierung eine Artifactory-Zero-Day-Lücke ausgenutzt hatten – ohne jedoch mitzuteilen, welche CVE-Einträge genau damit zusammenhingen.
Die Vorfälle unterstreichen, wie verwundbar Software-Lieferketten bleiben, wenn zentrale Infrastrukturkomponenten wie Artefakt-Repositories nicht konsequent auf dem neuesten Stand gehalten werden. Angreifer nutzen selbst kleine Zeitfenster zwischen Patch-Veröffentlichung und Massenbereitstellung, um sich dauerhaften Zugang zu verschaffen – und hinterlassen oft Spuren, die erst bei einer gründlichen forensischen Analyse sichtbar werden.
