Si ton application Rails accepte des images envoyées par des utilisateurs et utilise libvips pour les traiter, une mise à jour ne suffit peut-être pas. La faille critique CVE‑2026‑66066 permet à un attaquant non authentifié de faire lire des fichiers arbitraires au serveur via Active Storage. Et comme l’environnement d’un processus contient souvent les clés et identifiants les plus précieux, le problème peut dépasser largement la simple fuite de fichier.
La faille se cache derrière une fonction très banale
Active Storage gère les fichiers téléversés et peut produire des variantes : miniature, redimensionnement ou conversion. Dans la configuration concernée, Rails s’appuie sur libvips, une bibliothèque rapide de traitement d’images. Le défaut venait du fait que certaines opérations marquées comme non sûres pour des contenus non fiables n’étaient pas suffisamment bloquées par Active Storage.
Visuel source : avis de sécurité officiel Rails sur GitHub — https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm
Le scénario nécessite deux conditions importantes : l’application doit utiliser libvips pour Active Storage et accepter des fichiers envoyés par des utilisateurs non fiables. Un attaquant peut alors téléverser un fichier construit pour déclencher une opération indésirable pendant son traitement. Le résultat documenté est une lecture arbitraire de fichiers accessibles au processus Rails.
Cette précision compte. Toutes les applications Rails ne sont pas automatiquement exploitables, et la présence d’Active Storage seule ne suffit pas. Mais les téléversements publics sont suffisamment courants pour que l’avis mérite un audit immédiat, pas un classement dans la pile des tâches du mois prochain.
Le fichier lu le plus intéressant est souvent l’environnement
Lire /etc/hostname serait déjà désagréable. Lire l’environnement du processus peut être beaucoup plus rentable pour un attaquant : on y trouve fréquemment secret_key_base, des identifiants de base de données, des clés d’objets compatibles S3 ou des jetons d’API. Rails rappelle d’ailleurs que la compromission de secret_key_base peut permettre de forger des cookies signés et d’autres données cryptographiques de l’application.
L’exécution de code à distance n’est pas une conséquence automatique de chaque exploitation. Elle devient toutefois plausible lorsque les secrets récupérés donnent accès à des données, à des tâches d’administration ou à des services qui permettent de poursuivre l’attaque. Autrement dit, la lecture de fichier est le premier domino ; la hauteur de la chute dépend ensuite des permissions accordées au processus.
Le correctif ne rend pas les secrets déjà volés magiquement inutiles. Si une instance vulnérable était accessible et qu’une exploitation est possible, il faut considérer les secrets lisibles comme compromis, même sans preuve parfaite dans les journaux.
Les versions corrigées sont déjà disponibles
L’équipe Rails a publié les versions Active Storage 7.2.3.2, 8.0.5.1 et 8.1.3.1. Les branches touchées sont celles antérieures à ces versions : moins de 7.2.3.2, 8.0.x avant 8.0.5.1 et 8.1.x avant 8.1.3.1. Rails 6 peut être concerné si Active Storage a été configuré en dehors de ses réglages habituels.
Il faut également passer libvips en version 8.13 ou plus récente. Cette mise à niveau permet de bloquer les opérations non fiables ; les versions plus anciennes ne savent pas appliquer cette protection. Avec les prérequis adéquats, VIPS_BLOCK_UNTRUSTED offre une mesure temporaire, tout comme Vips.block_untrusted(true) avec une version compatible de ruby-vips.
La mesure temporaire ne remplace pas le correctif Rails. Elle sert à réduire l’exposition pendant une fenêtre de maintenance, pas à transformer une dépendance ancienne en composant sûr par décret.
Rails publie aussi les outils pour regarder derrière soi
Le calendrier de divulgation a changé sous la pression du terrain. Les mainteneurs prévoyaient de détailler l’attaque plus tard, mais des preuves de concept ont circulé rapidement. Ils ont donc publié un dépôt d’enquête consacré à CVE‑2026‑66066, avec une description de la chaîne d’attaque, des indications sur les traces laissées dans la base et le stockage d’objets, ainsi que des outils pour estimer si une application était vulnérable ou exploitée.
Ces outils ne constituent pas une boule de cristal. L’absence d’un indice ne prouve pas qu’aucune donnée n’a été lue, et la présence d’un fichier spécialement formé ne démontre pas à elle seule l’exfiltration. Il faut croiser journaux HTTP, événements Active Storage, accès au stockage, dates d’exposition et rotation des secrets.
Pour les équipes qui hébergent Rails dans Docker ou Kubernetes, l’enquête doit aussi couvrir les journaux du frontal, les volumes montés et les identités du service. Un conteneur réduit la portée d’un incident seulement si ses permissions, son réseau et ses secrets sont réellement limités. Une boîte isolée avec la clé du royaume posée à l’intérieur reste une boîte avec la clé du royaume.
Ce qu’il faut faire ce soir, pas après le prochain sprint
Commence par inventorier les applications Rails qui utilisent Active Storage, leur processeur de variantes et la possibilité de téléverser des fichiers depuis Internet. Mets à jour Active Storage et libvips, puis recherche les traces d’uploads et de génération de variantes inhabituelles. Si l’exposition est confirmée ou plausible, renouvelle secret_key_base, la clé maître, les identifiants de stockage, la base de données et les jetons accessibles au processus.
Ensuite, vérifie les effets de bord : les sessions et cookies signés seront invalidés, les utilisateurs devront se reconnecter et certains liens Active Storage pourront cesser de fonctionner. C’est pénible, mais nettement moins pénible que de laisser un secret potentiellement copié continuer à signer des sessions pendant trois semaines.
Sources
Rails, « Possible arbitrary file read and remote code execution in Active Storage variant processing » — https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm — conditions, versions touchées et recommandations officielles.
Ruby on Rails, « Attack details, and tools to perform a forensic investigation » — https://discuss.rubyonrails.org/t/cve-2026-66066-attack-details-and-tools-to-perform-a-forensic-investigation/91441 — divulgation des détails et dépôt d’enquête.
Ruby on Rails, « Rails Versions 7.2.3.2, 8.0.5.1, and 8.1.3.1 have been released! » — https://rubyonrails.org/2026/7/29/Rails-Versions-7-2-3-2-8-0-5-1-and-8-1-3-1-have-been-released — publication des versions corrigées.
BleepingComputer, « Rails patches critical Active Storage flaw with RCE potential » — https://www.bleepingcomputer.com/news/security/rails-patches-critical-active-storage-flaw-with-rce-potential/ — contexte indépendant et impact pour les administrateurs.
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet