Artifactory CVE-2026-82329 : clé vide, accès admin

Qu'est-ce que CVE-2026-82329 ?

C'est une faille d'authentification (CWE-287) dans le service JFrog Access, qui gère l'identité et les jetons d'Artifactory. Selon l'analyse de Fastly, le service découpe une chaîne de configuration sur les virgules sans filtrer les entrées vides. Sur une installation par défaut, une chaîne vide devient donc une clé de jonction de confiance. Son secret de signature est constant, dérivé d'une entrée vide, donc identique sur toutes les installations concernées.

JFrog a publié l'avis le 28 août 2026. Le CISA a ajouté la CVE à son catalogue des vulnérabilités exploitées (KEV) le 2 septembre.

Comment l'attaque fonctionne-t-elle ?

L'attaque tient en quatre étapes, toutes sans authentification préalable :

1. Calculer le SHA-256 de la chaîne vide pour l'utiliser comme identifiant de clé (kid).
2. Forger un JWT signé en HS256 avec le secret constant.
3. Envoyer ce jeton à POST /access/api/v1/registry/join (ou aux variantes /join/router).
4. Recevoir un jeton à portée de service, échangeable contre un jeton d'administrateur de la plateforme qui n'expire pas.

Fastly a observé les premières sondes le 29 et 30 août, environ 75 000 tentatives le 31 août (dont la plupart venaient de chercheurs en sécurité offensive), plus de 171 000 le 1er septembre après la publication d'un exploit public, puis un pic d'environ 406 000 le 2 septembre. Ces chiffres montrent la vitesse entre divulgation et exploitation de masse : quatre jours.

Qui est concerné et quelles versions corriger ?

Les instances Artifactory auto-hébergées non durcies, c'est-à-dire sans clé de jonction supplémentaire configurée. Fastly ne publie pas de plage de versions vulnérables explicite mais donne les versions corrigées par branche : 7.111.21, 7.117.28, 7.125.20, 7.133.29, 7.146.38 et 7.161.20. Vérifiez l'avis JFrog pour votre branche exacte, car certaines sources secondaires citent d'autres numéros.

Les services hébergés par JFrog (SaaS) ne sont pas décrits comme concernés dans les sources que nous avons consultées ; confirmez-le auprès de votre contact JFrog.

Comment détecter une exploitation ?

La réponse courte : cherchez les appels à l'endpoint de jonction et les administrateurs que vous ne connaissez pas.

• Dans les journaux HTTP et ceux du service Access, recherchez les requêtes vers /access/api/v1/registry/join et ses variantes. Fastly considère une réponse HTTP 201 comme une compromission confirmée, surtout avec l'identifiant de clé calculé sur la chaîne vide.
• Auditez les administrateurs, dépôts, jetons et changements de configuration créés depuis le 28 août 2026.
• Repérez les agents utilisateurs des outils de scan (JFrogArtifactory/7.146.25) et celui de l'exploit public (jfrt/0/7.161.19).

Comment corriger et contenir ?

1. Mettre à jour vers la version corrigée de votre branche.
2. Considérer l'instance comme compromise si elle était exposée. Le correctif ne révoque pas les jetons déjà émis. Faites tourner la clé de jonction, révoquez les jetons créés depuis le 28 août et changez les identifiants stockés dans la plateforme.
3. Configurer une clé de jonction forte (valeur aléatoire) si vous ne pouvez pas mettre à jour immédiatement ; c'est le contournement décrit par plusieurs analyses, à valider auprès de JFrog.
4. Restreindre le réseau : l'API /access/api/v1/registry/* ne doit pas être joignable depuis Internet.
5. Vérifier l'intégrité des artefacts publiés pendant la fenêtre d'exposition : images Docker, paquets, binaires de build. Comparez les empreintes avec celles de vos pipelines.

Le sujet rejoint les attaques de chaîne d'approvisionnement : voir notre guide sur les attaques supply chain npm, Composer et pip et l'article sur la compromission de LiteLLM 1.107.0.

Qu'est-ce qui change quand un agent IA a accès à Artifactory ?

Un agent IA qui peut lire ou écrire dans un dépôt d'artefacts hérite de la confiance de toute la chaîne de build, et sa compromission a des effets en cascade. Quatre points ressortent.

Les identifiants vivent près de l'agent. Les agents de développement (assistants de code, agents CI) utilisent souvent un jeton Artifactory présent dans leur environnement ou leur contexte. Un jeton volé via cette faille ou via une injection de prompt donne un accès durable à vos dépôts, d'autant plus que le jeton d'administrateur forgé n'expire pas.

L'empoisonnement devient automatique. Si un agent installe des dépendances ou déploie des images depuis Artifactory, un artefact substitué est consommé sans relecture humaine. L'agent exécute, teste et parfois publie le résultat : l'attaque se propage à la vitesse du pipeline.

L'agent peut être la cible de l'injection. Un README, un message de commit ou une description de paquet d'un artefact compromis peut contenir des instructions que l'agent lit comme du contexte. C'est l'injection de prompt indirecte décrite sur notre page dédiée, appliquée à la chaîne logicielle. Elle recoupe LLM03 (Supply Chain) et LLM06 (Excessive Agency) du Top 10 OWASP pour les applications LLM.

Les serveurs MCP élargissent la surface. Un serveur MCP qui expose Artifactory à un agent (recherche de paquets, téléchargement, publication) donne à celui-ci les droits du jeton qu'il porte. Consultez notre page sur la sécurité MCP.

Mesures utiles : des jetons à portée minimale et à durée courte par tâche d'agent, une identité distincte de l'agent avec lecture seule par défaut, la vérification des signatures et des empreintes avant tout déploiement, une validation humaine pour la publication d'artefacts, et la journalisation de chaque appel d'outil vers le dépôt.

Comment tester votre exposition ?

Inventoriez les instances Artifactory joignables, les jetons détenus par vos agents et les actions qu'ils peuvent enchaîner. Notre Red Team Agent Express (1 900 €, 5 jours) attaque un agent réel avec ses outils et ses identifiants, y compris l'accès à un dépôt d'artefacts, et livre un rapport avec preuves reproductibles.