CVE-2026-66066 perce Rails Active Storage — une faille critique livre la clé maîtresse de votre application en une requête

Vendredi 1er août 2026. L’équipe Rails publie un correctif pour la CVE-2026-66066, une vulnérabilité classée critique dans le framework Active Storage. Un attaquant non authentifié peut lire n’importe quel fichier du serveur en uploadant une image spécialement conçue — et, si l’environnement du processus contient la secret_key_base, escalader vers une exécution de code à distance (RCE). Akamai a baptisé la chaîne d’attaque « KindaRails2Shell ».

L’impact est massif. Active Storage est le composant intégré de Rails pour la gestion des fichiers uploadés. Il est activé par défaut dans la plupart des projets Rails 7 et 8. La faille touche les versions antérieures à 7.2.3.2, les branches 8.0.x avant 8.0.5.1 et 8.1.x avant 8.1.3.1. Rails 6.x n’est concerné que si Active Storage a été configuré hors des paramètres par défaut.

Le vecteur : libvips, le processeur d’image par défaut

La vulnérabilité réside dans l’interaction entre Active Storage et libvips, le processeur d’image utilisé par défaut dans les images Docker officielles de Rails ainsi que dans les installations Debian et Ubuntu.

Quand un utilisateur upload une image, Active Storage peut générer des miniatures via libvips. CVE-2026-66066 permet à un attaquant de soumettre une image spécialement conçue qui force libvips à lire des fichiers arbitraires sur le serveur. Les conditions d’exploitation sont simples :

• L’application autorise l’upload d’images par des utilisateurs non authentifiés (formulaire de contact avec pièce jointe, avatar public, inscription avec photo).
• libvips est utilisé comme processeur d’image, ce qui est le comportement par défaut.
• La version de libvips est antérieure à 8.13.

Si ces trois conditions sont réunies, l’attaquant peut lire le contenu du fichier .env, qui contient généralement la secret_key_base — la clé maîtresse cryptographique de l’application. Selon Akamai, cette clé permet de forger des cookies de session, de signer des Global ID et de manipuler des données sérialisées, ce qui ouvre directement la porte à une RCE complète sur le serveur sous-jacent.

Pas de workaround pour libvips < 8.13

L’équipe Rails recommande trois actions en parallèle :

1. Mettre à jour Rails vers les versions corrigées (7.2.3.2, 8.0.5.1 ou 8.1.3.1).
2. Mettre à jour libvips vers la version 8.13 ou supérieure. Pour les administrateurs utilisant déjà libvips ≥ 8.13, un mécanisme de contournement temporaire existe : définir la variable d’environnement VIPS_BLOCK_UNTRUSTED ou appeler Vips.block_untrusted(true) avec ruby‑vips ≥ 2.2.1.
3. Rotation complète des secrets : secret_key_base, identifiants de base de données, clés de service Active Storage, et tout autre secret accessible au processus de l’application.

Pour les applications utilisant libvips avant 8.13, il n’existe aucun workaround. La mise à jour de libvips est obligatoire.

Les utilisateurs d’ImageMagick ne sont pas affectés par ce vecteur spécifique. Cependant, libvips reste le processeur par défaut dans l’écosystème Rails moderne.

Divulgation accélérée par un PoC public

L’équipe Rails avait initialement prévu de publier les détails techniques le 28 août 2026, laissant un mois aux administrateurs pour patcher. Ce plan a été bouleversé par l’apparition de preuves de concept (PoC) publiques quelques jours seulement après la publication du correctif.

Les mainteneurs ont alors décidé de publier l’intégralité des détails techniques ainsi qu’une boîte à outils d’investigation forensique, estimant que la rétention d’information n’offrait plus de protection réelle.

La vulnérabilité a été découverte et signalée de manière responsable par des chercheurs d’Ethiack et de GMO Flatt Security Inc. Akamai a coordonné avec Ethiack avant la divulgation pour préparer des protections WAF (Web Application Firewall) pour ses clients.

La protection WAF est un sparadrap

Ethiack a tempéré l’enthousiasme autour des protections WAF : un attaquant disposant d’outils d’IA peut reconstruire la chaîne d’attaque à partir du diff du patch. La correction modifie le comportement de libvips dans Active Storage — une analyse du diff permet de déduire le vecteur et de construire un exploit.

Le message est clair : le patching est la seule protection durable. Un WAF peut gagner quelques heures ou quelques jours, pas plus.

Verdict

Si votre application Rails accepte des uploads de fichiers — et presque toutes le font, ne serait-ce que pour les avatars ou les pièces jointes — appliquez le correctif aujourd’hui. Le délai entre la publication du correctif et l’apparition de PoC publics a été de quelques jours. Le délai avant l’exploitation en masse sera du même ordre.

Trois priorités :

1. Mettez à jour Rails (bundle update rails) et libvips (≥ 8.13) immédiatement. Si vous utilisez l’image Docker officielle, reconstruisez avec la dernière version.
2. Lancez une rotation complète des secrets après la mise à jour — une secret_key_base compromise avant le patch reste valide après si vous ne la changez pas.
3. Auditez vos logs d’upload pour les jours précédant le 1er août. Recherchez des uploads d’images provenant d’adresses IP inhabituelles ou des patterns de requêtes suspects vers les endpoints Active Storage.

Pour les applications qui ne peuvent pas être patchées immédiatement, désactivez temporairement l’upload d’images par les utilisateurs non authentifiés et placez l’endpoint derrière une authentification stricte.

Références

• Rails Security Advisory, « CVE-2026-66066 — Arbitrary file read in Active Storage », 1er août 2026
• Akamai Security Research, « KindaRails2Shell: From File Read to RCE in Rails Active Storage », août 2026
• Ethiack, « Responsible Disclosure: Rails Active Storage RCE », août 2026
• BleepingComputer, « Rails patches critical Active Storage flaw with RCE potential », 1er août 2026