Passer au contenu principal
En janvier 2026, SentinelLABS et Censys ont publié une étude détaillant environ 175,000 hôtes Ollama accessibles sur près de 130 pays — le rapport de SentinelOne constitue la source principale. Ces chiffres ont également été repris par The Hacker News et SecurityWeek. Les chercheurs ont constaté qu’environ la moitié des hôtes exposés proposaient un support d’appels d’outils, ce qui permet d’exécuter du code, et pas seulement de dialoguer. Il ne s’agit pas d’une vulnérabilité propre à Ollama ; il s’agit d’une configuration par défaut que la plupart des utilisateurs ne modifient jamais.

​
Le mécanisme d’échec

Par défaut, Ollama écoute sur 127.0.0.1:11434, mais uniquement sur l’interface de boucle locale, donc inaccessible depuis l’extérieur. Pour y accéder depuis un autre appareil du réseau (un téléphone, un second ordinateur ou un agent de codage distant), la solution courante consiste à :
Cette unique variable d’environnement modifie l’adresse d’écoute, passant de la boucle locale à toutes les interfaces réseau. En combinaison avec un redirectionnement de port sur le routeur, une adresse IP publique d’une machine virtuelle ou une règle de pare-feu temporaire, le port 11434 devient accessible depuis tout Internet, et non plus uniquement depuis le réseau local. Par défaut, aucune authentification n’est requise ; ainsi, quiconque découvre ce port peut appeler directement l’API : lister les modèles, effectuer des inférences et, sur les hôtes proposant des appels d’outils, exécuter du code via le modèle. C’est précisément ce schéma que les outils de balayage massif tels que Shodan et Censys sont conçus pour détecter. Il ne faut pas d’attaque ciblée : un simple balayage de ports suffit.
Il s’agit d’un problème de configuration, et non d’un défaut d’Ollama. Ce même mécanisme d’échec — écoute sur toutes les interfaces, port ouvert ou redirigé, absence d’authentification — concerne tout serveur de modèles locaux, pas seulement Ollama.

​
Pourquoi l’ajout d’une authentification ne résout pas entièrement le problème

Placer un proxy inverse doté d’une authentification de base devant 0.0.0.0:11434 aide, mais ne supprime pas la condition sous-jacente : le port reste en écoute, et un élément du réseau doit rester accessible depuis l’extérieur pour que le proxy fonctionne. Chaque composant orienté vers les connexions entrantes — le proxy, la règle de pare-feu, le redirectionnement de port, le certificat TLS — représente un élément supplémentaire devant rester correctement configuré en permanence. Une mauvaise configuration ou un retour en arrière lors du débogage suffisent à rouvrir le port à l’accès extérieur.

​
Une autre option consiste à ne pas du tout ouvrir de port entrant.

Tokios adopte une approche différente : le tokios-connector que vous exécutez à côté de votre modèle ne écoute jamais le trafic entrant. Il établit une seule connexion sortante wss:// vers https://api.tokios.com — dans la même direction que celle utilisée par votre navigateur pour charger une page web — et Tokios redirige les requêtes via cette connexion. Il n’y a aucun port à rediriger, aucune règle de pare-feu à configurer, et rien n’est lié à 0.0.0.0. Toute requête parvenant à votre modèle doit comporter une clé API sk-tok-… à portée définie, vérifiée avant que Tokios ne la transmette à votre connecteur. Ces clés peuvent être attribuées à des déploiements spécifiques selon des motifs de noms de modèles, être renouvelées, désactivées ou supprimées ; une clé révoquée cesse immédiatement d’être valide. Pour être précis quant à la portée de cette fonctionnalité : un connecteur sortant ne possède tout simplement aucune interface entrante à exposer. Il s’agit d’une différence structurelle au sein du modèle de connexion, et non d’une garantie de sécurité. Tokios ne prétend pas empêcher toute utilisation abusive d’un modèle que vous exposez via ce connecteur ; une clé API divulguée demeure un risque réel, tout comme un mot de passe divulgué ailleurs. Il s’agit en réalité d’un mécanisme plus spécifique : il n’existe aucun port d’écoute que les scanners puissent détecter, car il n’y en a jamais eu.
Si vous utilisez actuellement Ollama avec OLLAMA_HOST=0.0.0.0 pour un accès à distance, c’est exactement ce schéma qui sous-tend le numéro d’hôte 175,000. Réinstallez votre modèle sur 127.0.0.1 et accédez-y via un connecteur uniquement sortant ; consultez Accès à distance avec Ollama pour procéder à ce changement.

​
Illustration concrète de ce fonctionnement.

1

Lancez Ollama en mode boucle locale, comme il le fait par défaut.

Aucune substitution OLLAMA_HOST ni option de liaison à toutes les interfaces n’est nécessaire.
2

Associez ensuite le connecteur.

tokios-connector initie une connexion vers https://api.tokios.com et attend votre approbation dans la console. Cette étape ne crée aucun port sur votre machine ni sur votre routeur.
3

Vous pouvez désormais interroger votre modèle depuis n’importe où.

La requête doit comporter une clé sk-tok-… valide et à portée définie, sinon elle n’atteint jamais votre connecteur.
Cette situation s’applique également à toute personne se trouvant derrière un NAT de niveau opérateur (CGNAT), où le redirectionnement de ports n’est pas seulement déconseillé — il est structurellement impossible, car votre routeur ne dispose d’aucune adresse IP publique vers laquelle rediriger le trafic. Consultez Servir un LLM local depuis un environnement CGNAT pour comprendre pourquoi et comment la même connexion sortante permet de contourner ce problème.

​
Points clés à retenir

Le graphique montrant 175,000 hôtes résulte d’un scan, et ne prédit rien concernant un serveur particulier. Toutefois, le principe sous-jacent est simple et mérite d’être mémorisé, quel que soit le nombre exact d’hôtes : la possibilité d’accès entrant sans authentification constitue le cœur du problème. En supprimant cette possibilité d’accès entrant, on élimine toute une catégorie d’incidents du type « comment ont-ils même pu le trouver ? », car il n’y a plus rien en écoute pour être détecté.

Démarrage rapide

Associez un connecteur, enregistrez un modèle, puis envoyez votre première requête.

Accès distant à Ollama

Ramenez une installation Ollama déjà exposée en réseau local et accédez-y via Tokios.

Mécanisme de routage des requêtes par Tokios

Découvrez l’ensemble de l’architecture reposant uniquement sur des connexions sortantes.