Fallo en Rails Active Storage: revise tres ajustes antes del 7 de noviembre

Un fallo CVSS 9.8 en Rails Active Storage deja que una imagen subida escriba archivos en su servidor. Revise tres ajustes, actualice y vigile el plazo de Rails 8.0.

Casi todas las aplicaciones Rails que aceptan una foto de perfil, un documento o una foto de producto envían ese archivo a través de Active Storage. El 4 de noviembre de 2026, el equipo de Rails publicó un aviso crítico sobre esa ruta de subida. En algunas configuraciones habituales, una sola subida manipulada puede permitir que un atacante no autenticado escriba archivos en su servidor.

Que esté expuesto o no depende de tres ajustes fáciles de comprobar. Este artículo explica el fallo, muestra cómo comprobar cada ajuste y enumera qué hacer si no puede actualizar hoy. Es especialmente importante para los equipos que usan Rails 8.0, porque el soporte de seguridad de esa rama termina el 7 de noviembre de 2026.

En qué consiste el fallo

Cuando se adjunta un archivo, Active Storage ejecuta un analizador para leer datos básicos como las dimensiones de la imagen. Con el procesador :mini_magick, ese analizador entrega el archivo a ImageMagick. ImageMagick admite muchos formatos mediante módulos llamados coders, y algunos son muy potentes: el commit de la corrección muestra un SVG subido que llega al coder MSL, un formato de scripts capaz de leer y escribir los archivos indicados en su script. Active Storage no limitaba a qué coders podía llegar una subida, por lo que la política de ImageMagick del servidor era la única protección.

Dos detalles lo hacen grave. Primero, el analizador se ejecuta al adjuntar, así que no hace falta ninguna variant, preview ni llamada explícita a analyze: basta con aceptar la subida. Segundo, las aplicaciones que almacenan archivos con el servicio Disk también pueden verse forzadas a leer cualquier archivo que el proceso de la aplicación pueda leer. Eso incluye secret_key_base y las credenciales de otros sistemas, lo que puede derivar en ejecución remota de código o movimiento lateral.

El fallo lo reportó RyotaK, de GMO Flatt Security, a través de HackerOne. El equipo de Rails señala que se reportó una cadena de ataque y que no da por hecho que sea la única. El aviso no indica si el fallo se ha explotado.

La prueba de exposición de tres condiciones

Solo está afectado si se cumplen las tres condiciones. Compruébelas en orden; si cualquiera de ellas es falsa, esta cadena de ataque no se aplica, aunque actualizar sigue siendo lo correcto.

Condición	Dónde mirar	Expuesto cuando
1. Procesador de variants	config.active_storage.variant_processor y load_defaults	Es :mini_magick (el valor predeterminado con load_defaults 6.1 o anterior)
2. Política de ImageMagick	El policy.xml del servidor	No bloquea MSL, los coders de Ghostscript ni el delegate gs (las políticas predeterminadas de Debian y Ubuntu no lo hacen)
3. Quién puede subir archivos	Sus formularios de subida y APIs	Usuarios no confiables pueden adjuntar archivos

1. ¿Qué procesador usa Active Storage?

Busque en su configuración y consulte a la aplicación en ejecución:

grep -rn "variant_processor\|load_defaults" config/
bin/rails runner 'p Rails.application.config.active_storage.variant_processor'

Desde Rails 7.0 el valor predeterminado es :vips, pero las aplicaciones actualizadas desde versiones antiguas a menudo siguen cargando valores predeterminados antiguos o definen :mini_magick de forma explícita. Revise también bundle info mini_magick: si la gema está en su bundle, averigüe dónde se usa.

2. ¿Bloquea su política de ImageMagick los coders peligrosos?

Liste la política que ImageMagick carga realmente en cada servidor de aplicaciones y worker:

magick -list policy      # ImageMagick 7
convert -list policy     # ImageMagick 6

Busque reglas con rights="none" para el coder MSL, los coders de PostScript y PDF y el delegate gs. Si usa sin cambios la política empaquetada de Debian o Ubuntu, asuma que no están bloqueados. Recuerde que las imágenes de contenedor y los hosts de workers pueden ejecutar una compilación de ImageMagick distinta de la de sus servidores web.

3. ¿Pueden usuarios no confiables subir archivos?

Enumere todos los puntos donde un archivo llega a attach, has_one_attached o has_many_attached, incluidas las APIs, las direct uploads y las herramientas de administración que importan archivos externos. Un registro público con campo de avatar cuenta como no confiable.

La corrección: rutas de actualización por rama

Las versiones corregidas son Rails 8.1.4.1 y Rails 8.0.5.2. En conjunto corrigen 21 problemas de seguridad, así que merece la pena instalarlas aunque no esté expuesto a este.

Su rama	Qué hacer
8.1	Actualizar a 8.1.4.1
8.0	Actualizar ya a 8.0.5.2 y después planificar el paso a 8.1: el soporte de seguridad de 8.0 termina el 7 de noviembre de 2026
7.2 y anteriores	No se publicará ninguna corrección. Aplique la mitigación mediante política que se describe abajo y actualice a 8.0 o posterior

Las aplicaciones que usan :mini_magick también necesitan mini_magick 5.1 o posterior. Con una versión anterior, la versión corregida lanza un error al arrancar, así que actualice ambas gemas a la vez y pruebe el arranque en staging:

bundle update rails mini_magick
bundle info activestorage
bundle info mini_magick

Las versiones corregidas incluyen su propia política de ImageMagick, pero compruebe que realmente llega a ImageMagick. No se aplica si su aplicación reemplaza MiniMagick.cli_env después del arranque, usa MiniMagick.cli_prefix o instala su propio MiniMagick::Shell; esas aplicaciones necesitan las reglas en la política del sistema. GraphicsMagick no lee en absoluto las políticas de ImageMagick. Además, la política incluida se suma al policy.xml de su servidor en lugar de sustituirlo, por lo que una regla de permiso en ese archivo, incluido un comodín, anula el bloqueo.

Las mismas versiones corrigen un segundo fallo, GHSA-v924-7rp8-4mxh (CVSS 8.8). Active Storage pasaba las subidas a ImageMagick y FFmpeg con nombres temporales que conservaban la extensión original del archivo, de modo que un atacante que controlara el nombre del archivo y el tipo de contenido declarado podía influir en qué decodificador se ejecutaba. Las mitigaciones de Rails para este fallo solo cubren FFmpeg, otra razón más para actualizar en lugar de confiar en mitigaciones.

Un patrón, no un caso aislado

En julio de 2026, CVE-2026-66066 fue un fallo crítico distinto de Active Storage que afectaba a las aplicaciones que usan libvips. Las aplicaciones con ImageMagick no estaban expuestas a esa ruta, pero sí a esta. Dos fallos críticos en cuatro meses, a través de las dos bibliotecas de imágenes compatibles, apuntan a la misma lección: el procesamiento de imágenes es una gran superficie de ataque, y Active Storage lo ejecuta sobre archivos de desconocidos en el momento en que se adjuntan.

Cambiar de procesador no es una corrección por sí solo. Lo que le protege es tratar la biblioteca de imágenes como parte de su superficie de ataque: mantenerla parcheada igual que el framework, restringirla con una política y saber qué hosts la ejecutan. La política de ImageMagick, en particular, es un ajuste del servidor fácil de olvidar, porque reside en la imagen del sistema operativo y no en el código de su aplicación.

Si no puede actualizar de inmediato

Rails también publicó commits con los parches para 8.1 y 8.0. Hasta que pueda desplegar una versión corregida, siga esta lista de comprobación:

1. Añada las reglas mínimas del aviso a la política de sistema de ImageMagick en cada host que procese subidas (por ejemplo, /etc/ImageMagick-7/policy.xml).
2. Asegúrese de que ninguna regla de permiso ni comodín del mismo archivo las anule y confírmelo con magick -list policy.
3. Si renderiza PDF o PostScript mediante ImageMagick, vuelva a permitir el delegate gs y solo los coders que necesite, asumiendo que esto mantiene cierto riesgo.
4. Controle las subidas: restrinja temporalmente quién puede adjuntar archivos o suspenda las subidas anónimas.
5. Si usa el servicio Disk, planifique la rotación de secret_key_base, la master key y el contenido de config/credentials.yml.enc, las credenciales de almacenamiento y de base de datos, y los tokens de terceros. No conserve un secreto expuesto como alternativa de respaldo.

Las reglas mínimas publicadas en el aviso son:

<policy domain="coder" rights="none" pattern="MSL"/>
<policy domain="delegate" rights="none" pattern="gs"/>
<policy domain="coder" rights="none" pattern="{PS,PS2,PS3,EPS,EPS2,EPS3,EPI,EPSF,EPSI,EPT,EPT2,EPT3,PDF,AI,EPDF,PDFA,POCKETMOD,XPS,PCL}"/>

Consulte todos los detalles en el aviso de seguridad de Rails.

Cómo puede ayudar LOGIQ

LOGIQ ayuda a equipos que ejecutan stacks de código abierto sobre Linux, desde la imagen del sistema operativo hasta el runtime de la aplicación. Si necesita ayuda para revisar las políticas de ImageMagick en sus servidores o para planificar la salida de una rama que se queda sin soporte, hable con nuestro equipo.