Alerte critique sur les rails Active Storage expose les secrets et vous permet de lire des fichiers arbitraires

Une vulnérabilité critique dans le stockage actif de Ruby on Rails, enregistré comme CVE-2026-66066 (CVSS 9.5), permet à un attaquant non authentifié de lire des fichiers arbitraires du serveur d'applications à travers des charges d'images manipulées. La racine de la défaillance n'est pas Rails elle-même, mais l'interaction entre Active Storage et la bibliothèque de traitement d'image libvips : Active Storage a transmis un contenu peu fiable aux opérations libvips marquées « sans confiance » ou « non fuzzy », qui peuvent invoquer des chargeurs et des salvers dangereux capables de renvoyer tous les fichiers accessibles par le processus Rails.

Le scénario pratique qui transforme cet accès en une intrusion grave est l'exposition de secrets dans l'environnement du processus ferroviaire: secret _ clé _ base, clé maître de Rails, déchiffrer les identifiants, mots de passe de base de données, clés de services de stockage et jetons API. Avec ces identificateurs, un attaquant pourrait exécuter un code à distance (CER) sur des services connectés, se déplacer latéralement dans l'infrastructure ou vider des données sensibles dans des services cloud. L'opération exige également que l'application utilise libvips pour le traitement d'image et accepte des charges d'utilisateurs peu fiables; les applications utilisant MiniMagick ne sont pas affectées par cette route spécifique.

Les branches touchées et les versions identifiées par les équipes de recherche sont les rails 7.0.0 à 7.2.3.1, les rails 8.0.0 à 8.0.5 et les rails 8.1.0 à 8.1.3, et les rails 6.0.0 à 6.1.x seulement lorsque le stockage actif est configuré pour utiliser Vips (dans Rails 6 Vips ce n'était pas le processeur par défaut). Rails a publié des correctifs et les versions recommandées à mettre à jour sont 7.2.3.2, 8.0.5.1 et 8.1.3.1. De plus, les installations de traitement nécessitent libvips 8.13 ou plus et, si vous utilisez ruby-vips, version 2.2.1 ou ultérieure. Vous pouvez vérifier les notes de lancement et l'activité de projet dans le dépôt officiel Rails et dans les ressources ruby-vips et libvips pour confirmer les versions et correctifs: https: / / github.com / rails / rails / rejets et https: / / github.com / libvips / ruby-vips.

Pour les opérateurs qui ne peuvent pas appliquer immédiatement le patch Rails, il y a une atténuation temporaire: pour permettre le blocage des opérations libvips peu fiables. Si votre environnement a libvips 8.13 ou supérieur, vous pouvez exporter la variable environnement VIPS _ BLOC _ UNTRUSTED = true ou d ' invoquer Vips.block _ sans confiance (vrai) de rubis-vips 2.2.1 ou plus. Si votre installation utilise une version antérieure de libvips sans cette capacité, la seule alternative sûre est de mettre à jour libvips ou d'arrêter d'utiliser Vips for Active Storage jusqu'à ce que vous puissiez garer Rails et la bibliothèque sous-jacente.

Il est essentiel de comprendre que l'application du patch n'invalide pas les références qui ont déjà été exposées. Rails avertit explicitement qu'après patching, tous les secrets que le processus Rails peut lire doivent être tournés. Au moins, cela inclut secret _ clé _ base, identifiants maître et non chiffrés, mots de passe de base de données, clés de service Active Storage (S3 / GS / etc.) et jetons tiers. La rotation doit être accompagnée d'un audit et d'une vérification : rechercher un accès inhabituel, demander des paramètres qui acceptent des images, transférer des données inattendues et créer de nouveaux comptes ou clés dans des systèmes liés.

Parallèlement à la rotation, les équipes d'intervention devraient saisir et analyser les journaux relatifs au traitement des charges et des images, examiner les instantanés et les sauvegardes par activité suspecte et vérifier l'intégrité des images et des vecteurs d'exécution. S'il y a des soupçons d'exfiltration ou d'engagement préalable, traiter l'incidence comme une intrusion complète : isoler les services engagés, remplacer les titres de compétence dans tous les systèmes dépendants et envisager des vérifications médico-légales. Étant donné qu'un PdC public n'a pas encore été publié et que les avoirs en nature n'ont pas été confirmés au moment de l'avis, les indicateurs d'engagement peuvent être limités; toutefois, la possibilité de lire des fichiers à distance fait de tout signe d'accès anormal une question de priorité.

Du point de vue de l'architecture approfondie et de la défense, il convient de prendre des mesures pour réduire l'impact de défaillances similaires à l'avenir: minimiser la surface de lecture du processus Rails (le faire fonctionner avec le moins de permissions nécessaires), les identifiants de service de segment avec des rôles et des politiques d'accès limités, limiter les types et les tailles de fichiers qu'il accepte Active Storage et appliquer la validation du contenu du côté serveur avant de transmettre des fichiers aux processeurs natifs. Il est également recommandé de mettre en place des alertes pour les opérations de stockage actif à l'étranger et de conserver un inventaire des dépendances natives telles que les libvips en dehors du cycle du paquet Ruby pour pouvoir les garer séparément.

Les découvreurs de la décision ont été accrédités par Rails comme chercheurs d'Ethiack et d'OGM Flatt Security. Rails a indiqué qu'il fournira des détails techniques supplémentaires au plus tard le 28 août 2026, lorsque plus de techniques de détection et de descriptions plus fines du vecteur d'attaque seront probablement arrivées. D'ici là, la recommandation prioritaire est de stationner rapidement, de mettre à jour les libvips et rubis-vips le cas échéant, et de faire pivoter toutes les clés et secrets lisibles par le processus Rails.

Enfin, rappelez-vous que la Le score CVSS 9.5 reflète la sévérité technique et non l'exposition de masse: pour être exploitable l'application doit utiliser Vips pour traiter des images, accepter des charges d'utilisateur peu fiables et avoir une construction libvips qui inclut des opérations dangereuses. Cependant, si votre service répond à ces exigences, traitez cette vulnérabilité comme une urgence opérationnelle et effectuez les mises à jour et rotations recommandées avec la plus grande urgence.