Ruby on Rails lanzó parches para una vulnerabilidad crítica (CVE-2026-66066) en Active Storage que permite a atacantes leer archivos arbitrarios y secretos del servidor mediante la carga de imágenes manipuladas. El fallo afecta a versiones desde Rails 6.0 hasta 8.1 que utilicen libvips, pudiendo derivar en la ejecución remota de código. Se recomienda actualizar a las versiones corregidas y rotar todas las credenciales y claves secretas del sistema.







Ruby on Rails ha lanzado correcciones para una vulnerabilidad crítica de Active Storage que podría permitir a atacantes no autenticados leer archivos arbitrarios de los servidores de aplicaciones mediante la carga de imágenes manipuladas.

Rastreado como CVE-2026-66066 (puntuación CVSS: 9.5), el fallo puede exponer el entorno de proceso de Rails y secretos como secret_key_base, la clave maestra de Rails, contraseñas de bases de datos, credenciales de almacenamiento en la nube y tokens de API. Estos secretos podrían permitir la ejecución remota de código (RCE) o el movimiento lateral hacia sistemas conectados.

Las aplicaciones afectadas utilizan libvips para el procesamiento de imágenes de Active Storage y aceptan cargas de imágenes de usuarios no confiables. Rails selecciona Vips bajo load_defaults 7.0, y las versiones posteriores lo mantienen por defecto.

Ethiack y GMO Flatt Security enumeran los rangos afectados como Rails 7.0.0 hasta 7.2.3.1, Rails 8.0.0 hasta 8.0.5, y Rails 8.1.0 hasta 8.1.3. Las versiones de Rails 6.0.0 hasta 6.1.7.10 están afectadas solo cuando Active Storage está configurado para usar Vips, que no era el procesador predeterminado en Rails 6.

El aviso oficial indica un rango de paquetes más amplio: activestorage < 7.2.3.2. Ambos equipos de investigación sitúan la ruta de ataque práctica de Vips en Rails 6.0 y posteriores. Las aplicaciones que utilizan MiniMagick no están expuestas a través de esta ruta de ataque específica. Rails 7.0 y 7.1 han llegado al final de su vida útil y no tienen versiones corregidas, por lo que las aplicaciones en esas ramas deben actualizar a Rails 7.2.3.2 o posterior.

Debes actualizar a Rails 7.2.3.2, 8.0.5.1, o 8.1.3.1 y rotar cada secreto que sea legible por el proceso de la aplicación. Las instalaciones parcheadas requieren libvips 8.13 o posterior y, cuando ruby-vips esté instalado, ruby-vips 2.2.1 o posterior.

Ningún equipo de investigación había publicado una prueba de concepto (PoC) hasta las 17:30 UTC del 29 de julio de 2026. Búsquedas de términos exactos no encontraron ningún repositorio de exploits en GitHub, GitLab, Exploit-DB o Packet Storm en ese momento. Rails advirtió que aplicar el parche no invalida las credenciales que ya puedan haber sido robadas.

El fallo reside en el límite de confianza entre Active Storage y libvips. El aviso de seguridad de Rails https://github.com/rails/rails/security/advisories/GHSA-xr9x-r78c-5hrm dice que libvips admite cargadores, guardadores y otras operaciones, algunas respaldadas por librerías de terceros y marcadas como "no fuzzed" o "no confiables" porque son inseguras para entradas hostiles. Active Storage no las bloqueaba, permitiendo que una carga manipulada invocara una de ellas y revelara archivos legibles por el trabajador de Rails.

Una aplicación vulnerable no necesita exponer una operación dedicada de redimensionamiento o miniatura. "Generar variantes no es un requisito independiente", dijo Rails. El parche público https://github.com/rails/rails/commit/349e7a5d5b4b715af1e416db824f3c078a7d59e5 también muestra que tanto el analizador como el transformador de Vips pasaban adjuntos no confiables a las operaciones inseguras.

Una solicitud exitosa le da al atacante una primitiva de lectura de archivos arbitrarios. La ejecución de código o el movimiento lateral dependería de lo que el atacante extraiga y a qué puedan acceder esas credenciales. Rails te indica que rotes secret_key_base, la clave maestra y credenciales descifradas, credenciales de base de datos, claves de servicio de Active Storage y tokens de terceros.

El parche llama a Vips.block_untrusted(true) cuando Active Storage se inicia. Las aplicaciones que no puedan actualizar Rails inmediatamente pueden configurar VIPS_BLOCK_UNTRUSTED al ejecutar libvips 8.13 o posterior, o llamar a Vips.block_untrusted(true) con ruby-vips 2.2.1 o posterior. Rails afirma que las versiones anteriores de libvips no pueden bloquear estas operaciones, por lo que debes actualizar libvips o eliminarlo de la aplicación.


Rails dio crédito a André Baptista, Bruno Mendes y Rafael Castilho de Ethiack https://ethiack.com/info-hub/research/kindarails2shell-rails-rce-CVE-2026-66066, y a RyotaK de GMO Flatt Security https://blog.flatt.tech/entry/kindarails2shell_rails, por informar el problema de forma independiente. Los investigadores no han revelado el formato malicioso, la construcción de lectura de archivos ni la cadena de RCE. Rails dijo que se publicarán más detalles técnicos a más tardar el 28 de agosto de 2026.

El equipo de seguridad de Rails fue contactada sobre la explotación y las versiones afectadas, y Ethiack sobre la cadena de ataque.

Ni Rails ni los investigadores informaron de una explotación real en el momento de la publicación. Una revisión el 29 de julio a las 17:30 UTC encontró que el CVE-2026-66066 no figuraba en la versión 2026.07.27 del catálogo de Vulnerabilidades Explotadas Conocidas de la CISA https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

No hay un recuento fiable de aplicaciones vulnerables o víctimas nombradas. La puntuación de 9.5 describe la gravedad según el CVSS, no cuántos despliegues están expuestos: un despliegue vulnerable también debe usar Vips, aceptar cargas de imágenes no confiables e incluir una operación explotable en su compilación de libvips.

Fuente:
THN