Faille Rails Active Storage : vérifiez trois réglages avant le 7 novembre

Faille CVSS 9.8 dans Rails Active Storage : un seul upload d’image peut écrire des fichiers sur le serveur. Trois réglages, la mise à jour et l’échéance Rails 8.0.

Presque toutes les applications Rails qui acceptent une photo de profil, un document ou une photo de produit font passer ce fichier par Active Storage. Le 4 novembre 2026, l’équipe Rails a publié un avis de sécurité critique concernant ce chemin d’upload. Dans certaines configurations courantes, un seul fichier forgé peut permettre à un attaquant non authentifié d’écrire des fichiers sur votre serveur.

Votre exposition dépend de trois réglages faciles à vérifier. Cet article explique la faille, montre comment contrôler chaque réglage et indique quoi faire si vous ne pouvez pas mettre à jour dès aujourd’hui. Il concerne surtout les équipes sous Rails 8.0, car le support de sécurité de cette branche prend fin le 7 novembre 2026.

En quoi consiste la faille

Lorsqu’un fichier est attaché, Active Storage lance un analyseur pour en lire les informations de base, comme les dimensions d’une image. Avec le processeur :mini_magick, cet analyseur transmet le fichier à ImageMagick. ImageMagick prend en charge de nombreux formats grâce à des modules appelés coders, dont certains sont très puissants : le commit de correction montre un SVG envoyé par l’utilisateur atteignant le coder MSL, un format de script capable de lire et d’écrire les fichiers nommés dans son script. Active Storage ne limitait pas les coders accessibles à un upload, si bien que la politique ImageMagick du serveur était la seule protection.

Deux points rendent la faille grave. D’abord, l’analyseur s’exécute dès l’attachement : aucune variante, aucun aperçu ni appel explicite à analyze n’est nécessaire, il suffit d’accepter l’upload. Ensuite, les applications qui stockent les fichiers avec le service Disk peuvent aussi être amenées à lire n’importe quel fichier lisible par le processus de l’application. Cela inclut secret_key_base et les identifiants d’autres systèmes, ce qui peut mener à une exécution de code à distance ou à un mouvement latéral.

La faille a été signalée par RyotaK de GMO Flatt Security via HackerOne. L’équipe Rails précise qu’une seule chaîne d’attaque a été signalée et qu’elle ne présume pas que ce soit la seule. L’avis n’indique pas si la faille a été exploitée.

Le test d’exposition en trois conditions

Vous n’êtes concerné que si les trois conditions sont réunies. Vérifiez-les dans l’ordre : si l’une d’elles n’est pas remplie, cette chaîne d’attaque ne s’applique pas, même si la mise à jour reste la bonne décision.

Condition	Où regarder	Exposé si
1. Processeur de variantes	config.active_storage.variant_processor et load_defaults	Il vaut :mini_magick (la valeur par défaut avec load_defaults 6.1 ou antérieur)
2. Politique ImageMagick	Le fichier policy.xml du serveur	Elle ne bloque pas MSL, les coders Ghostscript ni le délégué gs (ce que ne font pas les politiques par défaut de Debian et Ubuntu)
3. Qui peut envoyer des fichiers	Vos formulaires d’upload et vos API	Des utilisateurs non fiables peuvent attacher des fichiers

1. Quel processeur Active Storage utilise-t-il ?

Cherchez dans votre configuration et interrogez l’application en cours d’exécution :

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Depuis Rails 7.0, la valeur par défaut est :vips, mais les applications mises à niveau depuis d’anciennes versions chargent souvent encore d’anciens paramètres par défaut ou définissent :mini_magick explicitement. Vérifiez aussi bundle info mini_magick : si la gem figure dans votre bundle, identifiez où elle est utilisée.

2. Votre politique ImageMagick bloque-t-elle les coders dangereux ?

Affichez la politique réellement chargée par ImageMagick sur chaque serveur d’application et chaque worker :

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

Recherchez des règles avec rights="none" pour le coder MSL, les coders PostScript et PDF, et le délégué gs. Si vous utilisez sans modification la politique fournie par les paquets Debian ou Ubuntu, partez du principe qu’ils ne sont pas bloqués. N’oubliez pas que les images de conteneurs et les hôtes de workers peuvent utiliser un build d’ImageMagick différent de celui de vos serveurs web.

3. Des utilisateurs non fiables peuvent-ils envoyer des fichiers ?

Recensez tous les endroits où un fichier atteint attach, has_one_attached ou has_many_attached, y compris les API, les uploads directs et les outils d’administration qui importent des fichiers externes. Une inscription publique avec un champ d’avatar compte comme source non fiable.

Le correctif : chemins de mise à jour par branche

Les versions corrigées sont Rails 8.1.4.1 et Rails 8.0.5.2. Elles corrigent au total 21 problèmes de sécurité et méritent donc d’être installées même si vous n’êtes pas exposé à celui-ci.

Votre branche	Que faire
8.1	Passer à 8.1.4.1
8.0	Passer à 8.0.5.2 dès maintenant, puis planifier la migration vers 8.1 : le support de sécurité de 8.0 prend fin le 7 novembre 2026
7.2 et antérieures	Aucun correctif ne sera publié. Appliquez le contournement par politique ci-dessous et passez à 8.0 ou supérieur

Les applications qui utilisent :mini_magick ont aussi besoin de mini_magick 5.1 ou supérieur. Avec une version plus ancienne, la version corrigée lève une erreur au démarrage : mettez donc les deux gems à jour ensemble et testez le démarrage en préproduction :

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

Les versions corrigées embarquent leur propre politique ImageMagick, mais vérifiez qu’elle atteint bien ImageMagick. Elle ne s’applique pas si votre application remplace MiniMagick.cli_env après le démarrage, utilise MiniMagick.cli_prefix ou installe son propre MiniMagick::Shell ; ces applications doivent placer les règles dans la politique système. GraphicsMagick ne lit pas du tout les politiques ImageMagick. Par ailleurs, la politique fournie s’ajoute au policy.xml de votre serveur au lieu de le remplacer : une règle d’autorisation présente dans ce fichier, y compris un joker, l’emporte donc sur le blocage.

Les mêmes versions corrigent une seconde faille, GHSA-v924-7rp8-4mxh (CVSS 8.8). Active Storage transmettait les fichiers à ImageMagick et FFmpeg sous des noms temporaires qui conservaient l’extension d’origine, de sorte qu’un attaquant maîtrisant le nom de fichier et le type de contenu déclaré pouvait influer sur le décodeur utilisé. Les contournements proposés par Rails pour cette faille ne couvrent que FFmpeg, raison de plus pour mettre à jour plutôt que de s’appuyer sur des contournements.

Une tendance, pas un cas isolé

En juillet 2026, CVE-2026-66066 était une autre faille critique d’Active Storage, touchant les applications utilisant libvips. Les applications sous ImageMagick n’étaient pas exposées à ce chemin, mais elles le sont à celui-ci. Deux failles critiques en quatre mois, via les deux bibliothèques d’images prises en charge, mènent à la même leçon : le traitement d’images est une vaste surface d’attaque, et Active Storage l’exécute sur des fichiers d’inconnus dès qu’ils sont attachés.

Changer de processeur ne suffit pas à corriger le problème. Ce qui vous protège, c’est de considérer la bibliothèque d’images comme faisant partie de votre surface d’attaque : la maintenir à jour comme le framework, la restreindre par une politique et savoir sur quels hôtes elle tourne. La politique ImageMagick, en particulier, est un réglage serveur facile à oublier, car elle se trouve dans l’image du système d’exploitation et non dans le code de votre application.

Si vous ne pouvez pas mettre à jour immédiatement

Rails a également publié des commits de correctif pour 8.1 et 8.0. En attendant de pouvoir déployer une version corrigée, suivez cette liste de contrôle :

1. Ajoutez les règles minimales de l’avis à la politique système d’ImageMagick sur chaque hôte qui traite des uploads (par exemple /etc/ImageMagick-7/policy.xml).
2. Assurez-vous qu’aucune règle d’autorisation ni aucun joker dans ce même fichier ne les annule, puis vérifiez avec magick -list policy.
3. Si vous générez des PDF ou du PostScript via ImageMagick, réautorisez le délégué gs et uniquement les coders dont vous avez besoin, en acceptant qu’un certain risque subsiste.
4. Encadrez les uploads : restreignez temporairement qui peut attacher des fichiers, ou suspendez les uploads anonymes.
5. Si vous utilisez le service Disk, prévoyez de renouveler secret_key_base, la master key et le contenu de config/credentials.yml.enc, les identifiants de stockage et de base de données, ainsi que les jetons de services tiers. Ne conservez pas un secret exposé comme solution de repli.

Les règles minimales publiées dans l’avis sont les suivantes :

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

Consultez tous les détails dans l’avis de sécurité Rails.

Comment LOGIQ peut vous aider

LOGIQ accompagne les équipes qui exploitent des stacks open source sous Linux, de l’image du système d’exploitation jusqu’au runtime applicatif. Si vous souhaitez de l’aide pour vérifier les politiques ImageMagick sur vos serveurs, ou pour planifier la sortie d’une branche en fin de support, contactez notre équipe.