36 769 services d’IA exposés sur l’Internet public

L’accessibilité publique s’étend à toute la chaîne d’approvisionnement de l’IA

Une étude publiée le 11 septembre a recensé 36 769 points de terminaison d’IA accessibles publiquement, allant de serveurs de modèles locaux à des plateformes d’automatisation et des consoles de bases vectorielles.

Des chercheurs de Mysterium VPN ont identifié ces systèmes en interrogeant l’index de balayage Internet de Netlas et en recherchant des empreintes propres à chaque service. Seuls 2,02 % des points de terminaison recensés ont renvoyé une réponse HTTP 401 ou 403, les codes d’état considérés comme la preuve d’une barrière d’authentification.

Cela ne signifie pas que tous les autres services autorisaient un accès sans restriction. Les pages de connexion peuvent renvoyer HTTP 200, tandis que l’authentification peut être imposée ailleurs dans l’application. Ce chiffre montre plutôt que la plupart des déploiements ne présentaient aucun mécanisme de contrôle détectable au niveau réseau sur le point de terminaison analysé.

La recherche a mesuré une exposition observable, et non une intrusion réussie. Les chercheurs n’ont récupéré aucun document, consulté aucun historique de conversation, lu aucun identifiant, exécuté aucun modèle, exploité aucune vulnérabilité et publié aucun nom d’hôte ni aucune adresse IP.

Le total constitue également une estimation minimale. Les index de balayage Internet ne couvrent pas tous les ports ni tous les hôtes, et les empreintes strictes écartent les systèmes qui ne peuvent pas être attribués avec certitude à un produit donné.

La répartition montre néanmoins comment une infrastructure d’IA auto-hébergée peut exposer plusieurs ressources distinctes : capacité GPU, identifiants de workflows, connexions à des systèmes d’entreprise et données privées utilisées pour la génération augmentée par récupération.

Les serveurs de modèles dominent les systèmes exposés

Open WebUI constituait la plus importante famille de produits de l’ensemble de données, avec 18 529 instances accessibles. Une seule a renvoyé un défi d’authentification HTTP.

Les chercheurs ont également identifié :

• 4 880 points de terminaison vLLM, dont trois ont renvoyé un défi d’authentification ;
• 150 points de terminaison LocalAI, dont aucun n’a renvoyé de défi ;
• 69 points de terminaison llama.cpp, dont aucun n’a renvoyé de défi.

Ces chiffres ne permettent pas d’établir que chaque installation était utilisable de manière anonyme. Une interface de connexion Open WebUI, par exemple, peut répondre HTTP 200 tout en exigeant des identifiants avant d’exposer les conversations ou les fonctions liées aux modèles.

Ollama fournissait des indices plus probants, car son point de terminaison racine affiche le texte reconnaissable Ollama is running sans demander d’authentification. Mysterium a trouvé 6 935 hôtes présentant cette empreinte, dont 6 046 ont explicitement répondu HTTP 200.

Une API Ollama exposée peut révéler les modèles installés et permettre à un utilisateur externe d’envoyer des requêtes d’inférence en utilisant le matériel de l’opérateur. Des attaquants peuvent ainsi consommer du temps GPU et de l’électricité sans compromettre l’hôte au sens traditionnel du terme.

Cet abus de ressources est généralement appelé LLMjacking. Il peut engendrer des coûts, dégrader le service fourni aux utilisateurs légitimes et associer l’infrastructure de l’opérateur à des contenus générés par un tiers inconnu.

Une étude distincte menée par SentinelOne et Censys, publiée en janvier, a recensé environ 175 000 hôtes Ollama exposés dans 130 pays. Près de la moitié prenaient en charge des fonctions d’appel d’outils capables d’exécuter du code, d’appeler des API ou de communiquer avec des systèmes externes. Les différences de couverture du balayage et de critères d’identification expliquent pourquoi ce total était nettement supérieur.

Mysterium a également observé 22 024 réponses sur le port par défaut d’Ollama, 11434. Ces systèmes ont été exclus du décompte principal, car la présence d’un port ne suffit pas à déterminer quelle application est à l’écoute. Parmi ces réponses, 4 136, soit 18,8 %, provenaient des États-Unis.

Les chercheurs ont tenté d’établir une répartition plus détaillée par pays, mais ont abandonné cette analyse après que les limites de débit eurent rendu les résultats peu fiables pour plusieurs grands pays.

Les plateformes d’agents peuvent exposer bien davantage que des capacités de calcul

L’étude a recensé 5 223 plateformes accessibles publiquement pour créer des agents et des workflows. Les produits identifiés comprenaient Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow et Open WebUI Pipelines.

Ces applications peuvent avoir un impact sur la sécurité plus important qu’un simple serveur d’inférence. Leur objectif est de connecter des modèles à des données et à des actions, notamment en stockant ou en référençant des clés d’API OpenAI, des identifiants de bases de données, des jetons Slack, des mots de passe CRM et des secrets de webhooks.

Une plateforme de workflows peut également disposer des autorisations nécessaires pour interroger des bases de données de production, mettre à jour des fiches clients, accéder à des dépôts de code source, envoyer des messages ou déclencher d’autres automatisations. L’exposition rapproche donc les secrets comme les chemins d’exécution autorisés d’un attaquant.

Mysterium a identifié 1 341 instances Flowise accessibles. Aucune n’a renvoyé de défi d’authentification 401 ou 403, même si cette seule mesure ne permet pas de conclure à l’absence de mécanismes de connexion au niveau applicatif.

Flowise présente également un risque logiciel distinct. CVE-2026-40933 est une vulnérabilité critique de l’adaptateur MCP permettant à un attaquant authentifié d’exécuter des commandes arbitraires. Elle a obtenu un score CVSS de 9,9 et le vecteur CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Le problème a été corrigé dans Flowise 3.1.0. Les administrateurs doivent effectuer une mise à niveau vers cette version ou une version ultérieure.

L’exposition sur Internet ne prouve pas qu’un système Flowise détecté utilise une version vulnérable, et la faille nécessite toujours un accès authentifié. Toutefois, un déploiement accessible publiquement offre aux attaquants davantage de possibilités d’obtenir ou de réutiliser des identifiants, puis de cibler le mécanisme d’exécution de commandes.

Des jetons divulgués rendent l’exploitation inutile

Les risques liés à n8n montrent pourquoi les défenseurs ne peuvent pas se concentrer exclusivement sur les failles logicielles.

Dans une analyse publiée en août, des chercheurs de GitGuardian ont examiné des jetons d’API n8n exposés dans des commits publics sur GitHub. Ils ont identifié 4 576 jetons uniques associés à 1 255 noms d’hôte.

Parmi ces hôtes, 896 étaient accessibles au moment des tests. Au moins un jeton divulgué fonctionnait sur 321 instances.

Dans ce type de situation, l’attaquant n’a pas besoin d’une vulnérabilité. Un jeton valide peut fournir un accès direct aux workflows et à leurs intégrations, selon ses privilèges et la configuration de l’instance concernée.

Les déploiements n8n et Flowise connectés à des environnements de production constituent donc des coffres-forts à identifiants particulièrement précieux. Un jeton divulgué par l’intermédiaire du code source peut servir de point d’entrée, tandis qu’un plan de contrôle accessible publiquement fournit à l’attaquant un endroit où l’utiliser.

Les défenseurs doivent examiner les dépôts et l’historique des commits, et pas seulement la version actuelle d’un projet. Supprimer un secret de la dernière révision n’invalide pas les copies conservées dans les commits précédents, les forks, les journaux ou les caches. Tout identifiant susceptible d’avoir été exposé doit être renouvelé.

Les bases vectorielles constituent un autre risque d’exposition des données

Mysterium a recensé 920 points de terminaison de bases vectorielles accessibles, dont la quasi-totalité présentait des consoles d’administration Attu pour Milvus. Cette catégorie est particulièrement incomplète, car la source de balayage ne couvrait pas les ports natifs utilisés par les bases de données Qdrant et Milvus.

Une base de données vectorielle peut donc rester accessible publiquement sans apparaître dans le total.

Ces systèmes stockent des représentations vectorielles et les contenus associés utilisés par les applications d’IA pour retrouver les informations pertinentes. Selon le déploiement, ces éléments peuvent inclure des documents internes, des tickets d’assistance, des fiches clients, des consignes opérationnelles ou des entrées privées de bases de connaissances.

Une console d’administration exposée et une interface de base de données native exposée constituent également deux problèmes de détection distincts. Les équipes de sécurité qui analysent uniquement les ports web conventionnels peuvent trouver Attu tout en ignorant la base de données sous-jacente, ou inversement.

L’étude n’a pas inspecté les collections ni récupéré d’enregistrements ; elle n’établit donc pas que des données étaient accessibles depuis l’un des 920 points de terminaison. Elle montre en revanche que des interfaces d’administration étaient visibles depuis l’Internet public.

Les défenseurs doivent réduire l’exposition avant de rechercher une compromission

Les organisations doivent commencer par inventorier les serveurs de modèles, les plateformes d’agents, les moteurs de workflows, les bases de données vectorielles et les consoles d’administration associées. Les ressources cloud et les expérimentations temporaires d’IA méritent une attention particulière, car des services peuvent rester liés à 0.0.0.0 après les tests.

Lorsque la connectivité publique n’est pas nécessaire, les services doivent écouter uniquement sur localhost ou sur des interfaces réseau privées. Les systèmes nécessitant un accès distant doivent combiner l’authentification à des contrôles périmétriques, une segmentation et des restrictions concernant les réseaux sources autorisés.

Les mesures prioritaires comprennent :

• Mettre Flowise à niveau vers la version 3.1.0 ou une version ultérieure.
• Rechercher dans les dépôts de code et l’historique des commits les clés d’API, les jetons n8n, les mots de passe de bases de données, les secrets de webhooks et autres identifiants.
• Renouveler les secrets susceptibles d’avoir transité par des workflows exposés ou des dépôts publics.
• Restreindre les appels d’outils, l’exécution de code, l’accès aux API et les intégrations externes qui ne sont pas nécessaires.
• Protéger les consoles Attu et analyser séparément les interfaces natives de Milvus et de Qdrant.
• Surveiller les requêtes d’inférence inhabituelles, l’utilisation des GPU, les modifications de workflows, l’emploi des jetons et l’activité sur les systèmes connectés.
• Utiliser les empreintes de produits des services de balayage Internet pour localiser les ressources de l’organisation visibles depuis l’extérieur du réseau.

L’étude n’a confirmé aucune compromission. Son enseignement pratique est plus circonscrit, mais reste lourd de conséquences : des dizaines de milliers de composants d’IA reconnaissables sont accessibles depuis Internet, et beaucoup ne présentent aucune barrière d’accès détectable avant l’application elle-même.