Shadow AI : scanner les outils IA auto-hébergés exposés (Ollama, Langflow, ComfyUI) avec Nuclei

Un RSSI découvre rarement ces stacks par un audit planifié. Il tombe dessus par accident : un scan de routine remonte un port 11434 ouvert sur une IP publique, ou un développeur mentionne en réunion qu'il a "monté un petit outil de génération d'images pour l'équipe marketing". En creusant, on trouve une instance ComfyUI accessible depuis Internet, sans mot de passe, avec l'historique complet des générations et parfois les identifiants du compte cloud utilisés pour la facturation GPU. C'est le shadow AI : des stacks d'intelligence artificielle auto-hébergées par les équipes techniques, en dehors de tout inventaire, et souvent exposées sans authentification par défaut.

Le problème : des panels IA ouverts par défaut

La plupart des outils IA open source populaires en 2026 partagent un même défaut de conception : l'authentification n'est pas activée par défaut, elle doit être configurée explicitement. Sur un poste de développement local, ce n'est pas un problème. Le jour où le conteneur est déployé sur une VM cloud avec une règle de pare-feu trop permissive (ou aucune), il devient un panel public.

Les cibles les plus fréquentes :

• Ollama (port par défaut 11434) : serveur d'inférence local pour modèles de langage. Son API REST (/api/tags, /api/generate) ne demande aucune authentification par défaut. Un accès ouvert permet de lister les modèles chargés, de générer du contenu au nom de l'organisation, et de consommer des ressources GPU/CPU à volonté.
• ComfyUI : interface de génération d'images par workflow. L'API expose l'exécution de graphes de traitement, y compris des nœuds personnalisés capables d'exécuter du code arbitraire.
• Langflow : constructeur visuel d'agents LLM. Plusieurs versions ont exposé des endpoints de validation de code accessibles sans authentification, permettant une exécution de code à distance.
• AnythingLLM : plateforme de RAG (retrieval augmented generation) auto-hébergée. Une instance ouverte expose les documents indexés (souvent des documents internes sensibles) et les clés d'API des fournisseurs de modèles configurés.
• LiteLLM : proxy de routage vers des fournisseurs de modèles multiples. Une instance mal protégée fuit les clés API en amont ou permet un abus de quota facturé à l'entreprise.
• Gradio : bibliothèque très utilisée pour prototyper des démonstrations IA. De nombreuses instances tournent en mode debug, ce qui autorise l'exécution de code Python côté serveur.

Aucun de ces outils n'a été conçu comme malveillant. Ils ont été conçus pour un usage local ou de démonstration, et déployés en production par des équipes qui n'ont pas les réflexes de durcissement d'un serveur web classique.

Recenser la vague de templates avril 2026

La communauté de détection a suivi ce mouvement : une vague de templates Nuclei taggés exposure, llm et ai a été ajoutée au premier semestre 2026, couvrant spécifiquement ces panels. Avant d'écrire quoi que ce soit soi-même, la première étape consiste à recenser ce qui existe déjà :

nuclei -tags exposure,llm,ai -tl

Cette commande liste, sans exécuter le moindre scan, tous les templates disponibles correspondant à ces tags. On y trouve typiquement des détections pour :

• des interfaces Ollama accessibles sans authentification (endpoint /api/tags répondant avec la liste des modèles) ;
• des instances ComfyUI exposant l'API de soumission de workflow ;
• des panels Langflow accessibles sans session valide ;
• des tableaux de bord AnythingLLM, LiteLLM et Gradio en mode ouvert.

Cette liste évolue vite : la vague continue depuis avril 2026 car de nouveaux outils IA sortent chaque mois et suivent le même schéma d'exposition. Un point de vigilance : ne jamais mélanger le recensement communautaire avec un usage direct de PoC copiés depuis des dépôts sans licence explicite. La rigueur qui s'applique à la détection de CVE classique s'applique ici aussi.

Exemple de scan

Concrètement, sur un périmètre à auditer, la commande de base ressemble à ceci :

nuclei -u https://cible.exemple.com -t http/exposed-panels/ -tags llm

Elle applique tous les templates du dossier exposed-panels filtrés sur le tag llm. Pour cibler spécifiquement une exposition Ollama sur un hôte donné :

nuclei -u http://cible.exemple.com:11434 -t http/exposed-panels/ollama-api-exposure.yaml

Un résultat positif ressemble typiquement à ceci :

[ollama-api-exposure] [http] [high] http://cible.exemple.com:11434/api/tags

Ce résultat n'est utile que s'il correspond à une vraie fuite, ce qui nous amène au piège le plus courant de ce type de scan.

Le piège des faux positifs : présence n'est pas exposition

Un panel Ollama qui répond sur le port 11434 n'est pas automatiquement un incident. Trois cas de figure très différents produisent parfois le même signal brut :

1. Le vrai leak : le port est ouvert sur Internet, aucune authentification n'est demandée, l'endpoint /api/tags renvoie effectivement la liste des modèles en clair. C'est une exposition réelle.
2. Le faux positif par ordre d'exécution : le scanner atteint le port, mais un reverse proxy en amont impose une authentification basique ou un certificat client sur le chemin réel utilisé en production, le scan direct sur le port du conteneur contourne ce proxy artificiellement (scan interne mal ciblé) sans refléter ce qu'un attaquant externe verrait réellement.
3. Le panel derrière authentification légitime : l'endpoint existe et répond à une requête non authentifiée par un code 401 ou une redirection vers un formulaire de connexion. La simple présence du service ne doit jamais être confondue avec son exposition réelle.

La règle à appliquer systématiquement : un matcher de qualité ne doit jamais se contenter de vérifier qu'un port répond ou qu'une bannière contient un nom de produit. Il doit matcher sur le comportement non authentifié réel : une réponse 200 avec le contenu métier attendu (la liste des modèles, les documents indexés, le workflow exécutable), pas sur un simple statut ou une simple présence de service. C'est exactement la même discipline que pour un template de CVE classique : la preuve doit être empirique, pas déclarative.

Industrialiser plutôt que scanner une fois

Le shadow AI n'est pas un problème qu'on résout par un audit ponctuel. Les stacks apparaissent au fil des sprints, souvent sans passer par la validation IT. Traiter ce risque comme un one-shot de type bug bounty (un scan, un rapport, puis plus rien) garantit de repasser à côté de la prochaine instance montée trois semaines plus tard.

L'approche qui tient dans la durée :

• Scan récurrent sur l'ensemble de la surface d'attaque connue, pas seulement sur les actifs déclarés. Les stacks IA apparaissent souvent sur des sous-domaines ou des IP qui n'ont jamais été formellement inventoriés.
• Filtrage par sévérité et par tag dans le pipeline de traitement : un LiteLLM exposé qui fuit des clés API n'a pas la même urgence qu'un Gradio en mode debug sur un environnement de test isolé. Le tri automatique par sévérité évite de noyer l'équipe sécurité sous des alertes de priorité égale alors qu'elles ne le sont pas.
• Intégration continue : chaque nouveau template de la vague llm/ai doit être ajouté au pipeline sans intervention manuelle, sous peine de reproduire le même décalage que celui observé sur les CVE classiques (le retard entre publication et détection est la fenêtre d'exposition).

En résumé

Le shadow AI n'est pas une catégorie de risque exotique, c'est la réédition d'un problème connu (l'exposition de panels d'administration sans authentification) appliquée à une nouvelle génération d'outils qui grandissent plus vite que les réflexes de durcissement des équipes qui les déploient. Nuclei, avec ses tags exposure, llm et ai, donne les moyens de le détecter à l'échelle, à condition de matcher sur le comportement réel et de traiter ce scan comme un processus récurrent, pas comme un audit isolé.

C'est cette discipline que nous appliquons dans le pack Nuclei ThreatClaw : couverture continue de la surface d'attaque IA et shadow AI, priorisée par sévérité, avec des matchers validés pour distinguer un panel réellement ouvert d'un faux positif de façade.