Un million de services IA exposés : ce que le scan Intruder a réellement trouvé

What is this?

Le 5 mai 2026, The Hacker News publiait We Scanned 1 Million Exposed AI Services. Here’s How Bad the Security Actually Is, une contribution de l’équipe sécurité Intruder. En partant des journaux de transparence de certificats comme amorce, l’équipe a énuméré un peu plus de deux millions d’hôtes, identifié un million de services IA exposés et trié un sous-ensemble des stacks les plus courantes en laboratoire. Conclusion, dans leurs mots : « l’infrastructure IA que nous avons scannée était plus vulnérable, plus exposée et plus mal configurée que tout autre logiciel que nous ayons jamais étudié ».

Ce rapport est l’élément que nous couvrons ici — non parce qu’il révèle une nouvelle classe de vulnérabilité, mais parce qu’il quantifie, avec une méthodologie reproductible, un problème que la plupart des écrits sur la sécurité LLM traitent encore comme anecdotique. Le rapport Fault Lines in the AI Ecosystem de Trend Micro et son communiqué sur les serveurs IA exposés confirment le même schéma sous un autre angle, et Cybernews avait déjà recensé plus de 175 000 systèmes IA exposés, y compris des instances Ollama sans authentification. Le signal est cohérent sur trois mesures indépendantes.

How it works

Aucune attaque inédite dans le compte-rendu Intruder. La méthodologie est de la simple reconnaissance appliquée à grande échelle, et le mode de défaillance est de niveau conception. Les catégories d’exposition rapportées sont suffisamment stables pour se résumer en flux de travail.

Étape                          Ce que voit un scanner non authentifié
-----------------------------  -----------------------------------------------
1. Découverte                  Logs de transparence de certificats → ~2M
                               hôtes candidats exécutant des services IA
2. Empreinte                   Les ports ouverts répondent par les bannières
                               projet (Open WebUI, Flowise, n8n, Ollama…)
3. Sonde d'authentification    Frapper « / » ou les endpoints du modèle sans
                               header → beaucoup renvoient du contenu,
                               pas 401/403
4. Sonde de capacité           Envoyer un prompt anodin (« Hello ») aux API
                               Ollama qui annoncent un modèle chargé
5. Sonde de configuration      Lire docker-compose, fichiers env,
                               credentials par défaut documentés
6. Inventaire des outils       Pour les plateformes d'agents (Flowise, n8n) :
                               lister nœuds, credentials, prompts, outils
                               attachés

Trois constats portent l’essentiel de l’impact.

Des chatbots sans authentification en façade. Des instances basées sur Open WebUI exposaient l’historique complet de conversations LLM des utilisateurs à quiconque atterrissait sur l’hôte. Des fronts génériques exploitant des modèles frontières multimodaux — Claude, GPT, Gemini, DeepSeek, Moonshot — étaient laissés totalement ouverts ; l’équipe Intruder a compté 518 serveurs encapsulant des modèles frontières bien connus parmi ceux qu’elle a pu identifier. Un chatbot ouvert devient une surface de jailbreak gratuite et non attribuable pour qui le découvre, les clés API de l’hôte payant la note.

Des plateformes de gestion d’agents accessibles depuis internet. Des consoles Flowise et n8n exposées révélaient l’intégralité des chatflows : logique métier, prompts, liste des credentials et outils câblés. Les identifiants n’étaient pas toujours lisibles en clair, mais les outils qu’ils déverrouillaient étaient directement appelables. Intruder a identifié plus de 90 instances exposées dans les secteurs gouvernement, marketing et finance — des environnements où les systèmes connectés sont la véritable cible.

Des API Ollama répondant à « Hello ». L’équipe a interrogé plus de 5 200 serveurs Ollama exposés annonçant un modèle chargé, et 31 % ont répondu à un prompt d’un seul mot, confirmant l’absence d’authentification et un chemin d’inférence actif. Ollama lui-même ne conserve pas les conversations, mais un tiers de ces endpoints étaient prêts à servir d’inférence GPU gratuite à n’importe quel appelant, y compris ceux routés vers des proxys de modèles frontières.

Les défauts sous-jacents, ramenés à une liste, sont familiers depuis vingt ans d’audits de configuration cloud :

Anti-pattern « insecure by default »      Cas concret
----------------------------------------- --------------------------------------
Pas d'authentification à l'installation   Open WebUI, Ollama, Flowise (selon
                                          le mode de déploiement), n8n self-hosted
Premier utilisateur = admin               De nombreux fronts LLM self-hosted
Identifiants statiques / codés en dur     docker-compose d'exemple copiés en
dans des configs d'exemple                production tels quels
Application exécutée en root              Plusieurs projets revus
Sandbox faible ou absente pour outils     Nœuds interpréteur de code / écriture
de code                                   fichier avec accès au système hôte

Why it matters

Les chiffres sont utiles précisément parce que les classes de bug ne le sont pas. Rien de tout cela n’exige un jailbreak modèle, une injection de prompt indirecte ou un exploit de niveau frontière. C’est la couche d’hébergement LLM qui reproduit tous les patrons de mauvaise configuration que l’outillage cloud-native mature a passé une décennie à éliminer.

Trois implications comptent pour les défenseurs.

D’abord, la surface d’attaque est en grande partie invisible aux inventaires traditionnels. La plupart de ces déploiements sont montés par des équipes applicatives via Docker sur un VPS ou dans un compte bac à sable, derrière un certificat TLS qui en est la seule trace durable. La transparence de certificats a suffi à Intruder pour les trouver ; elle suffit à un attaquant pour trouver les vôtres.

Ensuite, le chatbot est un système de manipulation d’identifiants. Une instance Open WebUI ouverte adossée à une clé API payante est, fonctionnellement, un compte non attribuable appartenant à la prochaine personne qui la jailbreakera. L’analogie pertinente n’est pas « log de chat fuité » — c’est « jeton OAuth fuité avec un quota généreux ». L’étude Amazon chatbot gone wrong de Lasso Security documente le même patron d’abus contre un bot hébergé ; le scan Intruder en trouve l’équivalent self-hosted à l’échelle.

Enfin, le rayon d’impact des plateformes d’agents, c’est la stack connectée. Une console Flowise exposée avec un outil Airtable, Slack, Notion ou base interne câblé est joignable par un visiteur non authentifié, et les divulgations récentes — la CVE-2026-41265 de l’Airtable Agent de Flowise et la classe plus large Prompts as shells — montrent que même quand les credentials sont masqués, le registre d’outils suffit à obtenir exécution de code ou exfiltration de données.

Defenses

La liste correctrice est opérationnelle, pas algorithmique. Rien n’exige d’outillage nouveau au-delà de ce qu’une équipe sécurité mature exploite déjà.

1. Inventoriez les endpoints IA externes via la transparence de certificats. Tirez les logs CT de votre propre organisation, filtrez les hôtes ressemblant à de l’infrastructure IA (Open WebUI, Flowise, n8n, Ollama, vLLM, LM Studio, Text Generation WebUI, LiteLLM et similaires), et vérifiez que chacun est intentionnel, authentifié et soumis à un rate-limit.

2. Traitez l’installation par défaut comme le modèle de menace. Avant d’exposer un front IA, vérifiez que l’authentification est activée, que le premier compte n’est pas admin automatique, que les identifiants sont générés à l’installation plutôt que copiés d’un docker-compose d’exemple, et que le conteneur ne tourne pas en root. Le rapport Intruder est explicite : ce ne sont pas des classes de bug, ce sont des valeurs par défaut.

3. Posez une frontière d’identifiants entre le chatbot et la clé API. Un bot self-hosted doit porter sa propre identité par utilisateur, avec quotas et audit, avant d’être autorisé à consommer une clé API amont. Si votre wrapper modèle expose la clé sous-jacente dans un endpoint de configuration ou un dump de variables d’environnement, traitez le wrapper comme non fiable et placez un proxy devant.

4. Isolez le plan de contrôle des agents. Flowise, n8n, Dify, LangFlow et équivalents sont des consoles d’administration. Leur place est derrière du SSO, sur un réseau interne, jamais sur un certificat TLS public. Si un développeur doit travailler à distance, faites passer par un VPN ou une passerelle zero-trust, pas par 0.0.0.0.

5. Appliquez le volet « actif IA » de la règle des deux. Pour chaque agent exposé, décidez avant déploiement lesquels deux parmi {entrée non fiable, données sensibles, action externe} la session est autorisée à porter, et appliquez la coupure au niveau réseau en plus du niveau prompt.

6. Journalisez inférences et appels d’outils comme des événements de sécurité, pas des métriques. Les logs conversationnels des chatbots ouverts et les traces d’appels d’outils des plateformes d’agents sont l’indicateur primaire d’abus. Ils ont leur place dans le même pipeline que les échecs d’authentification, pas dans un silo d’observabilité séparé.

7. Recalibrez votre monitoring de surface d’attaque externe. Si votre stack ASM ne reconnaît pas Open WebUI, Flowise, n8n, Ollama et les proxys LiteLLM courants, ajoutez-les. Le scan Intruder démontre que ces stacks sont désormais une part dominante de la nouvelle surface exposée, pas une part marginale.

Status

Stack	Schéma d’exposition documenté dans le scan de mai 2026	Première ligne de défense
Open WebUI	Historique de chat lisible ; modèles multimodaux librement utilisables	Activer l’authentification, placer derrière du SSO, rotater les clés amont
Flowise	Console accessible ; chatflows, prompts et inventaire d’outils lisibles	Déplacer la console en réseau privé, activer l’authentification, auditer les nœuds
n8n	Éditeur de workflows accessible sans authentification	Activer basic auth ou SSO, restreindre au réseau privé
Ollama	31 % des serveurs sondés ont répondu à un prompt non authentifié	Binder sur localhost, mettre un reverse proxy authentifiant devant
Fronts chat self-hosted	Clés API Claude / GPT / Gemini exposées en clair dans la config	Coffre-fort pour les credentials amont, portée par session

Le rapport Intruder est daté du 5 mai 2026. Le compte-rendu Trend Micro a été repris par PR Newswire le 22 juillet 2025, et le suivi par Cybernews de l’infrastructure Ollama exposée précède les deux. Trois mesures indépendantes, une image cohérente : la couche d’hébergement LLM expédie ses produits avec les valeurs par défaut mal calibrées. La réponse défensive n’est pas nouvelle — c’est le travail que les plateformes cloud ont fait entre 2010 et 2020, à refaire pour une stack qui n’a pas encore eu à apprendre la leçon.