Langflow et Rails : exploités en direct

Ce qui se passe

VulnCheck observe l'exploitation active de deux failles critiques :

• CVE-2026-0768 (CVSS 9.8, Langflow) — une validation d'entrée absente permet d'exécuter du code Python arbitraire dans le contexte de l'utilisateur root.
• CVE-2026-66066, alias KindaRails2Shell (CVSS 9.5, Ruby on Rails) — lecture de fichiers arbitraires, fuite de l'environnement du processus, puis exécution de code.

Côté Rails, le mécanisme tient dans une divergence : Active Storage et libvips ne lisent pas un fichier d'entrée de la même façon. Une image forgée franchit la validation de l'un et se fait interpréter par l'autre. L'exploitation exige que l'application traite les variantes d'image avec le processeur vips par défaut et accepte des envois d'utilisateurs non fiables — ce qui, note VulnCheck, décrit la configuration par défaut : « Active Storage always enables the libvips loaders that are unsafe for untrusted content. »

Ce qui fuit alors : secret_key_base, la clé maîtresse Rails, les mots de passe de base de données, les identifiants de stockage cloud, les jetons d'API.

L'ampleur mesurée

Plus de 50 détections en quelques heures le 30 août, 360 au 1er septembre. Caitlin Condon, VP threat research chez VulnCheck, détaille ce que cherchent les requêtes : les variables LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS*, AWS_SECRET*, le fichier /root/.cache/langflow/secret_key, l'accès .ssh et la taille de .bash_history. Le trafic vient principalement de Russie.

Sur Langflow, 12 vulnérabilités ont été exploitées depuis 2025, avec plus de 15 000 tentatives réussies sur CVE-2026-0769, CVE-2025-3248 et CVE-2026-5027 — allant du collecteur d'identifiants Python à l'enrôlement dans un botnet de minage Monero, après désactivation d'auditd pour créer un angle mort forensique. Début août, 7 100 instances Rails vulnérables étaient exposées.

Le détail qui compte

VulnCheck a testé un serveur Rails 8.1.3.1 déjà corrigé. Le correctif bloque bien la lecture de fichier par libvips — mais il ne neutralise pas la désérialisation Marshal de la clé de variante : le gadget d'exécution de code s'exécute encore, à condition de disposer d'une signature valide. Or une signature valide, c'est précisément ce que donne un secret_key_base fuité par la première étape.

À retenir

1. Si vous exposez Langflow, considérez l'instance comme compromise jusqu'à preuve du contraire et vérifiez auditd.
2. Sur Rails : corriger en 8.1.3.1 et faire tourner secret_key_base et la clé maîtresse, sinon la partie RCE reste ouverte.
3. Restreindre le traitement d'images provenant d'utilisateurs non authentifiés, ou changer de processeur de variantes.

Source : The Hacker News