Ruby on Rails ha lanzado parches para una vulnerabilidad crítica en Active Storage que podría permitir a atacantes no autenticados leer archivos arbitrarios de los servidores de aplicaciones a través de la subida de imágenes manipuladas.
La vulnerabilidad, rastreada como CVE-2026-66066 (puntuación CVSS: 9.5), 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 o el movimiento lateral hacia sistemas conectados.
Las aplicaciones afectadas utilizan libvips para el procesamiento de imágenes de Active Storage y aceptan subidas de imágenes de usuarios no confiables. Rails selecciona Vips bajo load_defaults 7.0, y las versiones predeterminadas posteriores lo mantienen.
Ethiack y GMO Flatt Security enumeran los rangos afectados como Rails 7.0.0 a 7.2.3.1, Rails 8.0.0 a 8.0.5 y Rails 8.1.0 a 8.1.3. Las versiones Rails 6.0.0 a 6.1.7.10 solo se ven afectadas cuando Active Storage está configurado para usar Vips, que no era el procesador predeterminado en Rails 6.
El aviso oficial enumera 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 usan 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.
Los operadores deben actualizar a Rails 7.2.3.2, 8.0.5.1 u 8.1.3.1 y rotar cada secreto 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.
Ninguno de los equipos de investigación había publicado una prueba de concepto (PoC) hasta las 17:30 UTC del 29 de julio de 2026. Búsquedas exactas realizadas por The Hacker News no encontraron repositorios de exploits en GitHub indexado, GitLab, Exploit-DB ni en resultados de Packet Storm al mismo tiempo. Rails advirtió que aplicar el parche no invalida las credenciales que ya podrían haber sido robadas.
La falla se sitúa en el límite de confianza entre Active Storage y libvips. El aviso de seguridad de Rails indica que libvips admite cargadores, salvadores y otras operaciones, algunas respaldadas por bibliotecas de terceros y marcadas como "no fuzzed" o "no confiables" porque no son seguras para entradas hostiles. Active Storage no las bloqueaba, lo que permitía que una carga manipulada invocara una y divulgara 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 separado", dijo Rails. El parche público también muestra que tanto el analizador como el transformador de Vips pasaban archivos adjuntos no confiables a las operaciones inseguras.
Una solicitud exitosa otorga al atacante una primitiva de lectura de archivos arbitrarios. La ejecución de código o el movimiento lateral dependerían de lo que el atacante extraiga y a qué puedan acceder esas credenciales. Rails indica a los operadores rotar secret_key_base, la clave maestra y las credenciales descifradas, las credenciales de la base de datos, las claves de servicio de Active Storage y los 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 dice que las versiones anteriores de libvips no pueden bloquear estas operaciones, por lo que las aplicaciones deben actualizar libvips o eliminarlo de la aplicación.
Rails agradeció a André Baptista, Bruno Mendes y Rafael Castilho de Ethiack, y a RyotaK de GMO Flatt Security, por informar el problema de forma independiente. Los investigadores no han divulgado 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.
The Hacker News se ha puesto en contacto con el equipo de seguridad de Rails sobre la explotación y las versiones afectadas, y con Ethiack sobre la cadena de ataque. Ni Rails ni los investigadores informaron de explotación activa en el momento de la publicación. Una revisión de The Hacker News a las 17:30 UTC del 29 de julio encontró que CVE-2026-66066 no figuraba en la versión 2026.07.27 del catálogo de vulnerabilidades explotadas conocidas de CISA.
No hay un recuento confiable de aplicaciones vulnerables ni víctimas nombradas. La puntuación de 9.5 describe la gravedad según CVSS, no cuántos despliegues están expuestos: un despliegue vulnerable también debe usar Vips, aceptar subidas de imágenes no confiables e incluir una operación explotable en su compilación de libvips.