Des attaquants enchaînent des failles JFrog Artifactory pour obtenir des droits admin et poser des backdoors

Wiz Research a confirmé l’exploitation active de trois vulnérabilités de JFrog Artifactory, le gestionnaire de dépôts d’artefacts présent dans de nombreuses chaînes CI/CD. Entre le 15 août et le 8 septembre 2026, plusieurs acteurs ont enchaîné deux d’entre elles pour passer d’une requête anonyme à un compte administrateur, parfois en moins de cinq minutes. Une troisième faille, critique, permet d’obtenir directement un jeton administrateur. Une fois dans la place, les attaquants ont installé des plugins Groovy malveillants, une porte dérobée écrite en Rust et volé des clés de signature. Ces éléments restent en place après la mise à jour.

Trois failles, deux chemins vers l’administration

Chemin 1 : du jeton anonyme au jeton administrateur

Wiz décrit une chaîne en trois requêtes HTTP non authentifiées :

1. Un POST sur /access/api/v1/aws/token/ (avec la barre oblique finale) renvoie un JWT de l’utilisateur anonyme interne (CVE-2026-42018).
2. Un POST sur /access/api/v1/tokens avec ce JWT renvoie un jeton de portée administrateur, qui porte toujours le nom d’utilisateur anonyme (CVE-2026-42016).
3. Un PUT sur /api/security/users/<nom> ou /access/api/ui/users/<nom> crée un administrateur persistant.

Dans les journaux, les actions suivantes apparaissent sous l’acteur token:anonymous.

Chemin 2 : la jonction de cluster détournée

CVE-2026-82329 est plus direct : une requête POST sur /access/api/v1/registry/join renvoie un jeton administrateur. Selon des analyses publiées, sur une installation par défaut, une clé de jonction vide reste considérée comme valide, avec un secret de signature prévisible. L’attaquant peut alors forger un JWT de jonction. JFrog propose d’ailleurs, en mesure temporaire, de définir une valeur aléatoire pour additionalJoinKeys (section shared › security de system.yaml) puis de redémarrer le service Access. Selon la presse, watchTowr a observé l’exploitation de cette faille dès le 1er septembre, quelques jours après le correctif.

Ce que font les attaquants après l’intrusion

Wiz souligne que les actions observées ne sont pas le fait d’un seul acteur. Les comportements récurrents sont les suivants :

• Comptes administrateurs persistants aux noms de test (labadmin_…, svc_…) ou d’apparence légitime (jfrog-distribution, repo-service, backup-service, ldap_admin…), parfois avec une clé SSH de l’attaquant associée.
• Jetons longue durée créés via /access/api/v1/tokens.
• Vol de données : configuration système, clé de jonction du cluster, énumération des utilisateurs, dépôts et jetons.
• Charges de second niveau téléchargées dans /dev/shm, /tmp ou /var/tmp, dont une porte dérobée en Rust avec capacités de commande et contrôle, et parfois des web shells déposés dans des dépôts.

Des plugins Groovy qui survivent au correctif

La mise à jour de Wiz du 17 septembre détaille les plugins Groovy malveillants déposés dans $JFROG_HOME/var/etc/artifactory/plugins/. Ils s’exécutent sans bac à sable avec les privilèges du compte de service, sont rechargés au redémarrage et survivent au patch. Wiz les classe en trois niveaux :

Pourquoi c’est grave

Artifactory est au cœur de la chaîne d’approvisionnement logicielle : il stocke et distribue les artefacts de build et de déploiement. Un attaquant administrateur peut modifier ce que vos pipelines consomment. Et avec la clé privée Access, il peut forger des jetons tant que le certificat n’est pas renouvelé.

Le retard de correction aggrave le risque. Selon Wiz, 67 % des organisations utilisant Artifactory avaient au moins une instance vulnérable à CVE-2026-42016 lors de la publication. Elles étaient encore 59 % six semaines après la divulgation. Pour CVE-2026-82329, la part est passée de 67 % à 49 % en deux semaines.

Versions corrigées

Mettez à jour vers 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 ou 7.161.20 (ou ultérieure) selon votre branche. Ces versions sont celles recommandées par Wiz et par l’avis JFrog pour CVE-2026-82329.

Lecture MITRE ATT&CK

Wiz ne fournit pas de correspondance ATT&CK. Le tableau ci-dessous est une lecture indicative de Defensy, établie à partir des comportements décrits.

Recommandations

1. ImmédiatMettre à jour et restreindre l’accès

   Appliquez la version corrigée de votre branche, en priorité sur les instances exposées sur Internet, et limitez l’accès à Artifactory aux réseaux et systèmes de confiance. À défaut de mise à jour immédiate, appliquez la mesure additionalJoinKeys proposée par JFrog.

2. ImmédiatPrésumer la compromission et chercher les traces

   Si l’instance était exposée et vulnérable, auditez les comptes administrateurs, les jetons, les clés SSH associées et le dossier des plugins. Un serveur normal dont l’API de plugins est cassée peut signaler la présence de l’implant metrics.

3. ImmédiatRenouveler clés et identifiants

   Renouvelez le certificat de signature des jetons Access : une mise à jour ne révoque pas une clé private.key volée. Renouvelez aussi la clé de jonction du cluster et les identifiants stockés dans Artifactory (LDAP, proxys, dépôts distants, base de données).

4. Court termeDéployer des détections sur les journaux Artifactory

   Alertez sur une erreur 401 sur /access/api/v1/aws/token/ suivie d’un 200 sur une variante depuis le même client, sur des appels à /access/api/v1/tokens par des identités anonymes ou peu privilégiées, et sur un succès de /registry/join corrélé à une création d’utilisateur ou à une lecture de configuration. Surveillez les fichiers de journaux vides ou tronqués.

5. Court termeVérifier l’intégrité des artefacts

   Contrôlez les artefacts publiés ou modifiés pendant la période d’exposition et les dépôts où des fichiers inattendus ont été déposés.

6. Moyen termeTraiter la forge d’artefacts comme un actif critique

   Centralisez ses journaux dans le SOC, limitez les comptes administrateurs et intégrez Artifactory à vos tests d’intrusion et à la revue de votre chaîne d’approvisionnement logicielle.