Sécuriser une instance Ollama exposée : les vrais risques de l'IA locale sur un réseau

Vous avez installé Ollama sur votre machine, téléchargé un Llama 3.3 ou un Qwen, et tout fonctionne en local. Puis vient le moment où vous voulez y accéder depuis un autre poste, votre téléphone, ou votre IDE distant. Vous changez une variable, vous redémarrez le service, et sans le savoir, vous venez peut-être d'ouvrir une API totalement ouverte sur Internet. C'est exactement le scénario qui a transformé l'IA locale en l'un des angles morts de la sécurité 2026.

Cet article n'est pas un énième tutoriel optimiste. C'est un état des lieux honnête des risques réels, chiffrés, suivi d'une procédure de durcissement qui tient la route en production.

Le problème de fond : Ollama n'a aucune authentification

Soyons direct. Ollama ne possède aucune couche d'authentification native. Zéro. La documentation officielle le confirme : aucune authentification n'est requise pour accéder à l'API via http://localhost:11434. Les « clés API » mentionnées dans la doc servent uniquement à s'authentifier auprès du cloud ollama.com, pas à protéger votre serveur.

Ce n'est pas un bug, c'est un choix de conception. En septembre 2024, une PR (#6223) implémentait une authentification basique prête à fusionner ; elle a été rejetée par le fondateur d'Ollama, avec la recommandation d'utiliser un proxy en amont. Le contrôle d'accès est donc entièrement à votre charge.

Par défaut, Ollama écoute sur 127.0.0.1:11434 — donc accessible uniquement en local. C'est le comportement sûr. Le drame commence quand on bascule sur OLLAMA_HOST=0.0.0.0 pour « accéder à distance », sans rien mettre devant.

L'ampleur réelle de l'exposition (les chiffres)

Ce n'est pas théorique. Les scans Internet de Shodan, Censys et ZoomEye trouvent ces serveurs en quelques secondes, car le port 11434 et la bannière HTTP « Ollama » rendent l'empreinte triviale.

• ~270 000 instances détectées par Shodan avec le filtre product:"Ollama", une grande part sur le port 11434 par défaut.
• 175 000 hôtes Ollama uniques recensés sur 130 pays lors d'une investigation de 293 jours (7,23 millions d'observations).
• 12 269 instances exposées identifiées par LeakIX en février 2026, dont environ 1 000 sur des versions vulnérables.
• Plus de 300 000 déploiements potentiellement concernés par la faille CVE-2026-7482 (« Bleeding Llama ») révélée en mai 2026.

Et le délai d'exploitation est court : une fois qu'un endpoint apparaît dans les résultats de scan, les tentatives d'exploitation commencent généralement en quelques heures.

Ce qu'un attaquant obtient avec une instance ouverte

1. Vol de modèles (model theft)

Via /api/tags, l'attaquant énumère chaque modèle avec sa taille exacte. Via /api/pull et /api/push, il peut exfiltrer les poids — y compris vos modèles fine-tunés propriétaires, qui représentent des mois de travail. Les chercheurs de LeakIX ont trouvé des instances avec 30+ modèles chargés, soit des centaines de gigaoctets posés sur Internet, depuis un llama3.3:latest sur 42 Go de VRAM jusqu'à des modèles maison confidentiels.

2. Abus de ressources et LLMjacking

Via /api/generate et /api/chat, n'importe qui exécute de l'inférence à vos frais. Sur du GPU loué, la facture grimpe vite et vous ne voyez rien d'anormal dans les logs applicatifs. C'est l'essor du LLMjacking : des acteurs malveillants scannent les services d'inférence exposés pour faire tourner leurs propres charges de travail — génération de contenu, traitement de données, voire alimentation d'autres attaques — sans jamais payer le compute. Pour comprendre pourquoi ce compute coûte si cher, voir notre dossier sur la VRAM, la RAM et le calcul nécessaire pour faire tourner un LLM en local.

3. Prompt injection et tool-calling

Les modèles modernes appellent des outils (tool-calling). Si votre instance Ollama est branchée à des systèmes internes via des intégrations — voir notre article sur les intégrations Ollama avec Codex, Claude et OpenClaw en local — une injection de prompt peut détourner ces outils pour atteindre des API connectées, lire des fichiers, ou pivoter dans votre réseau. L'absence d'auth transforme chaque capacité agentique en surface d'attaque.

4. Exécution de code à distance (RCE) — la menace la plus grave

Au-delà de l'accès non authentifié, plusieurs CVE critiques visent directement le binaire :

• CVE-2024-37032 « Probllama » : faille de path traversal via le champ digest d'un manifeste OCI non validé. Un registre malveillant écrit des fichiers arbitraires (ex. /etc/ld.so.preload) puis déclenche une RCE non authentifiée. En Docker, le serveur tourne en root et écoute sur 0.0.0.0 par défaut : un module Metasploit livre un shell root en quelques secondes. Corrigée en v0.1.34.
• CVE-2025-0317 (CVSS 7.5) : division par zéro dans ggufPadding lors du traitement d'un fichier GGUF forgé → crash et déni de service. Touche les versions ≤ 0.3.14.
• CVE-2026-7482 « Bleeding Llama » : lecture hors-bornes (heap) dans le loader GGUF, exploitable à distance sans auth. L'attaque exfiltre des données du tas via push en seulement trois appels API non authentifiés. Corrigée en v0.17.1.

Comment durcir : la stratégie « auth au bord »

Le principe est simple : Ollama reste privé, toute la sécurité se joue au reverse proxy. Un proxy ne rend pas Ollama magiquement sûr, mais il offre l'endroit où poser ce qui compte : TLS, authentification, timeouts, rate limiting et logs.

Étape 1 — Garder Ollama sur localhost

Ne changez jamais le bind par défaut. Laissez OLLAMA_HOST=127.0.0.1. Si le proxy tourne sur la même machine, il pointe vers 127.0.0.1:11434. Si le proxy est ailleurs, bindez sur une interface privée, jamais sur le NIC public.

Étape 2 — Fermer le port au pare-feu

• sudo ufw deny 11434 — l'API ne sort jamais.
• sudo ufw allow 443/tcp — seul le proxy HTTPS est joignable.

Étape 3 — Mettre l'authentification sur le reverse proxy

Caddy (TLS automatique, streaming correct par défaut) ou Nginx font l'affaire. Points critiques à ne pas rater :

• Authentification obligatoire : Basic Auth, Bearer token via header Authorization, ou forward-auth vers un SSO. Évitez les clés API en query string : elles fuient dans les logs et historiques de proxy.
• En-tête Host : envoyez Host: localhost à l'upstream, sinon Ollama valide l'origine et renvoie un 403 silencieux.
• Bloquer les endpoints de management : retournez 403 sur /api/(pull|push|delete|copy) pour que même un utilisateur authentifié ne puisse ni voler ni manipuler les modèles.
• Rate limiting : limit_req_zone $binary_remote_addr zone=ollama_limit:10m rate=2r/s; pour éviter la saturation GPU/RAM.
• Streaming : proxy_buffering off; et des timeouts longs (les défauts coupent les longues générations à 60 s).

Étape 4 — Préférer un tunnel privé à l'exposition directe

N'ouvrez jamais le port brut via du port-forwarding sur une box publique : c'est un appel aux bots. Pour un accès distant, un VPN (WireGuard) ou un tunnel Zero-Trust (Cloudflare Tunnel + SSO) est nettement plus robuste qu'un port 443 exposé.

Étape 5 — Patcher et surveiller

Restez à jour (≥ 0.1.34 pour Probllama, > 0.3.14 pour CVE-2025-0317, ≥ 0.17.1 pour Bleeding Llama). Surveillez le volume de requêtes, l'usage GPU et les patterns de prompts inhabituels. Toute instance ayant été accessible doit être considérée comme compromise : auditez les logs, faites tourner les secrets.

Verdict

Ollama est sûr par défaut (localhost) mais dangereux dès qu'on le déplace sans filet. Le bon mental model : Ollama est un moteur d'inférence, pas une application web exposable. Tant qu'il reste sur 127.0.0.1 derrière un pare-feu, et que TLS + authentification + rate limiting vivent sur un reverse proxy, le risque est maîtrisé. Le jour où vous lisez 0.0.0.0 dans votre config sans proxy devant, considérez votre GPU, vos modèles et votre réseau comme déjà compromis.

L'IA locale est une excellente idée — pour la confidentialité, le coût et la souveraineté. Mais « local » ne veut pas dire « sécurisé ». Cela veut dire « la sécurité est votre responsabilité ».