Flowise, Mercor, Axios : 12 jours, 3 incidents, une seule faille

En douze jours, trois acteurs qui font tourner l’économie de l’IA — un éditeur no-code utilisé par des milliers de PME, une startup valorisée 10 milliards et OpenAI lui-même — se sont fait cueillir par la même mécanique. Pas par des failles internes. Par des bibliothèques tierces compromises.

Si votre PME utilise Flowise, LangChain, LiteLLM ou un SDK OpenAI en production, la question n’est plus “mon stack IA est-il sûr ?” mais “quelles dépendances invisibles y ont été empilées, et qui les audite ?”.

Flowise : 15 000 instances exposées, une requête HTTP suffit

Flowise est un outil no-code qui permet d’assembler des agents IA en glissant des blocs dans une interface. Populaire dans les PME qui prototypent un assistant conversationnel sans coder.

Le 6 avril 2026, la société de threat intelligence VulnCheck détecte une exploitation active de la CVE-2025-59528, notée CVSS 10.0. Selon CSO Online, une seule adresse IP Starlink scanne Internet à la recherche d’instances vulnérables.

Le mécanisme est brutal. Le node CustomMCP — celui qui connecte un agent à un serveur Model Context Protocol externe — passe le paramètre mcpServerConfig fourni par l’utilisateur directement au constructeur JavaScript Function(), sans validation. Un attaquant non authentifié peut exécuter n’importe quel code Node.js sur le serveur, avec accès complet au filesystem, aux variables d’environnement et à tous les secrets stockés : clés API OpenAI, Anthropic, Azure, accès bases de données, vector stores. Tout ce qu’une PME branche dans un Flowise typique.

VulnCheck recense entre 12 000 et 15 000 instances Flowise exposées sur Internet. La faille a été divulguée en septembre 2025, un correctif existe depuis la version 3.0.6, la version actuelle est 3.1.1. Six mois après le patch, des dizaines de milliers d’instances tournent toujours en version vulnérable — la troisième CVE critique de Flowise exploitée en production après CVE-2025-8943 (auth manquante) et CVE-2025-26319 (upload arbitraire).

Ce n’est pas un cas isolé. C’est le prolongement direct de la surface d’attaque que nous documentions déjà dans les 30 CVE MCP publiées en 60 jours — la menace théorique de mars est devenue exploitation active d’avril.

Mercor : 40 minutes de malware, 4 To exfiltrés

Deuxième incident, plus insidieux. Mercor, startup valorisée 10 milliards de dollars, fournit à OpenAI, Anthropic et Meta des données labellisées pour entraîner leurs modèles. Un rouage central de l’économie IA.

Le 31 mars, Mercor reconnaît une brèche. Selon TechCrunch, le groupe Lapsus$ revendique l’exfiltration de 4 To : profils candidats, PII, code source, clés API, Slack interne, vidéos de conversations entre agents IA et contractuels, datasets clients. Meta a suspendu ses contrats. OpenAI enquête.

Le vecteur ? LiteLLM, bibliothèque open source téléchargée des millions de fois par jour pour router les requêtes entre LLM. Pendant quarante minutes, le groupe TeamPCP a injecté dans une version publiée du code qui collectait les credentials à chaque appel. De là, ils ont rebondi d’un système à l’autre jusqu’à exfiltrer les 4 To.

Quarante minutes. Dans la fenêtre où un développeur Mercor a fait un pip install ou un redéploiement, il a téléchargé la version compromise. La suite s’est déroulée toute seule.

Axios : même OpenAI a dû rotationner ses certificats

Troisième incident, le plus silencieux. Axios est une bibliothèque HTTP JavaScript utilisée dans des milliers d’applications Node.js — souvent une dépendance transitive d’une autre dépendance. Le 31 mars, elle est compromise.

Selon le compte-rendu d’incident publié, OpenAI déclenche la procédure : rotation de tous les tokens et certificats, audit intégral des dépendances tierces, scanners supply chain temps réel, protocoles zero-trust renforcés. L’impact utilisateur reste faible grâce à la rapidité de réaction.

Si une organisation avec une équipe sécurité dédiée subit l’onde de choc d’une faille Axios, que fera votre PME avec trois développeurs et aucun npm audit programmé ?

Le vrai sujet n’est pas Flowise, ni LiteLLM, ni Axios

Le vrai sujet, c’est que votre PME a signé un contrat de confiance aveugle avec une dizaine de bibliothèques dont personne en interne ne connaît la maintenance, le modèle de sécurité ou les dépendances transitives.

Quand nous auditons un stack IA en PME, le problème n’est presque jamais le modèle — GPT, Claude, Mistral sont raisonnablement sécurisés par leurs éditeurs. Le problème, c’est l’empilement autour : Flowise pour le no-code, LangChain ou LiteLLM pour le routing, un SDK OpenAI, un ou deux serveurs MCP, un vector store, un framework d’orchestration. Dix à quinze libs déclarées, et plusieurs centaines de dépendances transitives que personne n’a jamais regardées.

Chacune est un contrat de confiance. Chacune est un vecteur. Le problème rejoint celui des 35 CVE en mars dans du code généré par IA : quand on accélère la production sans accélérer l’audit, la facture arrive tôt ou tard. La nouveauté 2026, c’est que les attaquants ciblent désormais spécifiquement les dépendances IA — les récompenses sont concentrées : clés API, datasets d’entraînement, agents avec accès métier.

Hygiène supply chain IA : dix points qui couvrent 80 % du risque

La liste que nous déroulons en audit flash chez les PME — les règles classiques de supply chain logicielle, appliquées au périmètre IA.

1. Cartographier votre stack — SBOM de toutes les libs IA en production, avec versions exactes et dépendances transitives.
2. Pinner les versions — jamais de latest sur LangChain, LiteLLM, SDKs IA, Flowise.
3. Scanner automatiquement — Dependabot, Trivy en CI, Snyk si le budget suit. Alerte sur CVE critique.
4. Isoler l’exécution — containers avec le strict minimum : pas d’accès filesystem inutile, pas de réseau sortant non nécessaire.
5. Ne jamais exposer les consoles no-code sur Internet — Flowise, n8n auto-hébergé, dify : derrière un VPN ou un reverse proxy avec authentification forte.
6. Activer la MFA sur tout — consoles admin, fournisseurs cloud, plateformes IA, dépôts Git.
7. Rotationner les API keys régulièrement — et systématiquement après tout incident amont.
8. Stocker les secrets dans un vault — HashiCorp Vault, Infisical, Doppler. Jamais de .env commité.
9. Centraliser les logs et détecter les anomalies — appels sortants inhabituels, pics d’API. Un SIEM léger suffit.
10. Écrire un plan de réponse incident — qui contacter, quels certificats rotationner, dans quel ordre. Avant d’en avoir besoin.

Ces dix points complètent la gouvernance interne de vos agents IA — l’un sans l’autre laisse un flanc découvert.

Ce que nous recommandons concrètement

Trois actions à caler dans les deux semaines.

D’abord, un inventaire. Listez toutes les bibliothèques IA en production, avec leurs versions. Si Flowise est exposé sur Internet, vérifiez immédiatement que vous êtes en 3.1.1 ou supérieure — sinon, mettez à jour ou isolez derrière un VPN avant ce soir.

Ensuite, un npm audit ou pip audit sur chaque projet IA. Traitez les criticités hautes. Abonnez-vous aux bulletins de sécurité des bibliothèques que vous utilisez.

Enfin, une revue opérationnelle. Vos agents IA tournent-ils sandboxés ? Vos clés API sont-elles dans un vault ? Votre équipe sait-elle quoi faire si LangChain publie une CVE critique un vendredi à 17 h ?

Si ces questions n’ont pas de réponse claire, c’est le moment de poser les bases. Nous intervenons sur ce type d’audit flash supply chain IA — livrable concret, priorisé, sans jargon. Avril 2026 a prouvé que le sujet n’attendra pas 2027 pour frapper.