Un attaquant sans authentification peut forcer une application Ruby on Rails à écrire des fichiers arbitraires sur le serveur, et si les pièces jointes sont stockées sur le disque, lire n’importe quel fichier accessible au processus applicatif. Cette faille, suivie sous la référence GHSA-f3w6-w445-fwh9, touche le mécanisme de traitement d’images d’Active Storage lorsqu’il utilise ImageMagick. Selon les analyses de Rails, cette vulnérabilité permet de compromettre des secrets comme la clé secrète de l’application ou les identifiants des systèmes externes, ouvrant la voie à une exécution de code à distance.

Le problème réside dans la façon dont ImageMagick sélectionne un « coder » en fonction du contenu du fichier fourni. Active Storage ne restreignait pas ces coders, laissant uniquement la politique de sécurité interne à ImageMagick comme barrière. Le risque se matérialise dès l’attachement du fichier, sans qu’une opération de variante ou d’analyse ne soit nécessaire. Un exemple rapporté par l’équipe Rails impliquait le coder MSL, un interpréteur capable de lire et d’écrire des fichiers basés sur son script.

Ce qui est touché et la gravité réelle

Pour qu’une application soit exposée, trois conditions doivent être réunies : elle doit utiliser ImageMagick via config.active_storage.variant_processor = :mini_magick, accepter des téléversements de fichiers provenant d’utilisateurs non fiables, et sa politique de sécurité ImageMagick ne doit pas bloquer les coders concernés. Les politiques standards fournies par Debian ou Ubuntu ne suffisent pas à contrer cette attaque.

L’impact est sévère. Rails attribue à cette faille une note de 9,8 sur l’échelle CVSS. Si les pièces jointes sont stockées sur le disque serveur, l’attaquant peut non seulement écrire des fichiers, mais aussi lire des informations sensibles comme secret_key_base ou les fichiers de configuration contenant les identifiants.

Les correctifs sont intégrés dans les versions activestorage 8.0.5.2 et 8.1.4.1. L’équipe Rails a déployé une politique de sécurité spécifique qui est préfixée dans le chemin de configuration de MiniMagick, assurant ainsi qu’elle s’applique à chaque processus ImageMagick lancé par MiniMagick.

Que faire maintenant

L’impératif, selon les recommandations de Rails, est la mise à jour immédiate. En plus de passer à une version corrigée d’activestorage, les applications utilisant :mini_magick doivent s’assurer d’utiliser mini_magick version 5.1 ou ultérieure, sous peine de faire planter l’application au démarrage. L’entreprise doit aussi vérifier que la nouvelle politique de sécurité est bien chargée par l’application, en exécutant la commande `bin/rails runner ‘puts MiniMagick.identify { |i| i.list

Fiche technique

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

• Ship an ImageMagick security policy for every MiniMagick process · rails/rails@468aa9a, github.com
• Possible arbitrary file write and read in Active Storage image analysis, github.com
• Critical Rails Flaw Lets Attackers Write Server Files via Crafted ImageMagick Uploads, The Hacker News, 4 novembre 2026
• GHSA-xr9x-r78c-5hrm : Active Storage has possible arbitrary file read and remote code execution in Active…, GitHub Advisory Database (CC BY 4.0)
• CVE-2026-66066, NVD (NIST)