KindaRails2Shell, attaques actives contre Ruby on Rails : des fichiers téléversés utilisés pour dérober des secrets et des identifiants

Au 31 août 2026, CVE-2026-66066 fait l’objet d’une exploitation active contre des applications Ruby on Rails exposées. Cette vulnérabilité, surnommée KindaRails2Shell, permet de transformer le téléversement d’une image spécialement conçue en lecture arbitraire des fichiers accessibles au processus Rails.

Le problème affiche un score CVSS de 9,5 et est classé CWE-1188. Les principales cibles sont les applications qui combinent Active Storage, le moteur de traitement d’images libvips et des fichiers téléversés par des utilisateurs non fiables, y compris sans authentification.

L’impact ne se limite pas à la divulgation de fichiers. Les secrets récupérés peuvent permettre de falsifier des sessions, de dérober des identifiants, d’accéder à des services connectés et, dans certaines conditions, d’aboutir à une exécution de code à distance.

Quelles versions de Rails sont vulnérables

D’après les données du NVD, les versions de Ruby on Rails antérieures aux versions suivantes sont concernées :

• 7.2.3.2
• 8.0.5.1
• 8.1.3.1

Les administrateurs doivent donc effectuer la mise à niveau vers la version corrective disponible pour leur branche, au minimum. Les composants concernés incluent notamment Ruby on Rails/Action Pack, Active Storage, libvips, libmatio et HDF5.

Toutes les installations Rails ne présentent toutefois pas le même niveau d’exposition. Les applications les plus à risque sont celles qui :

• utilisent Active Storage pour recevoir et transformer des images ;
• ont configuré libvips comme moteur de traitement ;
• autorisent les téléversements anonymes ou provenant de comptes qui ne sont pas totalement fiables ;
• exécutent Rails avec un accès à des identifiants, des clés et des configurations sensibles sur le système de fichiers.

Début août, VulnCheck avait identifié environ 7 000 instances Ruby on Rails exposées et vulnérables. Ce chiffre ne permet pas de déterminer combien d’entre elles ont depuis été mises à jour ni combien ont été compromises.

Rails a publié les correctifs fin juillet, en demandant une mise à jour immédiate des configurations exposées. Peu après, des chercheurs indépendants ont analysé le correctif, reconstitué le défaut et diffusé du code de preuve de concept. Selon VulnCheck, les attaques ont commencé environ un mois après la publication des mises à jour.

De l’image piégée à la lecture des fichiers locaux

KindaRails2Shell exploite une divergence dans la manière dont Rails et les bibliothèques sous-jacentes déterminent le format d’un fichier.

Rails peut traiter un blob comme une image en se fondant sur le type de contenu déclaré par le client. libvips, en revanche, examine les magic bytes, c’est-à-dire les séquences présentes dans le contenu qui identifient son format réel. Un attaquant peut tirer parti de cette différence pour téléverser un objet présenté à l’application comme une image, mais reconnu par libvips comme un fichier MATLAB Level 5.

La chaîne d’exploitation passe par plusieurs bibliothèques :

1. Rails accepte le téléversement comme un contenu graphique.
2. libvips détecte les octets caractéristiques du format MATLAB.
3. Le fichier est transmis à libmatio.
4. Un champ de l’en-tête amène libmatio à reconnaître la variante MAT 7.3.
5. Le traitement est délégué à la bibliothèque HDF5.
6. La fonction External File List de HDF5 reçoit un chemin et un offset contrôlés par l’attaquant.

External File List permet à un jeu de données HDF5 de stocker ses données dans un fichier externe. Dans ce scénario, la fonction est toutefois détournée pour lire un fichier local choisi par l’attaquant. Lors du rendu, les octets récupérés peuvent être intégrés à l’image produite, puis renvoyés sous forme de pixels.

La vulnérabilité résulte donc de l’absence de désactivation, dans Active Storage, des opérations libvips dangereuses lorsque le contenu provient de sources non fiables. Aucun compte n’est nécessaire : il suffit d’atteindre une fonction de téléversement vulnérable.

Secrets applicatifs, sessions et déplacement latéral

L’attaquant peut lire tout fichier accessible avec les privilèges du processus Rails. Le périmètre dépend de la configuration du serveur et des autorisations accordées à l’application, mais peut inclure :

• les variables d’environnement ;
• les fichiers contenant des secrets applicatifs ;
• les bases de données ou les coffres d’identifiants ;
• les clés d’accès aux services de stockage ;
• les configurations contenant des jetons ;
• les éléments utilisés pour signer les sessions et d’autres données applicatives.

Parmi les éléments les plus sensibles figure secret_key_base. Son exposition peut compromettre les mécanismes cryptographiques qui protègent les sessions, les cookies signés et d’autres objets générés par l’application.

Une fois les secrets dérobés, l’attaquant peut falsifier des sessions, usurper l’identité d’utilisateurs légitimes ou se connecter à des bases de données et à des infrastructures externes. Des identifiants partagés ou des clés dotées de privilèges excessifs peuvent également faciliter le déplacement latéral vers d’autres systèmes.

C’est pourquoi l’installation du correctif ne suffit pas nécessairement à clore la réponse à l’incident. La mise à jour bloque le vecteur d’attaque concerné, mais ne révoque pas les identifiants ni les signatures déjà dérobés.

Le doute concernant la variante Marshal après l’application du correctif

VulnCheck a effectué une vérification sur un serveur mis à jour vers la version 8.1.3.1, répertoriée par le NVD parmi les versions correctives. Le test aurait confirmé le blocage de la lecture arbitraire de fichiers via libvips, tout en mettant en évidence une possible portion résiduelle de la chaîne d’exploitation.

Plus précisément, une variante liée à la désérialisation Marshal et aux variation keys pourrait rester exploitable en présence d’une signature valide. Dans ces conditions, le gadget permettant l’exécution de code à distance continuerait de fonctionner même sur le système mis à jour.

Cette observation provient d’une seule source et ne démontre pas que le correctif soit inefficace contre le vecteur principal. Elle introduit toutefois une distinction opérationnelle : les versions corrigées empêcheraient la lecture de fichiers via libvips, mais il n’est pas encore certain qu’elles neutralisent toutes les étapes ultérieures possibles de la chaîne.

Les organisations doivent donc tester séparément les variation keys et la désérialisation Marshal. Cette vérification est particulièrement urgente s’il existe un soupçon que des clés de signature ou d’autres secrets aient déjà été exposés.

Catalogue CISA KEV et état de la menace

Aucune indication vérifiable ne confirme l’inscription de CVE-2026-66066 au catalogue Known Exploited Vulnerabilities de la CISA. Il n’existe donc, à ce stade, ni date d’ajout ni échéance KEV à communiquer.

Aucune information ne permet non plus d’établir la présence de vulnérabilités récentes de Ruby on Rails dans ce catalogue. L’exploitation active est néanmoins attestée par la télémétrie décrite par VulnCheck, indépendamment du statut de la faille dans le KEV.

L’activité n’a pas été attribuée à un groupe spécifique. Le nombre d’organisations touchées, les cibles privilégiées et les éventuels indicateurs de compromission associés à une campagne précise ne sont pas connus.

Mise à jour, recherche de traces et rotation des secrets

La première mesure consiste à mettre Rails à niveau vers 7.2.3.2, 8.0.5.1 ou 8.1.3.1, en choisissant la version correspondant à la branche utilisée. Les systèmes qui combinent Active Storage, libvips et des téléversements non authentifiés doivent être traités en priorité.

Si la mise à jour ne peut pas être appliquée immédiatement, il convient de désactiver temporairement les téléversements d’images ou de déplacer leur traitement dans un environnement isolé. Le processus ne devrait avoir accès qu’aux fichiers indispensables, sans pouvoir lire les secrets, les identifiants ou les configurations de l’ensemble de l’application.

Rails a également publié des outils d’analyse forensique permettant d’identifier les tentatives d’exploitation. En l’absence d’indicateurs publics plus précis, les équipes de défense doivent examiner :

• les requêtes de téléversement inhabituelles ou les contenus dont le type déclaré est incohérent ;
• l’activité anormale des processus libvips ;
• les accès inattendus à des fichiers locaux pendant le rendu ;
• les erreurs associées à MATLAB, libmatio ou HDF5 ;
• la génération suspecte de variation keys ;
• les sessions créées ou utilisées d’une manière incompatible avec le comportement habituel des utilisateurs.

Si une application vulnérable est restée exposée, il faut considérer comme potentiellement compromis secret_key_base, ainsi que les identifiants et les clés de stockage accessibles au processus. Ces valeurs doivent être renouvelées et les sessions existantes révoquées ou régénérées.

Enfin, les tests réalisés après l’application du correctif doivent couvrir à la fois le téléversement malveillant via libvips et la possible variante Marshal. KindaRails2Shell n’est plus un risque théorique : les attaques actives rendent également nécessaire une analyse rétrospective visant à détecter une éventuelle exfiltration de secrets.