Ein unauthentifizierter POST auf /access/api/v1/aws/token/ liefert HTTP 200 und ein JWT für den internen Anonymous-Nutzer. Der abschließende Schrägstrich gehört dazu. Im nächsten Schritt wird das JWT gegen /access/api/v1/tokens getauscht und kommt mit Admin-Geltungsbereich zurück. Zwischen beiden Anfragen liegen kein Passwort, kein zweiter Faktor und keine menschliche Interaktion.
Das ist kein Laborbefund. Wiz Research hat die Ausnutzung von drei Schwachstellen in JFrog Artifactory dokumentiert – CVE-2026-42016, CVE-2026-42018 und CVE-2026-82329 – und beschreibt Ketten, die in weniger als fünf Minuten von einem fremden Rechner zu einem dauerhaften Admin-Konto führen. Wer eine selbst betriebene Instanz verantwortet, sollte das als aktuellen Vorfall lesen, nicht nur als Patch-Hinweis.
Artifactory ist in vielen Umgebungen die zentrale Schlüsselausgabe: Wer ein Paket, ein Container-Image oder ein Build-Artefakt braucht, holt sich dort einen Schlüssel mit einem Aufkleber, auf dem steht, welche Türen er öffnet. Die drei Lücken greifen diese Ausgabe und die Prüfung der Aufkleber an, nicht die Schlösser. Wer eine Instanz betreibt, muss deshalb nicht nur fragen, ob ein Schlüssel echt ist, sondern ob jemand geprüft hat, wofür er gilt.
Drei Lücken, ein Schlüsselbund: die JFrog-Artifactory-Schwachstellen im Einzelnen
Den Anfang macht eine fehlerhafte Authentifizierungsprüfung. CVE-2026-42018 führt dazu, dass Artifactory einer unauthentifizierten Anfrage ein internes Anonymous-Token zurückgibt – auch dann, wenn anonymer Zugriff in der Konfiguration abgeschaltet ist. Es braucht kein Konto, kein Vorwissen über interne Strukturen, keine Vorbereitung. Ein einziger Request genügt. Man hält einen Schlüssel in der Hand, der laut Aufkleber nur die Putzkammer öffnet, aber ein echter Schlüssel des Hauses ist.
CVE-2026-42016 ist die zweite Hälfte. Die Token-Validierung prüft Signatur und Aussteller korrekt, setzt aber den Geltungsbereich des Tokens nicht durch. Ein Token für eine unbedeutende Rolle lässt sich damit für Aktionen verwenden, für die niemand eine Berechtigung vergeben hat. Das Schloss liest, wer den Schlüssel ausgestellt hat, aber nicht, was auf dem Aufkleber steht. Diese Privilegieneskalation über eine unzureichende Token-Validierung macht aus einem niedrig privilegierten Zugang einen Schlüssel für alle Etagen.
Die dritte Lücke ist die direkteste. CVE-2026-82329 ist eine Authentifizierungsumgehung, die schon in der Standardkonfiguration greift: Ein Angreifer ohne Anmeldung, aber mit Netzwerkzugriff auf die Instanz kann administrative Rechte erlangen und die gesamte Deployment-Umgebung kontrollieren – Artefakte, hinterlegte Zugangsdaten, Integrationen. Die Schwachstelle wurde nach Angaben mehrerer Anbieter aktiv ausgenutzt und in den Katalog bekannter ausgenutzter Schwachstellen (CISA KEV) aufgenommen. Das ist kein Randfall für Testinstanzen.
Zwei Requests bis zum Admin-Token: die Kette aus CVE-2026-42018 und CVE-2026-42016
Zwischen dem 15. August und dem 8. September 2026 beobachteten die Forscher mehrere Akteure, die CVE-2026-42018 und CVE-2026-42016 gegen selbst betriebene Artifactory-Instanzen verketteten. In mehreren Fällen wurde eine eigens entwickelte Rust-Backdoor mit C2-Funktionalität abgelegt. Nach Angaben von Wiz Research gab es zu diesem Zeitpunkt keine öffentliche Meldung über eine Ausnutzung dieser beiden Lücken. Keine der beiden Schwachstellen verschafft für sich genommen Adminrechte. Erst die Kombination macht aus einer unauthentifizierten Anfrage einen Admin-Token.
Der Ablauf ist gleichförmig. Zuerst liefert ein POST auf /access/api/v1/aws/token/ mit HTTP 200 ein JWT für den internen Anonymous-Nutzer. Danach wird dieses JWT über einen POST auf /access/api/v1/tokens gegen ein Token mit Admin-Geltungsbereich getauscht, erneut HTTP 200. Anschließend legt ein PUT auf /api/security/users/<username> oder /access/api/ui/users/<username> ein dauerhaftes Konto an. Der eskalierte Token behält den Benutzernamen anonymous, trägt aber Admin-Autorität; spätere Anfragen erscheinen als token:anonymous. In einigen Fällen lagen zwischen erstem Request und angelegtem Admin-Konto weniger als fünf Minuten.
Danach unterscheiden sich die Fälle; kein Akteur hat alle Schritte ausgeführt. Beobachtet wurden dauerhafte Admin-Konten, bösartige Groovy-Plugins, ad-hoc Befehlsausführung über den Plugin-Endpunkt /api/plugins/execute/<plugin>, das Nachladen einer zweiten Stufe in ein weltweit beschreibbares Verzeichnis wie /dev/shm, /tmp oder /var/tmp sowie gelegentlich ein Webshell-Upload in einen Repository-Pfad. Die Reihenfolge war meist: Rechte, Werkzeuge, weitere Zugänge.
CVE-2026-82329: ein einziger POST auf /access/api/v1/registry/join genügt
Zwischen dem 1. und dem 8. September 2026 sahen die Forscher mehrere erfolgreiche Ausnutzungen von CVE-2026-82329. Der Einstieg war jedes Mal identisch: ein unauthentifizierter POST auf /access/api/v1/registry/join, der mit HTTP 200 oder 201 antwortet und einen Token mit Admin-Geltungsbereich im Antwortkörper zurückliefert. Danach gehen die Akteure unterschiedlich vor. Das spricht eher für mehrere unabhängige Gruppen als für einen einzelnen Angriff.
Beobachtet wurden das Auslesen der Systemkonfiguration über GET /api/system/configuration, das Anlegen persistenter Admin-Konten per PUT auf /api/security/users/<username> mit gesetztem customData.artifactory_admin: true, das Prägen langlebiger Tokens über /access/api/v1/tokens, das Abziehen des Cluster-Join-Keys direkt aus /access/api/v1/system/security/join_key sowie das Durchzählen von Nutzern, Repositories und Tokens. In einigen Fällen hinterlegten Angreifer zusätzlich eigene SSH-Schlüssel an den neu erstellten Konten – ein Bring-your-own-Key-Zugang, der unabhängig von Artifactory funktioniert.
Die Namen der angelegten Konten zeigen, woher sie stammen. Viele tragen die Handschrift von Proof-of-Concept-Werkzeugen: Nxploited_ gefolgt von drei Zeichen, labadmin_ mit Hex-Suffix, 0xTerror, svc_ mit acht Zeichen. Daneben gibt es Konten, die bewusst unauffällig klingen – jfrog-distribution, jfrog-insight, repo-service. Wer bei der Suche nach Kompromittierung nur nach offensichtlichen Namen filtert, übersieht diese zweite Gruppe.
Bösartige Groovy-Plugins: die Hintertür, die den Patch überlebt
Der konstanteste Schritt nach der Übernahme war in allen untersuchten Fällen das Ablegen eines Artifactory-User-Plugins. Eine Groovy-Datei landet in $JFROG_HOME/var/etc/artifactory/plugins/ und ist anschließend unter /artifactory/api/plugins/execute/<name> erreichbar. Solche Plugins laufen ungesandboxt in der Artifactory-JVM mit den vollen Rechten des Dienstkontos, werden beim Neustart automatisch nachgeladen und sind über gewöhnlichen, TLS-verschlüsselten API-Verkehr erreichbar. Auf Netzwerkebene sind sie nicht von normaler Registry-Nutzung zu unterscheiden.
Ein Plugin, das über eine der drei Lücken abgelegt wurde, verschwindet nicht durch ein Upgrade. Der Patch schließt die Eintrittstür, die Hintertür bleibt. Die Forscher haben sechs unterschiedliche Plugins geborgen und ordnen sie drei Stufen zu; die dritte, aufwendigste ist in der veröffentlichten Analyse nur angerissen.
Die erste Stufe sind Einweg-Kommandozugänge. rce.groovy und cmd.groovy nehmen einen Befehl aus einem Query-Parameter – bei rce base64-kodiert, bei cmd im Klartext –, schieben ihn durch /bin/sh -c oder bash -c und geben stdout plus stderr im Antwortkörper zurück. Ohne Parameter liefern beide id zurück. Die schlichte Benennung spricht für Gelegenheitsakteure oder Forscher, die Zugriff bestätigen, nicht für dauerhafte Präsenz. Gefährlicher ist jwtToken.groovy beziehungsweise uploadFile.groovy: identisches Prinzip, aber mit users: ['anonymous', 'admin'] deklariert – ein einfacher GET auf /artifactory/api/plugins/execute/jwtToken?token=<base64> führt Shellbefehle ohne Anmeldung aus und funktioniert auch nach dem Patchen weiter.
Die zweite Stufe ist auf Datenernte ausgelegt. JFrogImage.groovy tritt als einzelnes GET mit vier Betriebsmodi an. Modus e=1 exportiert Konfigurationsgeheimnisse: LDAP-Einstellungen samt managerDn und managerPassword, die Atlassian-Crowd-Integration, den Mailserver, alle konfigurierten Proxies und jedes Remote-Repository mit hinterlegten Zugangsdaten – jeweils durch CryptoHelper.decryptIfNeeded(), also im Klartext. Für eine Artefakt-Registry ist das ein direkter Hebel in die vorgelagerten Registries, das SSO-Verzeichnis und die Proxy-Infrastruktur. Modus u=1 sucht zuerst das Datenbankpasswort in db.properties, system.yaml und den JF_SHARED_DATABASE_-Umgebungsvariablen, meldet sich dann als Artifactory selbst an der Datenbank an, identifiziert jede Tabelle mit user oder token im Namen und zieht bis zu 5.000 Zeilen.
Artifactory-Angriff erkennen und beheben: Log und Dateisystem prüfen
Die Erkennung beginnt bei den Endpunkten, die im Normalbetrieb kaum jemand anfasst. Anfragen auf /access/api/v1/aws/token/ mit abschließendem Schrägstrich, Aufrufe von /access/api/v1/tokens durch einen anonymous-Akteur, ein /access/api/v1/registry/join von einer externen Adresse und ein GET /api/system/configuration ohne klaren Administratorbezug sind die ersten Spuren. Dazu kommt der Blick ins Plugin-Verzeichnis: Jede Datei unter $JFROG_HOME/var/etc/artifactory/plugins/, die dort nicht bewusst hingehört, ist eine potenzielle Hintertür – besonders solche mit sprechenden Namen wie rce, cmd, jwtToken oder uploadFile.
Die Aufräumarbeit ist unangenehmer als das Update. Ein Angreifer mit gestohlenen Access-Signing-Keys kann jederzeit gültige Tokens prägen, ohne den Host wieder zu betreten. Deshalb reicht es nicht, den Dienst zu aktualisieren und neu zu starten. Zu rotieren sind die Signing-Keys, der Cluster-Join-Key und alle hinterlegten Zugangsdaten für Remote-Repositories, LDAP, Crowd, Mail und Proxies. Zu prüfen sind alle Konten mit Admin-Rolle, alle langlebigen Tokens und alle angehängten SSH-Keys. Zu löschen sind Plugins, die niemand bewusst installiert hat.
Die Reihenfolge ist einfach: erst die Eintrittspunkte schließen, dann inventarisieren, dann rotieren, dann aufräumen. Wer umgekehrt arbeitet, dreht Schlösser aus, während der Nachschlüssel noch draußen kursiert. Die vom Hersteller genannten Fix-Versionen sollten aus der Original-Meldung stammen, nicht aus Sekundärquellen – bei CVE-2026-42018 wurden die betroffenen Versionsstände in der Berichterstattung bereits einmal korrigiert.
Was die Patchzahlen über den Engpass sagen
Die Zahlen von Wiz Research zeigen ein anderes Problem. Zum Zeitpunkt der Veröffentlichung von CVE-2026-42016 am 27. Juli lief in 67 Prozent der untersuchten Organisationen mindestens eine verwundbare Instanz; bei CVE-2026-42018 waren es 69 Prozent zum 12. August, bei CVE-2026-82329 ebenfalls 67 Prozent zum 28. August. Sechs Wochen nach der ersten Meldung waren noch 59 Prozent der Organisationen für CVE-2026-42016 anfällig, und CVE-2026-42018 war in vier Wochen nur von 69 auf 62 Prozent gefallen. Nur bei der kritischen Authentifizierungsumgehung ging es schneller: von 67 auf 49 Prozent innerhalb von zwei Wochen.
Das sagt weniger über die Schwere der Lücken als über die Priorisierung in Betrieben. Was als kritisch etikettiert ist, bekommt einen Sprint; was nur als Privilegieneskalation gilt, wartet auf das nächste Wartungsfenster. Angreifer greifen aber nicht in der Reihenfolge der Schweregrade an, sondern in der Reihenfolge des geringsten Widerstands. Eine mittlere Lücke, die seit sechs Wochen offen steht, ist im Zweifel der bequemere Einstieg als eine kritische, die längst geschlossen ist. Die JFrog-Artifactory-Sicherheitslücke liegt dann weniger im Code als im Prozess, der ihn aktualisiert.
War eine Instanz im relevanten Zeitraum erreichbar, sollte man von einer Kompromittierung ausgehen, bis das Gegenteil belegt ist. Der Patch ist der erste Schritt. Danach müssen Konten, Tokens, Schlüssel und Plugins geprüft werden.
Quelle: wiz.io
