Une RCE critique dans IBM Langflow force un délai d'urgence de la CISA — le mécanisme exact (deux endpoints enchaînés) est précisément ce que nous venons de vérifier absent de notre propre code
Le 4 août, la CISA a inscrit une faille critique de Langflow (CVSS 9.8) à son catalogue des vulnérabilités activement exploitées, avec un délai d'urgence au 7 août pour les agences fédérales américaines — hier. Langflow, racheté par IBM via l'acquisition de DataStax, orchestre des workflows d'agents IA. Nous avons pris ce déclencheur au sérieux et vérifié notre propre code contre exactement ce type de faille, le jour même.
Le mécanisme est simple et brutal : un attaquant non authentifié appelle l'endpoint /api/v1/auto_login, qui, en configuration par défaut (LANGFLOW_AUTO_LOGIN=true), délivre un jeton super-administrateur à n'importe quel appelant réseau. Avec ce jeton, il appelle ensuite /api/v1/validate/code pour exécuter du code Python arbitraire via exec(). Aucune authentification requise — l'exploit fonctionne sur une installation par défaut, sans rien configurer de spécial. Un code de preuve de concept circule depuis juillet, et une exploitation active a été observée sur le terrain. Ce n'est pas un incident isolé pour la plateforme : Forkast recense aussi CVE-2026-33017 (RCE non authentifiée, exploitée 20h après divulgation) et CVE-2026-55255 (une faille IDOR utilisée pour aspirer des clés de fournisseurs LLM, des identifiants cloud et des secrets de base de données) — un motif répété de failles dans la frontière d'authentification de la pile d'infrastructure agentique.
Le réflexe marketing serait de citer cette faille pour dire "regardez, les autres sont vulnérables, pas nous". On a préféré vérifier avant d'écrire quoi que ce soit. Un grep complet de tout notre backend (server/src/*.ts) confirme : aucun endpoint n'accorde un jeton privilégié sans authentification — rien d'équivalent à auto_login n'existe dans notre code. Les seuls 4 endroits où AppManager lance un processus externe (le chat de l'assistant, le moteur de mails, l'envoi vers la boîte "Envoyés", et la transcription audio via ffmpeg) passent tous leurs arguments sous forme de tableau, jamais de chaîne interpolée — la classe d'injection shell que ce genre de faille exploite typiquement n'a pas de prise ici. Et surtout : AppManager n'expose à aucun utilisateur un constructeur de workflow visuel qui exécute des définitions arbitraires téléversées — l'architecture même qui rend Langflow vulnérable à cette classe de faille n'existe pas chez nous, pas parce qu'on l'a "sécurisée", mais parce qu'on ne l'a pas construite.
Pour AppH
- La vérification n'est pas une affirmation en l'air : c'est un grep réel de tout le code serveur, fait le jour même de la divulgation, et le raisonnement complet (quels fichiers, quels appels, pourquoi ils sont sûrs) est documenté dans notre propre journal de décisions interne.
- La différence d'architecture est réelle, pas cosmétique : un outil qui exécute des définitions de workflow téléversées par l'utilisateur a une surface d'attaque que nous n'avons tout simplement pas choisi de construire.
Contre / la limite honnête
- Trois failles critiques en 2026 sur une seule plateforme d'agents montrent que toute la catégorie est jeune et sous-testée — notre propre code d'appel d'agent (le chat de l'assistant) est tout aussi récent et n'a pas reçu le niveau d'examen adversarial qu'un outil utilisé par des milliers d'entreprises comme Langflow attire naturellement.
- Un grep qu'on fait soi-même n'est pas un audit de sécurité indépendant — c'est un point de départ honnête, pas une certification. Personne n'ayant trouvé de faille chez nous ne veut pas dire qu'il n'y en a pas, seulement que personne n'a encore cherché avec l'intensité qu'on voit sur Langflow.
La tentation, face à l'actualité d'un concurrent qui brûle, c'est de s'en servir comme preuve qu'on a bien fait. On préfère être honnêtes sur ce que cette vérification prouve vraiment : elle prouve qu'on a regardé, un jour précis, avec une méthode précise, et qu'on n'a rien trouvé de comparable — pas qu'on est à l'abri pour toujours. La vraie leçon de Langflow n'est pas "évitez les outils d'agents IA", c'est que la frontière entre "recommander une action" et "l'exécuter" doit rester étanche même sous la pression de livrer vite. Chez AppManager, notre assistant peut lire une image que vous lui envoyez ou lancer un processus pour transcrire un appel — mais aucune de ces capacités ne lui donne le pouvoir de modifier vos données métier ou de déclencher une action à conséquence réelle sans qu'un humain l'ait validée d'abord. Ça reste vrai aujourd'hui parce qu'on l'a vérifié aujourd'hui, pas parce qu'on l'a décrété une fois et qu'on a arrêté de regarder.
Vérifié par un humain d'AppH