7.100 servidores Rails en la mira: la vulnerabilidad KindaRails2Shell ya se está explotando en ataques
Un solo archivo especialmente preparado puede dar acceso a claves, tokens y credenciales.
Una vulnerabilidad crítica de Ruby on Rails, que hace apenas un mes parecía un escenario extremadamente peligroso pero teórico, ha llegado a servidores reales. VulnCheck registró la explotación de CVE-2026-66066, conocida como KindaRails2Shell, en sus honeypots en Singapur, Israel y Reino Unido. La actividad procedía de una sola dirección IP en Francia, y tras una intrusión exitosa el atacante establecía comunicación con un servidor de mando en Israel.
El problema afecta a Active Storage, el mecanismo integrado en Ruby on Rails para manejar archivos subidos. Las aplicaciones vulnerables usan la biblioteca libvips para procesar imágenes y permiten que usuarios no confiables suban imágenes. A partir de Rails 7, libvips se emplea en esa configuración por defecto. El fallo obtuvo 9,5 de 10 según CVSS y permite atacar el servidor sin autenticación.
La mecánica de KindaRails2Shell se basa en que distintas partes del sistema identifican de forma diferente el tipo de un mismo archivo. Rails en una carga directa puede aceptar el tipo de contenido indicado por el cliente, mientras que libvips más tarde inspecciona la firma real del archivo. Un objeto especialmente preparado pasa por varios manejadores de formato hasta que la biblioteca HDF5 accede a un archivo externo en el servidor. Como resultado, el contenido elegido por el atacante se convierte efectivamente en píxeles de imagen y se devuelve al exterior. Los desarrolladores de Rails describieron más tarde la cadena tras la aparición de pruebas de concepto de terceros.
El principal peligro no es tanto la lectura de archivos aislados, sino los secretos de la aplicación. A través de variables de entorno y de la configuración se pueden obtener secret_key_base, la clave maestra de Rails, contraseñas de bases de datos, claves de almacenamiento en la nube y tokens de servicios externos. El secreto secret_key_base permite falsificar datos que Rails considera firmados por la propia aplicación. Una cadena de explotación posterior puede llegar a una deserialización Marshal insegura y terminar en ejecución remota de código.
La vulnerabilidad fue encontrada de forma independiente por los especialistas de Ethiack y por el investigador RyotaK de GMO Flatt Security. Los desarrolladores de Rails publicaron correcciones el 29 de julio en Active Storage 7.2.3.2, 8.0.5.1 y 8.1.3.1. Para operar con seguridad también se requiere libvips en la versión 8.13 o posterior, ya que las compilaciones más antiguas no saben bloquear operaciones inseguras para archivos no confiables.
La rapidez en la transición de la investigación a los ataques reales fue bastante previsible. Ya a principios de agosto VulnCheck preparó su propio exploit funcional y contabilizó más de 7100 instancias de Rails accesibles desde Internet. Junto con el exploit, la empresa creó reglas Sigma, Suricata, Snort y YARA, además de volcados de red para detectar intentos de explotación. Varias semanas después, los honeypots de VulnCheck comenzaron a recibir tráfico malicioso real.
Una sola actualización de Rails no es suficiente si el servidor pudo haber estado accesible a ataques antes de aplicar el parche. Los desarrolladores recomiendan considerar comprometidos todos los secretos que el proceso de la aplicación pudo haber leído y reemplazar secret_key_base, la clave maestra, las credenciales de la base de datos, las claves de S3, Google Cloud Storage o Azure y los tokens de servicios externos. Cambiar secret_key_base también finalizará las sesiones de usuario existentes y invalidará los datos firmados antiguos.
Para verificar sistemas ya actualizados, el equipo de Rails publicó herramientas que ayudan a determinar el período de vulnerabilidad y a buscar rastros de KindaRails2Shell en Active Storage y en el almacenamiento de objetos. El ataque deja una marca inusual: la versión procesada de la imagen puede contener bytes robados del servidor directamente entre los datos de píxeles. Por eso los administradores de sistemas Rails ahora deben averiguar no solo si está instalado el último lanzamiento, sino también si alguien aprovechó la ventana de un mes entre la divulgación de KindaRails2Shell y la confirmación de explotación.