JFrog Artifactory cumule deux failles d’authentification exploitées, et votre registre binaire est le maillon suivant
Le 11 septembre 2026, CISA a inscrit au catalogue KEV deux failles JFrog Artifactory : CVE-2026-42016, qui valide la signature d’un jeton sans vérifier sa portée, et CVE-2026-42018, qui fuit un jeton anonyme même quand l’accès anonyme est désactivé. Passez en 7.133.11, révoquez les jetons concernés et auditez l’accès anonyme avant qu’un artefact empoisonné ne parte en production.
11 septembre 2026. CISA ajoute deux vulnérabilités JFrog Artifactory au catalogue KEV. 27 juillet 2026. La première, CVE-2026-42016, était publiée au NVD avec un score CVSS 8.1. 12 août 2026. La seconde, CVE-2026-42018, suivait à CVSS 7.5. Pourquoi c’est important : un registre binaire comme Artifactory n’est pas un simple dépôt de fichiers — c’est le nœud de chaîne d’approvisionnement par lequel transitent tous les artefacts que vos pipelines construisent, signent et déploient. Le compromettre, c’est pouvoir empoisonner ce que tout le monde télécharge.
Un registre binaire est une cible de chaîne d’approvisionnement
Artifactory occupe une position singulière dans le cycle de vie logiciel. C’est là que les équipes publient leurs artefacts, que les pipelines CI/CD les résolvent, et que les images Docker, paquets npm, Maven ou PyPI sont proxysés et mis en cache. Une élévation de privilèges sur cette couche ne donne pas accès à un serveur de plus : elle donne la main sur ce que les développeurs vont déployer ensuite.
C’est précisément ce qui rend les deux failles du 11 septembre plus coûteuses que leur score ne le suggère. Elles frappent le contrôle d’accès — la frontière qui décide qui peut lire, écrire ou supprimer un artefact. Et toutes deux ont été confirmées exploitées dans la nature par Wiz, avant même leur inscription au KEV.
CVE-2026-42016 : vérifier la signature d’un jeton, pas sa portée
La première faille est un défaut de validation d’autorisation. D’après le descriptif NVD, Artifactory validait la signature et l’émetteur d’un jeton, mais pas sa portée (scope). Conséquence directe : un jeton émis pour une portée restreinte — un accès en lecture seule à un dépôt précis, par exemple — pouvait être étendu pour obtenir des privilèges supérieurs, jusqu’à une élévation de privilèges complète.
Le mécanisme est le cauchemar classique du JWT mal exploité. La signature garantit que le jeton est authentique, mais l’authenticité n’est pas l’autorisation. Un système qui vérifie « ce jeton est bien signé par nous » sans vérifier « ce jeton est autorisé à faire ceci » ouvre la porte à toutes les élévations. La correction, livrée dans Artifactory 7.133.11 auto-hébergé, rétablit la vérification de la portée au moment de l’autorisation.
CVE-2026-42018 : le jeton anonyme qui fuit quand il ne devrait pas exister
La seconde faille est plus sournoise encore. Quand l’accès anonyme est désactivé — la posture que la plupart des équipes adoptent sur un registre exposé — Artifactory pouvait tout de même retourner un jeton d’utilisateur anonyme interne à un appelant non authentifié. Autrement dit, le serveur fuyait un secret qui n’aurait jamais dû être délivré, exposant potentiellement des ressources sensibles.
Le risque est double. D’abord, un jeton anonyme délivré par erreur peut être rejoué pour accéder à des artefacts que l’équipe croyait protégés. Ensuite, la fuite elle-même est un indicateur de compromission à surveiller : un appelant qui récupère un jeton anonyme alors que l’accès anonyme est coupé ne devrait jamais se produire dans un déploiement sain. La présence de ce comportement dans les journaux est un signal à escalader.
Une série, pas un accident
Les deux failles ne sont pas isolées. Elles s’ajoutent à CVE-2026-82329, un contournement d’authentification CVSS 9.8 corrigé le 3 septembre, et à CVE-2026-66384, une écriture hors cache dans le registre Docker corrigée fin août. Nous avons couvert ces deux épisodes ici (CVE-2026-82329 et CVE-2026-66384). Lue dans la durée, la séquence dit que Artifactory est sous pression soutenue sur sa surface d’authentification — un profil qui, en matière de chaîne d’approvisionnement, est le plus dangereux possible.
Le travail de Wiz change la donne. Leur publication « Artifactory under attack: in-the-wild exploitation of CVE-2026-42016 and CVE-2026-42018 » documente une exploitation réelle, pas une simple preuve de concept. Quand un éditeur de registre binaire entre au KEV, ce n’est plus « corrigez parce que c’est prudent » mais « corrigez parce que quelqu’un l’utilise déjà contre vous ».
Corriger, révoquer, auditer
La correction minimale tient en une version : 7.133.11 pour les instances auto-hébergées. La vérification se fait via l’API système, sans se fier à la page de login :
# Vérifier la version auto-hébergée réellement servie (7.133.11+ est corrigé)
curl -s https://artifactory.example.com/artifactory/api/system/versionUne version antérieure à 7.133.11 est vulnérable aux deux failles — pas une seule. Mais le correctif ne suffit pas à lui seul, car des jetons déjà émis ou déjà volés continuent de fonctionner après la mise à jour. Trois actions complètent le patch :
- Révoquez et réémettez les jetons. Tous les tokens d’accès, notamment ceux à portée large, doivent être invalidés puis régénérés après la mise à niveau. Un jeton volé avant le patch reste valide après lui.
- Auditez l’accès anonyme. Confirmez que l’accès anonyme est réellement désactivé sur chaque dépôt, et que aucun jeton anonyme n’apparaît dans les journaux d’accès postérieurement à cette désactivation.
- Restreignez la surface réseau. Un registre binaire n’a pas vocation à être joignable depuis tout l’Internet. Limitez-le à vos plages CI/CD et à vos runners, comme vous le feriez pour n’importe quel secret store.
Verdict
Artifactory est devenu un point de convergence que les attaquants ont identifié avant beaucoup d’équipes. Si vous hébergez Artifactory vous-même, passez en 7.133.11 immédiatement, puis révoquez les jetons et auditez l’accès anonyme — dans cet ordre, car le patch sans révocation laisse les jetons volés opérationnels. Si vous consommez des artefacts d’un registre interne, traitez cette alerte comme un rappel que la provenance des dépendances est un contrôle de sécurité à part entière : un registre compromis peut livrer un artefact signé et apparemment légitime qui contient une porte dérobée. Si vous gérez une flotte de registres, ajoutez les failles KEV de votre éditeur de binaire à votre veille au même titre que vos serveurs d’application — c’est là que la prochaine compromission de chaîne d’approvisionnement commencera.