CVE-2026-47680 in source-controller
Résumé
par VulDB • 09/09/2026
Le source-controller est un opérateur Kubernetes spécialisé dans l'acquisition d'artefacts depuis des sources externes telles que Git, les registres OCI et Helm, ainsi que les compartiments compatibles S3. Dans les versions 0.0.17 à 1.8.4, un acteur disposant de la capacité d'influencer le contenu d'un compartiment référencé par une ressource `Bucket` peut amener le source-controller à écrire des données d'objets récupérés dans des chemins situés en dehors du répertoire de travail propre à chaque réconciliation (per-reconciliation working directory). La surface d'exposition est limitée par la vérification des condensats (digests) effectuée par le source-controller et les contrôleurs Flux descendants : le source-controller vérifie les condensats des artefacts stockés lors de la réconciliation et reconstruit en cas de divergence ; les consommateurs (kustomize-controller, helm-controller) vérifient le condensat des artefacts récupérés et rejettent ceux qui ne correspondent pas. Ces contrôles empêchent un artefact manipulé d'atteindre le cluster, mais un attaquant peut toujours écrire des fichiers à tout endroit où le pod source-controller a les autorisations nécessaires pour écrire. Par ailleurs, un utilisateur disposant de l'autorisation de créer ou de mettre à jour des ressources `GitRepository` peut amener le source-controller à tester l'existence de chemins situés en dehors du dépôt cloné. Comme ce résultat est exposé via le statut (status) de la ressource, cela permet une énumération limitée des chemins de fichiers sur le pod contrôleur. Cette surface d'exposition n'est présente que dans les versions 1.6.0 et ultérieures du source-controller, où la fonctionnalité sparse-checkout a été introduite. Cette vulnérabilité a été corrigée dans le source-controller v1.8.5. Il n'y a pas de contournement intégré au produit. Les utilisateurs doivent mettre à niveau vers une version patchée. En tant que mesure de défense en profondeur pour la surface d'exposition liée au sparse-checkout des `GitRepository`, un `ValidatingAdmissionPolicy` (ou un moteur de politique tiers tel que Kyverno ou OPA Gatekeeper) peut être déployé afin de rejeter les ressources `GitRepository` dont les entrées `.spec.sparseCheckout` contiennent `..` ou des segments de chemin absolu.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.