Une vulnérabilité récemment divulguée, CVE-2026-85180, permet à des attaquants non authentifiés d'exploiter le module de téléchargement de modèles (model-puller) d'Ollama pour lancer des attaques de type SSRF (Server-Side Request Forgery) contre des services internes, y compris les points de terminaison de métadonnées cloud. La faille persiste dans la version actuelle, la 0.33.2, et peut être déclenchée sans compte Ollama valide.

Pourquoi cette vulnérabilité est importante

De nombreuses équipes exploitent un serveur Ollama interne pour fournir des modèles LLM aux développeurs et aux pipelines CI. L'API qui distribue les modèles est souvent laissée ouverte afin que tout utilisateur du réseau interne puisse demander un modèle par son nom. Cette commodité crée un chemin direct entre l'API exposée au public et le réseau privé. La CVE-2026-85180 transforme ce chemin en arme.

Un attaquant hébergeant un registre de modèles malveillant peut concevoir un manifeste qui redirige la requête de téléchargement vers n'importe quelle adresse accessible par le processus Ollama. Lorsque l'API de téléchargement (pull API) reçoit le manifeste, elle suit automatiquement la redirection. Comme le point de terminaison de téléchargement ne nécessite pas d'authentification, l'attaquant n'a pas besoin de compte Ollama. La redirection peut pointer vers l'adresse de loopback, une adresse link-local ou n'importe quel sous-réseau privé, offrant ainsi à l'attaquant un point d'ancrage à l'intérieur du VPC cloud ou du réseau sur site de la victime.

La cible la plus dangereuse est le service de métadonnées cloud (généralement 169.254.169.254). Ce point de terminaison distribue des identifiants temporaires à l'instance.

Comment le bug a échappé aux correctifs précédents

Plus tôt cette année, Ollama a corrigé un problème de redirection identifié sous la référence CVE-2026-5530. Le correctif avait ajouté une vérification bloquant les redirections vers des adresses privées, mais celle-ci ne s'appliquait qu'au composant principal de téléchargement. Le téléchargeur de modèles tensoriels (tensor model downloader), qui gère une classe différente de fichiers de modèles, utilise une bibliothèque cliente HTTP distincte. Cette bibliothèque traite les redirections manuellement et ne dispose d'aucune validation de la nouvelle destination. Par conséquent, la protection précédente ne s'applique jamais à ces téléchargements, laissant le vecteur SSRF ouvert.

Qui est à risque

Les entreprises qui exposent un point de terminaison Ollama à un large éventail de développeurs courent le risque le plus élevé. Les charges de travail cloud-native qui s'appuient sur des identifiants basés sur les métadonnées sont particulièrement vulnérables.

Ce qui peut être fait dès maintenant

Aucun correctif n'a été publié et la vulnérabilité persiste dans la version 0.33.2. En attendant un correctif officiel, les administrateurs doivent renforcer la couche réseau entourant le processus Ollama.

  • Arrêter les références de modèles arbitraires. Restreignez l'API afin que seuls les utilisateurs ou services de confiance puissent soumettre des noms de modèles. Rejetez les URL de registres inconnues ou fournies par l'utilisateur.
  • Verrouiller le trafic sortant. Au niveau du conteneur, de l'hôte ou du pare-feu, bloquez les connexions vers les adresses de loopback, link-local et les plages d'adresses IP privées provenant du processus Ollama. Refusez explicitement l'accès à l'adresse de métadonnées cloud (169.254.169.254), à moins que la charge de travail n'en ait réellement besoin.
  • Utiliser un registre contrôlé. Hébergez un registre de modèles interne qui ne distribue que des manifestes vérifiés. Appliquez une liste d'autorisation (allow-list) de noms d'hôtes et rejetez toute redirection pointant ailleurs.
  • Surveiller les téléchargements suspects. Analysez les journaux d'Ollama pour détecter les requêtes de téléchargement qui génèrent immédiatement un trafic réseau vers des adresses internes. Corrélez ces données avec la télémétrie réseau pour repérer les connexions sortantes inattendues.

À surveiller ensuite

Surveillez les notes de version et les avis de sécurité du projet pour le prochain correctif. En attendant, traitez le module de téléchargement de modèles (model-puller) comme un service capable de communiquer sur le réseau et appliquez immédiatement les quatre mesures d'atténuation.

À retenir : Une faille SSRF non authentifiée dans le téléchargeur de modèles d'Ollama peut exposer des identifiants cloud et des API internes ; en attendant un correctif, bloquez l'accès sortant aux réseaux privés, restreignez les références de modèles et surveillez l'activité de téléchargement.