Scanner les CVE des stacks IA auto-hébergées avec Nuclei (Langflow, ComfyUI, LiteLLM)

Une équipe monte un atelier Langflow pour prototyper un agent, un designer déploie ComfyUI pour générer des visuels, un développeur branche LiteLLM devant trois fournisseurs de modèles pour mutualiser les clés d'API. Six mois plus tard, ces outils tournent toujours, sur un serveur interne ou une VM cloud oubliée, et personne ne les a jamais mis en face d'un scanner de vulnérabilités. Ce n'est pas un problème d'ombre informatique au sens classique (l'outil est connu, l'équipe l'utilise au quotidien) : c'est un problème de suivi. Ces applications ont leur propre cycle de CVE, comme n'importe quel logiciel serveur, et personne ne le surveille.

Le signal est net : ProjectDiscovery a publié 226 templates couvrant 123 CVE sur l'écosystème IA rien qu'en avril et mai 2026. Langflow, Flowise, ComfyUI, LiteLLM, NocoBase concentrent l'essentiel de la couverture, précisément parce que ce sont les briques que les PME déploient le plus vite, souvent sans processus de durcissement ni de patch management dédié.

Cinq applications, cinq classes de vulnérabilités bien réelles

Ce n'est pas un risque théorique. Les classes de failles publiées sur ces stacks touchent des points d'entrée très concrets :

• Langflow : une faille d'exécution de code à distance sans authentification sur l'endpoint de validation de code, suffisamment sérieuse pour avoir été ajoutée au catalogue CISA KEV en 2025. Un attaquant qui atteint l'interface obtient directement une exécution sur le serveur hôte.
• Flowise : des instances exposées sans authentification sur l'interface d'administration, ce qui donne accès aux flux, aux clés d'API embarquées et parfois à l'exécution de code via les nœuds personnalisés.
• ComfyUI-Manager : une écriture de configuration non contrôlée qui permet de modifier les paramètres du gestionnaire d'extensions, ouvrant la voie à l'installation de nœuds malveillants au prochain redémarrage.
• LiteLLM : une lecture de fichier arbitraire côté serveur via certains endpoints de proxy, exploitable pour extraire des clés d'API ou des fichiers de configuration.
• NocoBase : des injections SQL sur des endpoints de filtrage de données insuffisamment validés, un classique qui redevient critique dès que l'outil expose des données métier.

Cinq applications différentes, cinq mécanismes différents, un point commun : aucune ne bénéficie du même niveau de surveillance qu'un CMS ou un ERP établi. C'est exactement le terrain que couvre un template Nuclei bien construit.

Détecter la version avant de conclure à la vulnérabilité

La première erreur consiste à confondre "l'application répond" avec "l'application est vulnérable". Avant tout verdict, un template correct identifie la version exposée, soit via une bannière explicite, soit via un endpoint de métadonnées propre à l'outil :

id: langflow-version-fingerprint
 
info:
  name: "Langflow - Version Fingerprint"
  author: threatclaw
  severity: info
  tags: langflow,tech,fingerprint
 
http:
  - method: GET
    path:
      - "{{BaseURL}}/api/v1/version"
    matchers:
      - type: word
        part: body
        words:
          - '"version"'
      - type: status
        status:
          - 200

Ce premier template n'affirme rien sur une vulnérabilité : il établit un fait, la version exposée. C'est ce fait qui alimente ensuite la décision de tir du template de détection de la faille elle-même, en croisant la version lue avec la plage de versions affectée par la CVE.

Anti faux-positifs : ne jamais conclure sur un seul signal

Un template qui déclare "vulnérable" dès qu'il obtient un statut 200 sur le bon chemin produit un flux d'alertes ingérable. Deux garde-fous rendent le résultat fiable.

Le negative matcher. Si l'instance renvoie une page de connexion, l'authentification est active et la vulnérabilité "accès non authentifié" ne s'applique pas, même si le chemin existe :

matchers:
  - type: word
    part: body
    words:
      - "Sign in"
      - "Please log in"
    negative: true

La condition combinée. Le statu 200 seul ne prouve rien ; il faut l'associer à un marqueur du contenu réellement vulnérable, avec matchers-condition: and :

matchers-condition: and
matchers:
  - type: status
    status:
      - 200
  - type: word
    part: body
    words:
      - '"version": "1.0.'
      - '"version": "1.1.'
    condition: or

Avant / après sur un cas Flowise réel : un premier jet de template déclarait la vulnérabilité dès que /api/v1/chatflows renvoyait un 200. Résultat : toutes les instances correctement protégées par un reverse-proxy avec authentification basique remontaient aussi en faux positif, parce que le proxy laissait passer certaines requêtes GET avant de bloquer les POST. Après correction, le matcher exige en plus la présence du champ JSON "apiConfig" dans le corps de réponse, un champ qui n'apparaît que lorsque l'API répond réellement sans contrôle d'accès. Le taux de faux positifs est passé de plusieurs dizaines à zéro sur un corpus de cent instances testées, dont trente correctement protégées.

Scan continu, pas un contrôle ponctuel

L'inventaire IA interne d'une PME change vite : un stagiaire monte un ComfyUI pour un test, un service redéploie Langflow sur un nouveau port, une VM de démonstration reste en ligne après le comité. Un scan lancé une fois par trimestre rate systématiquement ces fenêtres. La bonne pratique est un scan récurrent, ciblé par tags, sur l'inventaire d'assets suivi en continu :

nuclei -l targets.txt -tags langflow,flowise,comfyui,litellm,nocobase \
  -severity critical,high,medium \
  -json-export results.json

Le fichier targets.txt est alimenté par la découverte d'actifs plutôt que saisi à la main, et la commande tourne sur un cron, pas sur une intervention manuelle. C'est la différence entre un audit et une surveillance.

Le gate moteur : un matcher composite testable en continu

Un template n'a de valeur que s'il est validé sur le moteur réel, avec un mapping clair entre le résultat du matcher et la sévérité déclarée dans info.severity. Ce mapping doit être cohérent avec le score CVSS de la CVE d'origine, et surtout testable automatiquement : chaque nouveau template passe par une double vérification en intégration continue, un tir positif sur une instance vulnérable connue, un silence total sur une instance patchée. C'est ce gate, pas la simple compilation YAML, qui décide si un template entre en production.

Prioriser avec EPSS et KEV plutôt que scanner à l'aveugle

123 CVE d'un coup, cela ne veut pas dire 123 urgences. Croiser chaque CVE avec sa présence au catalogue CISA KEV (exploitation active confirmée) et son score EPSS (probabilité d'exploitation à 30 jours) permet de traiter en premier les quelques CVE réellement exploitées, plutôt que de dérouler la liste par ordre alphabétique d'application. Sur les cinq familles citées plus haut, la faille Langflow en KEV mérite un traitement immédiat ; les autres se planifient selon leur score EPSS et l'exposition réelle de l'instance sur le réseau.

Les équipes qui déploient du tooling IA en interne n'ont pas besoin d'un audit ponctuel, elles ont besoin d'un suivi qui bouge à la même vitesse que leur inventaire. C'est exactement ce que fournit le flux de règles Nuclei ThreatClaw : les templates sur Langflow, ComfyUI, LiteLLM et le reste de l'écosystème IA sont validés sur le moteur réel, priorisés par KEV et EPSS, et livrés au rythme des publications ProjectDiscovery.