Rails Active Storage : CVE-2026-66066, lecture de fichiers

Que décrit la CVE-2026-66066 ?

Selon BleepingComputer (1er août 2026), c'est une vulnérabilité jugée critique par les mainteneurs de Rails, exploitable quand libvips sert à générer des miniatures d'images. Un attaquant envoie une image spécialement forgée et peut lire des fichiers arbitraires sur le serveur. Les données exposées peuvent comprendre l'environnement du processus, qui contient en général secret_key_base et les identifiants des bases de données, du stockage cloud et d'autres services.

L'attaquant n'a pas besoin d'être authentifié. La condition préalable est que le serveur accepte des images envoyées par des utilisateurs non fiables. L'article ne donne pas de score CVSS numérique.

Quelles versions sont concernées ?

• Active Storage avant 7.2.3.2 ;
• 8.0.x avant 8.0.5.1 ;
• 8.1.x avant 8.1.3.1 ;
• Rails 6.x seulement si Active Storage a été configuré hors de ses réglages par défaut.

Les versions corrigées sont 7.2.3.2, 8.0.5.1 et 8.1.3.1. L'article recommande aussi libvips 8.13 ou supérieur. ImageMagick n'est pas concerné par ce vecteur, alors que libvips est le processeur par défaut des images Docker officielles de Rails et des installations Debian et Ubuntu par défaut.

Comment la lecture de fichiers devient-elle une exécution de code ?

Akamai, qui a baptisé la chaîne « KindaRails2Shell », explique qu'une secret_key_base compromise permet de forger des cookies de session, de signer des identifiants globaux et de manipuler des données sérialisées, ce qui mène à une exécution de code complète. Les autres secrets lisibles (identifiants de base, de stockage cloud) ouvrent d'autres chemins de pivot vers l'infrastructure.

Quel est le calendrier de la divulgation ?

Les détails techniques complets étaient prévus pour le 28 août 2026 sur les forums Rails. Des preuves de concept publiques sont apparues rapidement, et les mainteneurs ont publié plus tôt les détails et un outil d'analyse forensique. La faille a été signalée de manière responsable à l'équipe Rails par Ethiack et GMO Flatt Security Inc. ; Akamai a coordonné avec Ethiack avant la divulgation. Akamai a publié des protections pour pare-feu applicatif ; Ethiack souligne qu'un pare-feu ne fait peut-être que gagner du temps, car des attaquants outillés par l'IA pourraient reconstruire l'attaque à partir des différences de correctif.

Que faire, dans l'ordre ?

1. Identifiez vos applications Rails qui acceptent des images de personnes non fiables (avatars, pièces jointes, documents, import par des clients).
2. Mettez à jour Active Storage vers 7.2.3.2, 8.0.5.1 ou 8.1.3.1, et libvips vers 8.13 ou plus.
3. Contournement temporaire sur libvips 8.13 ou plus : définissez la variable d'environnement VIPS_BLOCK_UNTRUSTED, ou appelez Vips.block_untrusted(true) avec ruby-vips 2.2.1 ou supérieur. Il n'existe aucun contournement pour libvips antérieur à 8.13.
4. Faites tourner les secrets que l'application peut lire : secret_key_base, identifiants de base de données, identifiants du service de stockage Active Storage et tous les autres. Changer secret_key_base invalide les sessions existantes.
5. Cherchez des traces : envois d'images inhabituels, requêtes de miniatures sur des fichiers d'origine inconnue, accès aux secrets depuis des adresses nouvelles. Utilisez l'outil d'analyse forensique publié par les mainteneurs.
6. Réduisez le contenu de l'environnement : les secrets ne doivent pas tous être lisibles par le processus web ; limitez-les par service et passez par un gestionnaire de secrets.

Comment tester cette exposition ?

Avec autorisation, sur un environnement de préproduction qui reproduit la production.

1. Versions : relevez les versions de Rails, d'Active Storage et de libvips (vips --version) dans chaque image et chaque serveur.
2. Traitement d'images : vérifiez si les variantes d'images (miniatures, redimensionnement) passent par libvips pour des fichiers envoyés par des utilisateurs.
3. Surface d'envoi : listez les points d'accès qui acceptent un fichier sans authentification.
4. Contournement actif : si vous utilisez la variable de blocage, confirmez qu'elle est définie dans le processus réel (et non seulement dans votre shell) et qu'un fichier de test non fiable est refusé.
5. Contenu de l'environnement : listez ce que le processus web pourrait divulguer s'il était lu, et réduisez cette liste.

Comment durcir durablement le traitement des fichiers envoyés ?

Un envoi de fichier est une entrée contrôlée par un tiers qui traverse des bibliothèques de décodage complexes. Quelques principes limitent l'impact de la prochaine faille de ce type.

• Isoler le traitement : exécutez la génération de miniatures dans un processus ou un conteneur séparé, sans accès aux secrets de l'application, avec un système de fichiers en lecture seule et sans réseau sortant.
• Moindre contenu d'environnement : le processus qui décode des images n'a pas besoin de secret_key_base ni des identifiants de base de données. Séparez les rôles et passez par un gestionnaire de secrets.
• Limiter les formats acceptés : n'acceptez que les types d'images dont vous avez besoin, vérifiez le type réel du contenu et pas seulement l'extension, et plafonnez la taille et les dimensions.
• Traiter hors ligne : placez les fichiers dans une file de traitement et ne servez les variantes qu'après validation, plutôt que de décoder à la volée dans la requête web.
• Surveiller : alertes sur les erreurs de décodage répétées, sur les envois en rafale depuis une même origine et sur les lectures de fichiers inhabituelles par le processus web.
• Mettre à jour les bibliothèques système : libvips est une dépendance du système et des images de conteneurs, pas seulement du Gemfile. Inscrivez-la dans votre inventaire de dépendances et votre routine de mise à jour.

Que chercher dans les journaux pour savoir si vous avez été touché ?

Commencez par la période qui court de la publication des correctifs jusqu'à votre mise à jour, et élargissez si votre application était exposée plus tôt.

• Des demandes de variantes d'images (miniatures, redimensionnements) sur des fichiers envoyés récemment par des comptes inconnus ou par des visiteurs anonymes.
• Des erreurs inhabituelles du traitement d'images, ou des fichiers dont le contenu ne correspond pas à l'extension.
• Des connexions à vos bases ou à votre stockage cloud depuis des adresses inconnues, qui suggèrent l'utilisation d'identifiants volés.
• Des sessions valides pour des comptes qui ne se sont pas connectés, ou des modifications de données sérialisées, qui suggèrent une forge de cookies.

Si vous soupçonnez une lecture, considérez tous les secrets de l'environnement comme exposés, faites-les tourner et invalidez les sessions.

Quel rapport avec les applications d'IA ?

Les produits d'IA reposent souvent sur une application web classique qui reçoit des fichiers : analyse de documents, extraction depuis des images, import de pièces jointes avant résumé par un modèle. Une faille de lecture de fichiers sur ce front expose les mêmes secrets que celles de l'application, y compris les clés d'API de fournisseurs de modèles. Pour le cadre, voyez la page sécurité des agents IA et l'article sur les failles d'octobre 2026 qui touchent les agents.

Le Red Team Agent Express de CleanIssue (1 900 €, 5 jours) teste les agents IA et les flux de fichiers qui les alimentent : voir l'offre. Pour démarrer, un rendez-vous découverte de 30 minutes (gratuit) permet de savoir quels fichiers de stockage votre agent peut atteindre par Active Storage.