La vulnérabilité abuse du stockage actif, permettant à des attaquants non authentifiés de lire des fichiers sensibles et potentiellement de prendre le contrôle d’applications.
Une nouvelle vulnérabilité critique dans le framework d’application Web Ruby on Rails (« Rails »), CVE-2026-66066, pourrait transformer une image apparemment anodine en une porte d’entrée vers vos secrets.
Divulgué le 30 juillet, le CVE de haute gravité (noté 9,5 sur 10) présente un risque important pour les entreprises exécutant des applications qui gèrent les images téléchargées par les utilisateurs dans Rails.
Surnommé « KindaRails2Shell », il cible le composant Active Storage, trop fiable, du framework open source, permettant à des attaquants non authentifiés de lire des fichiers sensibles ou de passer à l’exécution de code à distance (RCE).
Le problème a été résolu dans les versions 7.2.3.2, 8.0.5.1 et 8.1.3.1 d’Active Storage ; les entreprises exécutant Rails devraient mettre à jour immédiatement.
« Le ‘baiser du chef’ est la possibilité pour un attaquant de télécharger une image qui n’est pas réellement une image (mais) un code qui lui permet de voler des secrets », a déclaré David Shipley de Beauceron Security.
Les attaquants obtiennent la clé du château
Ruby on Rails est un framework d’application open source côté serveur utilisé pour créer des applications Web complètes et des interfaces de programmation d’applications (API).
Il est populaire parmi les développeurs car il est évolutif, facile à apprendre et à utiliser, prend en charge le développement rapide d’applications, s’appuie sur une communauté active de plus de 1 000 ingénieurs qui le développent et le maintiennent, et dispose d’une vaste bibliothèque de près de deux millions de lignes de code prédéfini.
CVE-2026-66066 cible spécifiquement le composant Active Storage intégré de Rails, qui permet aux utilisateurs de télécharger des fichiers sur des services cloud ou des disques locaux et de les lier à leurs applications. En particulier, la vulnérabilité exploite la manière dont Active Storage interagit avec la bibliothèque de traitement d’images pour générer des images.
contient ce que l’on appelle des opérations « non fuzzées » qui n’ont pas été renforcées contre les entrées malveillantes grâce à des techniques connues sous le nom de fuzzing qui testent les cas où elles se bloquent, fuient des données ou se comportent de manière erratique. Cela les rend dangereux pour une utilisation avec du contenu non fiable, mais Active Storage ne les désactive pas de manière adéquate.
« CVE-2026-66066 est particulièrement dangereux car un attaquant peut ne pas avoir besoin d’un compte ou d’un accès privilégié », a expliqué Ensar Seker, RSSI chez SOCRadar.
Les attaquants peuvent exploiter le pipeline non sécurisé en téléchargeant des fichiers spécialement conçus qui trompent Active Storage en leur donnant accès aux fichiers auxquels le processus Rails est autorisé à accéder, même les plus sensibles dans les environnements de traitement d’applications.
En termes pratiques, cela pourrait exposer des variables d’environnement, des secrets d’application Rails, des informations d’identification de base de données, des clés d’accès au cloud, des jetons API et des informations d’identification pour les services connectés, a expliqué Seker.
Les attaquants peuvent également accéder au fichier qui signe et chiffre les cookies, les informations d’identification et les données de session. Lorsqu’elle est compromise, les attaquants détiennent essentiellement la clé de l’application.
« La vulnérabilité immédiate est un problème de lecture arbitraire de fichiers, mais le vol de secrets tels que celui de Rails peut transformer la divulgation d’informations en une compromission beaucoup plus large », a déclaré Seker.
En fonction de l’application, les attaquants pourraient potentiellement forger des données ou des sessions d’application fiables, accéder à des bases de données et des services cloud, se déplacer latéralement dans des systèmes connectés ou atteindre le RCE.
C’est cette voie d’escalade qui rend la vulnérabilité critique, a déclaré Seker. « Une fonctionnalité de téléchargement d’images apparemment courante, telle qu’une photo de profil, un avatar ou un générateur de vignettes, pourrait devenir un point d’entrée dans l’infrastructure sous-jacente de l’application. »
Comment identifier si vous êtes vulnérable
Les applications sont affectées lorsqu’elles sont configurées pour utiliser le traitement d’images Active Storage (le comportement par défaut depuis Rails 7.0) et acceptent les téléchargements d’images provenant d’utilisateurs non fiables ou non authentifiés. Les entreprises devraient auditer chaque application interne et tierce pour déterminer si elles sont configurées de cette façon, a conseillé Seker, et mettre immédiatement à jour Rails et Active Storage. Ils doivent également examiner toutes les fonctionnalités acceptant les images, y compris les avatars, les pièces jointes de support, les images de produits et les fonctions de téléchargement administratif.
La mise à niveau de Rails à elle seule n’est pas suffisante lorsqu’une ancienne installation reste en dessous ; doit être la version 8.13 ou ultérieure, a-t-il déclaré.
Les conseils et outils médico-légaux du projet Rails peuvent aider les entreprises à déterminer si les applications sont vulnérables ou si les fichiers sont exploitables, a noté Seker. Il est également important d’examiner les journaux d’applications, de proxy, de stockage d’objets et de traitement d’images pour détecter les téléchargements suspects ou les demandes inhabituelles.
De plus, les administrateurs doivent alterner tous les autres identifiants disponibles dans Rails, invalider les sessions actives et rechercher dans les systèmes en aval les identifiants potentiellement exposés.
« Les équipes de sécurité devraient traiter cela comme un incident potentiel de révélation de secrets, et non comme un simple exercice de gestion des correctifs », a déclaré Seker.
Ne faites pas confiance aux pipelines de traitement d’images
Les bibliothèques d’images complexes prennent en charge de nombreux formats et s’appuient sur de nombreux analyseurs et composants tiers, créant ainsi une large surface d’attaque, a noté Seker. Par conséquent, les bibliothèques « devraient être traitées comme un territoire d’exécution de code non fiable ».
Le traitement des images doit être isolé dans des bacs à sable ou des conteneurs dédiés, ou limité aux travailleurs ayant un accès minimal au système de fichiers, a-t-il conseillé. Il ne devrait y avoir aucune connectivité réseau inutile ni accès aux fichiers ou aux secrets d’une application. Des listes autorisées strictes doivent être appliquées, le contenu des fichiers doit être validé par un humain et les téléchargements doivent être analysés avant d’être traités et stockés en dehors des répertoires d’applications.
Des contrôles supplémentaires devraient inclure des informations d’identification de courte durée et de portée limitée, des restrictions sur le réseau sortant, une surveillance des dépendances et de la composition des logiciels, ainsi que des tests automatisés confirmant que les codecs ou les opérations dangereuses sont désactivées après la mise à niveau, a déclaré Seker.
« La leçon plus large est que les organisations ne peuvent pas évaluer l’exposition uniquement en se demandant si elles « utilisent Rails » », a-t-il noté, soulignant que deux applications exécutant la même version de Rails peuvent avoir une exposition très différente en fonction de leur processeur d’image, de leurs chemins de téléchargement et de leurs packages de système d’exploitation. Cela rend la visibilité sur la configuration d’exécution, les bibliothèques et les fonctionnalités des applications essentielle.
Cet incident démontre également l’importance de la rotation secrète dans la réponse aux vulnérabilités, a-t-il ajouté. « Lorsqu’une vulnérabilité permet un accès arbitraire aux fichiers, l’installation du correctif ferme le point d’entrée mais ne révoque pas les informations d’identification qui peuvent déjà avoir été copiées. »
Ne présumez pas que vous êtes en sécurité
Cette vulnérabilité illustre un cas d’utilisation parfait pour une nomenclature logicielle (SBOM), qui peut accélérer la découverte des logiciels vulnérables et les trier, a noté Shipley de Beauceron. Les entreprises pourraient également adopter une surveillance et une intervention intelligentes des pare-feu d’applications Web, en plus d’isoler les systèmes et d’appliquer des correctifs.
« Les mots que vous ne voulez jamais entendre dans une vulnérabilité critique sont « exécution de code arbitraire » et « exécution de code à distance » », a-t-il déclaré. « L’un ou l’autre peut signifier de mauvaises nouvelles. »
Ce qui est également intéressant ici, c’est que le processus de divulgation a été détourné, a-t-il souligné. Rails a publié des détails techniques sur la faille et des outils d’investigation pour évaluer la vulnérabilité des applications et rechercher des preuves d’exfiltration de données près d’un mois avant la date prévue, car plusieurs chercheurs avaient procédé à une ingénierie inverse de l’attaque et publié un code de preuve de concept.
Le fait que des preuves de concept soient désormais disponibles « augmente considérablement la probabilité de tentatives opportunistes d’analyse et d’exploitation », a noté Seker.
Par conséquent, a-t-il déclaré, « même les organisations qui ne voient aucune preuve évidente de compromission ne devraient pas supposer que l’application de correctifs supprime à elle seule le risque créé par des secrets précédemment révélés ».
