La plupart des serveurs Artifactory restent exposés

Trois correctifs, une seule chaîne d'attaque

JFrog a publié des correctifs pour trois vulnérabilités distinctes d'Artifactory depuis le 27 juillet 2026, et les attaquants ont passé des semaines à enchaîner les deux premières avant que la troisième ne devienne publique.

CVE-2026-42016 permet d'échanger un jeton à faible privilège contre un jeton à portée administrateur. CVE-2026-42018 remet un jeton interne d'utilisateur anonyme à un appelant qui ne s'est jamais connecté, même avec l'accès anonyme désactivé. CVE-2026-82329, divulguée le 28 août avec un score CVSS de 9,8, permet à un attaquant non authentifié d'obtenir directement des privilèges administrateur sous une configuration par défaut.

Les étapes exactes qui transforment un invité en administrateur

La société de sécurité Wiz a documenté le mécanisme exact : les attaquants envoient une requête POST à /access/api/v1/aws/token/, avec une barre oblique finale, qui renvoie un JWT anonyme même quand l'accès anonyme est désactivé. Ils envoient ensuite ce jeton à /access/api/v1/tokens pour demander un jeton à portée administrateur, qu'Artifactory délivre sans vérifier correctement le niveau de privilège réel du demandeur.

Pour la faille la plus récente, CVE-2026-82329, Wiz a trouvé un raccourci encore plus direct : un seul POST vers /access/api/v1/registry/join renvoie directement un jeton administrateur, sans qu'aucun enchaînement soit nécessaire. Une fois à l'intérieur, les attaquants ont créé des comptes administrateur persistants, installé des plugins Groovy malveillants via le propre cadre de plugins d'Artifactory pour exécuter du code sur le serveur, et dans certains cas déployé des portes dérobées écrites en Rust avec capacité de commande et contrôle. Wiz a observé les attaques enchaînées du 15 août au 8 septembre 2026, avec une vague distincte exploitant CVE-2026-82329 du 1er au 8 septembre.

Corrigé ne veut pas dire résolu

L'écart entre l'existence d'un correctif et un serveur qui l'exécute réellement est la vraie histoire ici, et il se mesure en mois, pas en jours. JFrog a corrigé CVE-2026-42016 dans la version 7.133.11 le 27 juillet ; six semaines plus tard, selon la télémétrie de Wiz, 59 pour cent des organisations restaient vulnérables.

CVE-2026-42018 ne s'est pas mieux comportée : corrigée sur cinq branches d'ici le 12 août, quatre semaines plus tard 62 pour cent des organisations restaient exposées. CVE-2026-82329 a évolué le plus vite, passant de 67 pour cent vulnérables à la divulgation à 49 pour cent après deux semaines, mais cela laisse encore près de la moitié de tous les déploiements Artifactory ouverts à une faille notée 9,8 sur 10 en gravité. L'ampleur des tentatives d'exploitation automatisées contre des serveurs non corrigés n'est pas théorique : Fastly a enregistré environ 406 000 tentatives d'exploitation contre CVE-2026-82329 en une seule journée, le 2 septembre, le même jour où la CISA l'a ajoutée à son catalogue des vulnérabilités exploitées connues.

L'obligation européenne que personne ne fait encore respecter

La CISA a donné aux agences fédérales américaines un délai ferme, le 5 septembre, trois jours après avoir ajouté CVE-2026-82329 à son catalogue KEV le 2 septembre. L'UE n'a pas d'ordre public équivalent avec une date pour les entreprises privées, même si l'article 21 de NIS2 impose déjà à de nombreuses entreprises moyennes de logiciels et de services informatiques de tenir un processus documenté de gestion des vulnérabilités couvrant exactement ce type d'outil de chaîne d'approvisionnement exposé à internet et non corrigé.

Cela laisse un vrai vide pour toute entreprise basée dans l'UE qui héberge elle-même Artifactory : il existe une obligation légale de gérer ce risque selon NIS2, mais aucun délai national ou à l'échelle de l'UE publié ne force le point comme le fait l'ordre de la CISA aux États-Unis. Pour l'instant, le seul moteur fiable pour corriger une instance Artifactory hébergée dans l'UE est l'équipe de sécurité d'une entreprise qui lit un avis du fournisseur et agit en conséquence, pas l'horloge d'un régulateur.

À lire ensuite: La faille la moins bien notée de GitLab ne nécessite qu'un projet public  |  Le Bug A Cassé Ce Dont Dépendent Les Correctifs