Ce que font vraiment les attaquants face à un serveur Ollama exposé

Qu’est-ce que c’est ?

Le 24 septembre 2026, les chercheurs Karina Elzer, Niklas Netterstrøm Johansen et Emmanouil Vasilomanolakis ont publié sur arXiv « OllamaDrama » (2609.29757), qui décrit Ollure, un honeypot conçu pour émuler l’API Ollama et mesurer empiriquement ce que font les attaquants une fois qu’ils découvrent une infrastructure LLM exposée sur l’internet public. Contrairement aux scans d’exposition évoqués ici en mai 2026 (« One million exposed AI services »), qui comptaient le nombre de déploiements mal configurés, Ollure observe ce qui se passe après la découverte : il a fonctionné pendant 84 jours sur quatre sites, cloud et universitaires, enregistrant 290 887 interactions provenant de 2 793 adresses IP uniques. Ces résultats corroborent une observation indépendante de plus petite ampleur : un honeypot déployé par le chercheur Marco Pedrinazzi entre mars et avril 2026, qui avait enregistré 6 461 événements provenant de 324 IP en 32 jours.

Comment ça marche

Ollure est un honeypot à interaction faible à moyenne : il reproduit l’API HTTP d’Ollama de façon suffisamment convaincante pour être identifié comme un déploiement réel, mais ne dispose d’aucun LLM en arrière-plan générant du texte — son exposition est donc sûre par construction. Le trafic observé se répartit en deux grandes phases. L’essentiel du volume relève de la reconnaissance : scans de découverte automatisés, prise d’empreinte du service, requêtes d’énumération des modèles annoncés (/api/tags, /api/show). Une part plus restreinte, mais plus révélatrice, correspond à de l’exploitation active. Les catégories rapportées incluent l’abus des points de terminaison de gestion des modèles (/api/pull, /api/create, /api/delete) — avec, dans certains cas, la fabrication de « modelfiles » malveillants pour tenter une divulgation de fichiers locaux —, des sondes de traversée de répertoires et de SSRF sur les champs acceptant des URL, des charges de type RCE injectées, des tentatives de configuration de minage de cryptomonnaie, des requêtes d’épuisement de ressources, des chaînes d’injection de prompt visant tout comportement LLM en aval, des tentatives d’extraction de configuration et de secrets, ainsi qu’un trafic cohérent avec des frameworks d’agents sondant les surfaces d’usage d’outils plutôt qu’un humain saisissant des prompts. Les chaînes de charge utile spécifiques ne sont pas reproduites ici, conformément à la présentation responsable du jeu de données par les auteurs.

Pourquoi c’est important

L’apport de cette étude est significatif pour la modélisation du risque : les équipes de sécurité disposaient déjà, via des scans, de preuves que des milliers de déploiements Ollama, Open WebUI, Flowise et autres piles d’IA auto-hébergées sont exposés sans authentification, mais pas de preuves de ce qui se passe ensuite. Ollure montre que la réponse est « beaucoup, et vite » : la reconnaissance débute quelques heures après l’exposition, et une part significative des visiteurs passe ensuite à une tentative d’exploitation concrète plutôt qu’à un simple scan passif. La présence de sondes SSRF et de tentatives de divulgation de fichiers via modelfile rappelle que l’API de gestion d’Ollama a été conçue pour un contexte de confiance mono-opérateur, non pour une exposition à l’internet public, et que réduire un runtime LLM à « une API qui répond à des prompts » sous-estime sa surface d’attaque réelle.

Défenses

N’exposez jamais Ollama, ni l’API de gestion d’un serveur d’inférence auto-hébergé, directement sur internet : liez-le à localhost ou à un réseau privé, et placez une authentification devant tout accès externe. Désactivez ou isolez par pare-feu les points de terminaison de gestion des modèles (/api/pull, /api/create, /api/push, /api/delete) séparément des points de terminaison d’inférence lorsque le logiciel le permet, car ils portent un risque de fichiers et d’effets de bord réseau qu’un simple point de terminaison de prompt n’a pas. Validez et restreignez tout champ URL fourni par l’utilisateur (utilisé dans les opérations de type pull/push) contre le SSRF, en bloquant notamment les plages d’IP de métadonnées cloud. Faites tourner le processus d’inférence dans un conteneur ou un bac à sable sans accès au socket Docker ni aux jetons de compte de service Kubernetes, car les tentatives de collecte d’identifiants ciblent spécifiquement ces éléments. Surveillez la signature de reconnaissance décrite ici — rafales de /api/tags et sondes de disponibilité type « hello » — comme un indicateur précoce de découverte du déploiement, et non comme un faux positif bénin à ignorer.

Statut

Élément	Détail
Honeypot	Ollure (interaction faible/moyenne, sans LLM en arrière-plan)
Durée de l’étude	84 jours, 4 sites réseau
Interactions enregistrées	290 887 depuis 2 793 IP uniques
Paper	arXiv:2609.29757, soumis le 2026-09-24
Étude corroborante	Honeypot Ollama InTheCyber, 6 461 événements / 324 IP, mars-avr. 2026