KindaRails2Shell, ataques activos contra Ruby on Rails: archivos subidos para robar secretos y credenciales

A 31 de agosto de 2026, CVE-2026-66066 está siendo explotada activamente contra aplicaciones Ruby on Rails expuestas. La vulnerabilidad, apodada KindaRails2Shell, permite convertir la carga de una imagen manipulada en una lectura arbitraria de los archivos accesibles para el proceso de Rails.

El problema tiene una puntuación CVSS de 9,5 y está clasificado como CWE-1188. Los principales objetivos son las aplicaciones que combinan Active Storage, el procesador de imágenes libvips y cargas procedentes de usuarios no confiables, incluso sin autenticación.

El impacto no se limita a la divulgación de archivos. Los secretos recuperados pueden permitir falsificar sesiones, robar credenciales, acceder a servicios conectados y, en determinadas condiciones, llegar a ejecutar código de forma remota.

Qué versiones de Rails son vulnerables

Según los datos de NVD, están afectadas las versiones de Ruby on Rails anteriores a:

• 7.2.3.2
• 8.0.5.1
• 8.1.3.1

Por tanto, los administradores deben actualizar al menos a la versión corregida disponible para su rama. Entre los componentes implicados se encuentran Ruby on Rails/Action Pack, Active Storage, libvips, libmatio y HDF5.

Sin embargo, no todas las instalaciones de Rails presentan el mismo nivel de exposición. Las aplicaciones con mayor riesgo son las que:

• utilizan Active Storage para recibir y transformar imágenes;
• han configurado libvips como motor de procesamiento;
• permiten cargas anónimas o procedentes de cuentas que no son plenamente confiables;
• ejecutan Rails con acceso a credenciales, claves y configuraciones sensibles del sistema de archivos.

A principios de agosto, VulnCheck identificó aproximadamente 7.000 instancias de Ruby on Rails expuestas y vulnerables. Esta cifra no indica cuántas se actualizaron posteriormente ni cuántas pudieron verse comprometidas.

Rails publicó las correcciones a finales de julio y solicitó actualizar de inmediato las configuraciones expuestas. Poco después, investigadores independientes analizaron el parche, reconstruyeron el fallo y distribuyeron código de prueba de concepto. Según VulnCheck, los ataques comenzaron aproximadamente un mes después de la publicación de las actualizaciones.

De la imagen manipulada a la lectura de archivos locales

KindaRails2Shell aprovecha una discrepancia en la forma en que Rails y las bibliotecas subyacentes determinan el formato de un archivo.

Rails puede tratar un blob como una imagen basándose en el tipo de contenido declarado por el cliente. libvips, en cambio, examina los denominados magic bytes, es decir, las secuencias presentes en el contenido que identifican el formato real. Un atacante puede aprovechar esta diferencia para cargar un objeto presentado a la aplicación como una imagen, pero reconocido por libvips como un archivo MATLAB Level 5.

La cadena continúa a través de varias bibliotecas:

1. Rails acepta la carga como contenido gráfico.
2. libvips detecta los bytes característicos del formato MATLAB.
3. El archivo se pasa a libmatio.
4. Un campo de la cabecera hace que libmatio reconozca la variante MAT 7.3.
5. El procesamiento se transfiere a la biblioteca HDF5.
6. La función External File List de HDF5 recibe una ruta y un desplazamiento controlados por el atacante.

External File List permite que un dataset HDF5 almacene sus datos en un archivo externo. En este escenario, sin embargo, la función se utiliza para leer un archivo local elegido por el atacante. Durante el renderizado, los bytes recuperados pueden incorporarse a la imagen resultante y devolverse en forma de píxeles.

La vulnerabilidad se debe, por tanto, a que Active Storage no deshabilita operaciones inseguras de libvips cuando el contenido procede de fuentes no confiables. No es necesaria una cuenta: basta con alcanzar una función de carga vulnerable.

Secretos de la aplicación, sesiones y movimiento lateral

El atacante puede leer cualquier archivo accesible con los privilegios del proceso de Rails. El alcance depende de la configuración del servidor y de los permisos asignados a la aplicación, pero puede incluir:

• variables de entorno;
• archivos con secretos de la aplicación;
• bases de datos o almacenes de credenciales;
• claves para servicios de almacenamiento;
• configuraciones que contienen tokens;
• material utilizado para firmar sesiones y otros datos de la aplicación.

Entre los elementos más sensibles se encuentra secret_key_base. Su exposición puede comprometer los mecanismos criptográficos que protegen las sesiones, las cookies firmadas y otros objetos generados por la aplicación.

Una vez robados los secretos, el atacante puede falsificar sesiones, suplantar a usuarios legítimos o conectarse a bases de datos e infraestructuras externas. Las credenciales compartidas o las claves con privilegios excesivos también pueden facilitar el movimiento lateral hacia otros sistemas.

Por este motivo, instalar únicamente el parche no necesariamente completa la respuesta al incidente. La actualización bloquea el vector corregido, pero no revoca las credenciales ni las firmas que ya hayan sido robadas.

La duda sobre la variante Marshal incluso después del parche

VulnCheck realizó una comprobación en un servidor actualizado a la versión 8.1.3.1, incluida por NVD entre las versiones correctivas. La prueba habría confirmado el bloqueo de la lectura arbitraria de archivos a través de libvips, pero también habría revelado una posible parte residual de la cadena.

En concreto, una variante relacionada con la deserialización de Marshal y las variation keys podría seguir siendo utilizable si se dispone de una firma válida. En estas condiciones, el gadget para ejecutar código de forma remota seguiría funcionando incluso en el sistema actualizado.

Este hallazgo procede de una única fuente y no demuestra que el parche sea ineficaz contra el vector principal. Sin embargo, introduce una distinción operativa: las versiones corregidas impedirían leer archivos mediante libvips, mientras que aún no está claro si neutralizan todas las posibles fases posteriores de la cadena.

Por tanto, las organizaciones deberían probar por separado las variation keys y la deserialización de Marshal. La comprobación es especialmente urgente si existe sospecha de que las claves de firma u otros secretos ya hayan quedado expuestos.

Catálogo CISA KEV y estado de la amenaza

No existe una indicación verificable de que CVE-2026-66066 haya sido incluida en el catálogo Known Exploited Vulnerabilities de CISA. Por tanto, no hay una fecha de inclusión ni un plazo KEV que se puedan indicar.

Tampoco hay información sobre posibles casos recientes de Ruby on Rails incluidos en el catálogo. No obstante, la explotación activa está respaldada por la telemetría descrita por VulnCheck, con independencia de su estado en KEV.

La actividad no se ha atribuido a un grupo concreto. No se conocen el número de organizaciones afectadas, los objetivos prioritarios ni posibles indicadores de compromiso asociados a una campaña específica.

Actualización, búsqueda de indicios y rotación de secretos

La primera medida es actualizar Rails al menos a 7.2.3.2, 8.0.5.1 o 8.1.3.1, según la versión correspondiente a la rama utilizada. Los sistemas con Active Storage, libvips y cargas no autenticadas deben recibir prioridad.

Si la actualización no puede aplicarse de inmediato, conviene deshabilitar temporalmente las cargas de imágenes o trasladar su procesamiento a un entorno aislado. El proceso solo debería tener acceso a los archivos imprescindibles y no poder leer secretos, credenciales ni las configuraciones de toda la aplicación.

Rails también ha publicado herramientas forenses para detectar intentos de explotación. A falta de indicadores públicos más específicos, los equipos defensivos deberían examinar:

• solicitudes de carga anómalas o contenidos cuyo tipo declarado no sea coherente;
• actividad inusual de los procesos de libvips;
• accesos inesperados a archivos locales durante el renderizado;
• errores relacionados con MATLAB, libmatio o HDF5;
• generación sospechosa de variation keys;
• sesiones creadas o utilizadas de forma incompatible con el comportamiento habitual de los usuarios.

Si una aplicación vulnerable permaneció expuesta, deben considerarse potencialmente comprometidos secret_key_base, las credenciales y las claves de almacenamiento accesibles para el proceso. Estos valores deben rotarse y las sesiones existentes deben revocarse o regenerarse.

Por último, las pruebas posteriores al parche deben cubrir tanto la carga maliciosa a través de libvips como la posible variante Marshal. KindaRails2Shell ya no es solo un riesgo teórico: los ataques activos hacen necesaria también una revisión retrospectiva para determinar si se produjo un posible robo de secretos.