CVE-2026-66066 « KindaRails2Shell » : un faux fichier MATLAB vole la clé secrète de Rails et ouvre un RCE

Rapport CTI technique du 1er septembre 2026

Résumé exécutif

CVE-2026-66066, surnommée KindaRails2Shell, exploite une confusion de parseur sur quatre couches empilées : Rails, libvips, libmatio et HDF5. Un fichier construit pour se faire passer à la fois pour un fichier MATLAB et pour un conteneur HDF5 est uploadé via une fonctionnalité d'image ordinaire. Quand Active Storage tente d'en générer une variante via libvips, le processeur d'image par défaut de Rails depuis la version 7.0, le parseur bascule sur l'interprétation trompeuse du fichier et permet à l'attaquant de lire des fichiers arbitraires accessibles au processus Rails, y compris les variables d'environnement contenant SECRET_KEY_BASE. Notée 9.5 en CVSS v4, la faille ne demande aucune authentification.

Rails a corrigé le défaut le 29 juillet 2026 dans les versions 7.2.3.2, 8.0.5.1 et 8.1.3.1, mais une mise à jour de Rails seule ne suffit pas : libvips doit être porté en version 8.13 ou supérieure. Un PoC public a suivi rapidement la divulgation. VulnCheck a recensé environ 7 000 instances Rails exposées et encore vulnérables début août, et a observé, la semaine du 24 août, une exploitation active contre ses honeypots à Singapour, en Israël et au Royaume-Uni. SecurityWeek qualifiait encore la faille de « dans le viseur des attaquants » dans une publication du 31 août, cinq semaines après le correctif initial.

Chronologie

Date	Événement
29 juillet 2026	Rails publie CVE-2026-66066 et les correctifs 7.2.3.2, 8.0.5.1, 8.1.3.1
Fin juillet - début août 2026	Rétro-ingénierie communautaire, publication d'un PoC public et d'outils forensiques Rails
Début août 2026	VulnCheck recense environ 7 000 instances Rails exposées et vulnérables
Semaine du 24 août 2026	VulnCheck observe une exploitation active contre des honeypots à Singapour, en Israël et au Royaume-Uni
31 août 2026	SecurityWeek et d'autres médias republient des alertes sur l'exploitation active en cours

Fiche vulnérabilité (format fiche CTI)

CVE-2026-66066 | CVSS 9.5 (v4) | Ruby on Rails, Active Storage avec libvips

Initialisation de ressource avec un défaut non sécurisé (CWE-1188). Le fichier malveillant s'ouvre par la chaîne ASCII « MATLAB 5.0 » propre à l'en-tête MAT, suivie d'un superbloc HDF5 placé derrière un userblock de 512 octets, avec la signature \x89HDF\r\n\x1a\n à l'offset 512. Ce montage crée un fichier à double identité : libmatio le traite comme un fichier MATLAB pendant que la couche HDF5 sous-jacente ouvre une voie de lecture de fichier détournée par libvips lors de la génération d'une variante d'image. Le résultat expose des fichiers arbitraires accessibles au processus Rails, en particulier SECRET_KEY_BASE. Une fois ce secret en main, l'attaquant dérive la clé de vérification Active Storage et forge un JSON de variation signé contenant un appel instance_eval, ce qui donne l'exécution de code.

Conditions d'exploitation : application Rails utilisant Active Storage avec libvips comme processeur d'image (comportement par défaut depuis Rails 7.0) et acceptant des uploads d'images provenant d'utilisateurs non fiables ; aucune authentification requise. Versions Active Storage concernées : inférieures à 7.2.3.2, la branche 8.0 avant 8.0.5.1, et la branche 8.1 avant 8.1.3.1. PoC disponible : oui, publié sur GitHub après rétro-ingénierie communautaire (dépôt shinthink/CVE-2026-66066). Patch/mitigation : mise à jour vers Rails 7.2.3.2, 8.0.5.1 ou 8.1.3.1, mise à jour conjointe de libvips vers 8.13 ou une version ultérieure, et rotation de SECRET_KEY_BASE après correction, une mise à jour de Rails seule sans mise à jour de libvips laisse la chaîne exploitable.

Diagramme de la chaîne d'attaque

Vue swimlane attaquant/défense construite à partir des publications Rails, Rapid7, Akamai et VulnCheck.

Analyse technique

Étape 1 : construction du fichier à double identité

L'attaquant façonne un fichier qui commence par l'en-tête MAT « MATLAB 5.0 » puis intègre un superbloc HDF5 valide après un userblock de 512 octets. Ce montage exploite le fait que libmatio et la bibliothèque HDF5 sous-jacente peuvent interpréter des offsets différents d'un même flux d'octets comme des en-têtes légitimes.

Étape 2 : upload via une fonctionnalité image ordinaire

Le fichier est soumis à une fonctionnalité d'upload d'image standard de l'application Rails ciblée. Aucune authentification n'est requise dès lors que le point de upload accepte des images de visiteurs non authentifiés, un cas fréquent sur les formulaires publics.

Étape 3 : confusion de parseur lors de la génération de variante

Quand Active Storage déclenche la génération d'une variante de l'image via libvips, le parseur suit la chaîne d'interprétation trompeuse construite à l'étape 1 et exécute une opération de lecture de fichier non prévue, exposant des chemins du système de fichiers accessibles au processus Rails.

Étape 4 : vol de SECRET_KEY_BASE et forge de la clé de vérification

Parmi les fichiers accessibles, l'attaquant cible les variables d'environnement contenant SECRET_KEY_BASE. Ce secret permet de dériver la clé de vérification utilisée par Active Storage pour signer les JSON de variation.

Étape 5 : exécution de code via variation forgée

Avec la clé de vérification en main, l'attaquant forge un JSON de variation signé contenant un appel instance_eval, que Rails accepte comme légitime puisqu'il porte une signature valide, ce qui aboutit à l'exécution de code arbitraire côté serveur.

Indicateurs de compromission

Type	Valeur
Fichier suspect	Upload d'image commençant par la signature ASCII « MATLAB 5.0 » suivie d'un superbloc HDF5 à l'offset 512
Comportement applicatif	Erreurs de génération de variante Active Storage inattendues dans les journaux Rails
Réseau	Requêtes d'upload d'image répétées ou automatisées vers des endpoints publics d'applications Rails, observées par VulnCheck sur des honeypots à Singapour, en Israël et au Royaume-Uni

Les journaux d'accès et hachages spécifiques aux campagnes d'exploitation observées par VulnCheck n'ont pas été détaillés publiquement au-delà de la localisation géographique des honeypots touchés ; ils ne sont donc pas reproduits ici.

MITRE ATT&CK

Tactique	Technique	ID	Justification
Initial Access	Exploit Public-Facing Application	T1190	Exploitation d'un point de upload d'image public d'une application Rails
Credential Access	Unsecured Credentials	T1552	Lecture de fichiers arbitraires pour récupérer SECRET_KEY_BASE dans les variables d'environnement
Defense Evasion	Impersonation	T1656	Fichier construit pour se faire passer simultanément pour un format MATLAB et un conteneur HDF5 légitimes
Execution	Exploitation for Client Execution	T1203	Exécution de code via la variation forgée et l'appel instance_eval

Cette cartographie est une lecture technique construite à partir des analyses Rapid7 et Akamai ; aucune cartographie ATT&CK officielle n'a été publiée par un éditeur pour cette vulnérabilité au moment de la rédaction.

Remédiation : checklist opérationnelle

Mettre à jour Rails vers 7.2.3.2, 8.0.5.1 ou 8.1.3.1 selon la branche utilisée, sans délai sur les instances exposées à Internet.
Mettre à jour libvips vers la version 8.13 ou une version ultérieure : une mise à jour de Rails seule ne referme pas la chaîne d'exploitation.
Effectuer une rotation de SECRET_KEY_BASE sur toute application ayant pu être exposée avant le correctif, en particulier celles ayant accepté des uploads d'images publics.
Auditer les journaux Active Storage à la recherche d'erreurs de génération de variante inhabituelles sur la période de fin juillet à fin août.
Restreindre les types de fichiers acceptés sur les points de upload publics et valider le contenu réel des fichiers plutôt que leur seule extension déclarée.
Utiliser les outils forensiques publiés par l'équipe Rails pour vérifier une éventuelle exploitation passée sur les instances non corrigées.
Recenser les instances Rails exposées à Internet utilisant Active Storage avec libvips, sur le modèle du scan mené par VulnCheck, pour prioriser la remédiation.