JFrog Artifactory : 4 CVE au CISA KEV en 16 jours — correctifs 7.133.11 et 7.146.8

Entre le 27 août et le 11 septembre 2026, la CISA a ajouté quatre vulnérabilités JFrog Artifactory à son catalogue Known Exploited Vulnerabilities. Quatre CVE sur un même produit en seize jours, toutes avec exploitation constatée.

Versions corrigées connues : 7.133.11 pour CVE-2026-42016, et 7.111.20 / 7.117.27 / 7.125.19 / 7.133.28 / 7.146.8 selon la branche pour CVE-2026-42018.

Aucun de ces scores n'atteint 9.0. C'est précisément pour cela que cet article existe : la gravité ici ne vient pas du score, elle vient de ce qu'Artifactory est — le dépôt qui alimente vos chaînes de compilation.

Trois défauts d'authentification sur quatre

Le point commun mérite d'être relevé. Sur les quatre CVE, trois concernent l'authentification ou l'autorisation. Ce n'est pas de la corruption mémoire, ce ne sont pas des injections : ce sont des contrôles d'identité qui ne font pas ce qu'ils devraient.

CVE-2026-42016 — vérifier la signature, pas la portée

C'est la plus instructive du lot :

JFrog Artifactory (Self Hosted) versions before 7.133.11 are vulnerable to a privilege escalation attack due to a validation check of the token signature/issuer and not the token's scope.

Le jeton est correctement vérifié — signature valide, émetteur légitime. Ce qui n'est pas vérifié, c'est ce que ce jeton a le droit de faire.

C'est l'erreur classique sur les jetons : confondre authentification (qui es-tu ?) et autorisation (as-tu le droit ?). Un jeton en lecture seule émis pour un dépôt donné est authentiquement signé ; si le contrôle s'arrête là, il ouvre tout.

Ce défaut est particulièrement pernicieux en revue de code parce que la vérification est présente et fonctionne. Elle répond simplement à la mauvaise question.

CVSS 8.1, vecteur AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N. Le PR:L est trompeur dans ce contexte : n'importe quel développeur, n'importe quel pipeline de CI dispose d'un jeton.

CVE-2026-42018 — un jeton anonyme livré quand l'anonyme est désactivé

JFrog Artifactory could return an internal anonymous-user token to an unauthenticated caller when anonymous access is disabled, potentially exposing sensitive resources.

La formulation contient sa propre contradiction : l'accès anonyme est désactivé, et pourtant l'appelant non authentifié reçoit un jeton d'utilisateur anonyme interne.

Autrement dit, le durcissement que l'administrateur a explicitement appliqué ne tient pas. Une organisation qui a désactivé l'accès anonyme — c'est-à-dire une organisation attentive — se croit protégée alors qu'elle ne l'est pas.

CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N : aucun privilège requis, impact sur la confidentialité uniquement.

CVE-2026-82329 — privilèges administrateur en configuration par défaut

JFrog Artifactory contains an improper authentication vulnerability that under default configuration can allow an unauthenticated attacker with network access to obtain administrative privileges.

NVD n'a publié ni score ni versions. Mais « configuration par défaut » et « privilèges administrateur sans authentification » suffisent à situer la gravité : c'est la plus sérieuse des quatre, et c'est celle dont on a le moins de détails.

CVE-2026-66384 — écriture hors du chemin prévu

JFrog Artifactory contains an improper limitation of a pathname to a restricted directory vulnerability. This can allow an authenticated user to write data outside the intended Docker cache path under specific remote-repository conditions.

Une traversée de chemin limitée au cache Docker, exigeant un compte et des conditions particulières. C'est la moins grave isolément — mais une écriture arbitraire dans un dépôt d'artefacts, c'est un moyen de substituer du contenu.

Pourquoi Artifactory est un problème de chaîne d'approvisionnement

Artifactory est le dépôt central d'artefacts : images de conteneurs, paquets npm, JAR Maven, modules Python, binaires internes. C'est ce que toutes les chaînes de compilation de l'organisation consomment.

Cela crée une asymétrie inhabituelle entre effort et impact.

Substituer un artefact ne demande aucune persistance. Un attaquant n'a pas besoin de rester : il remplace une image de base ou une version de bibliothèque, et attend. Le prochain build la récupère, la signe s'il y a signature en aval, et la déploie en production. La compromission voyage toute seule, par le mécanisme de distribution légitime.

Le contenu est implicitement de confiance. Personne ne vérifie l'intégrité d'une dépendance venant du dépôt interne — c'est précisément la raison pour laquelle on a un dépôt interne.

Artifactory détient des identifiants. Les dépôts distants qu'il met en cache sont configurés avec des jetons vers les registres amont : Docker Hub, npm, registres cloud privés. Un accès administrateur les expose.

Les jetons de CI y convergent. Chaque pipeline s'authentifie auprès d'Artifactory ; la plateforme voit passer l'identité de toute la chaîne de production.

C'est le même raisonnement que pour la CVE GitLab publiée aujourd'hui : sur l'outillage de développement, une faille de gravité moyenne dans le classement générique est une faille grave dans les faits, parce que ce que le système contient vaut plus que le système lui-même.

Versions

En pratique, viser la version la plus récente de ta branche couvre l'ensemble. Je ne peux pas te donner de numéro pour les deux dernières et je ne vais pas en inventer.

⚠️ CVE-2026-42016 est explicitement limitée aux installations Self Hosted.

Vérifier ta version :

curl -s http://artifactory.example.com/artifactory/api/system/version | jq .

# Conteneur
docker exec <conteneur> cat /opt/jfrog/artifactory/app/artifactory.version 2>/dev/null

Détection

Jetons et accès

C'est là que se voient trois des quatre CVE :

• Jetons d'accès créés sans demande correspondante : Administration → User Management → Access Tokens
• Utilisateurs administrateurs inconnus
• Requêtes API réussies sans authentification dans les journaux d'accès
• Usage d'un jeton depuis une adresse ou un horaire incohérents avec le pipeline auquel il appartient

# Journal d accès Artifactory
grep -iE "anonymous|token" $ARTIFACTORY_HOME/var/log/artifactory-request.log | tail -100

Intégrité des artefacts

C'est le contrôle décisif, et le seul qui détecte le scénario qui compte réellement :

• Artefacts republiés sous une version existante — un tag immuable qui change est un signal non ambigu
• Empreintes modifiées sur des versions déjà publiées
• Images de base dont la date de création ne correspond pas à leur historique

# Artefacts modifiés récemment via l API de recherche
curl -s -u user:token \
  "http://artifactory.example.com/artifactory/api/search/creation?from=<timestamp>" | jq .

Configuration des dépôts distants

Vérifie que les URL amont et les identifiants configurés n'ont pas été modifiés : rediriger un dépôt distant vers un registre contrôlé par l'attaquant est une manière discrète d'empoisonner les builds sans toucher aux artefacts déjà stockés.

Mitigation

1. Mettre à jour vers la dernière version de ta branche

Quatre CVE au KEV en seize jours sur un même produit justifient une intervention hors cycle.

2. Retirer l'exposition Internet

Artifactory n'a aucune raison d'être joignable publiquement. S'il l'est pour des partenaires ou des runners externes, place-le derrière un VPN ou restreins par plages d'adresses. CVE-2026-82329 étant exploitable sans authentification en configuration par défaut, c'est la mesure la plus rentable immédiatement.

3. Auditer la portée des jetons

CVE-2026-42016 exploite le fait que la portée n'était pas vérifiée. Le corollaire défensif tient indépendamment du correctif : des jetons à portée minimale et à durée limitée. Un jeton de CI permanent, valable sur tous les dépôts, transforme n'importe quelle fuite en compromission totale.

4. Signature et vérification des artefacts

C'est la mesure structurelle. Si tes builds vérifient les signatures des artefacts consommés, une substitution dans le dépôt ne suffit plus — c'est ce qui transforme une compromission d'Artifactory en incident contenu.

5. Si tu conclus à une compromission

1. Révoquer tous les jetons d'accès, sans exception — y compris ceux des pipelines, qu'il faudra régénérer
2. Faire tourner les identifiants vers les registres amont configurés dans les dépôts distants
3. Auditer les artefacts publiés ou modifiés sur la fenêtre concernée, en priorité les images de base et les bibliothèques internes très consommées
4. Vérifier les builds sortis pendant la fenêtre : c'est le vrai périmètre de l'incident, pas le serveur
5. Prévenir les équipes en aval — si un artefact a pu être substitué, ce qui a été déployé avec est suspect

Pourquoi surveiller en continu votre outillage de développement

Artifactory, GitLab, Jenkins, les registres de conteneurs : cette catégorie échappe presque toujours aux inventaires de vulnérabilités. Elle est gérée par les équipes de développement, mise à jour selon ses propres cycles, et n'apparaît pas dans les scans de parc pilotés par la DSI. Or c'est la catégorie où une CVE notée 7.5 produit un impact que le score ne décrit pas — parce que la valeur n'est pas dans le serveur, elle est dans ce qu'il distribue.

Avec cveo.tech, inventorie ton outillage de développement et d'intégration continue avec sa version exacte, et reçois une alerte automatique dès qu'une CVE critique en concerne un.