Fallo crítico en Rails Active Storage: una imagen subida puede escribir archivos en tu servidor

Qué pasa: una imagen subida puede escribir archivos en el servidor

El 4 de noviembre el equipo de Rails publicó las versiones 8.1.4.1 y 8.0.5.2, con 21 correcciones de seguridad: 1 crítica, 4 altas, 13 medias y 3 bajas. La crítica, GHSA-f3w6-w445-fwh9, permite que alguien que sube un archivo escriba archivos en el servidor y, si la aplicación los guarda en disco, también los lea.

Al adjuntar una imagen, Active Storage la analiza con ImageMagick sin limitar qué «coders» puede usar. Es el contenido del archivo el que elige el coder, y algunos (MSL, la familia Ghostscript, la indirección @archivo) leen o escriben otros archivos. El análisis se lanza al adjuntar: no hace falta pedir una miniatura ni una variante.

Tu aplicación está expuesta si se cumplen las tres condiciones siguientes:

• Acepta subidas de usuarios que no controlas: avatares, documentos, adjuntos de formularios.
• config.active_storage.variant_processor es :mini_magick, el valor por defecto con load_defaults 6.1 o anterior.
• La política de ImageMagick del servidor no bloquea ya MSL y Ghostscript. Las que traen Debian y Ubuntu no lo hacen.

Lectura de archivos y el aviso de vídeo

Si además usas el servicio Disk (:local), el atacante puede leer lo que lea la aplicación: secret_key_base, la master key, credenciales de otros sistemas. Con S3, GCS o Azure el fallo crítico se queda en escritura.

En el mismo paquete va GHSA-v924-7rp8-4mxh, de severidad alta: la extensión del nombre del archivo elegía el decodificador de FFmpeg o ImageMagick en vídeos y audios, con lectura de archivos y, en builds de FFmpeg con AviSynth, ejecución de código. Este afecta también a las aplicaciones que usan libvips si tienen activos los analizadores de vídeo y audio, que lo están por defecto.

Qué hacer en Rails

1. Ejecuta bundle update rails y comprueba la versión con bundle exec rails runner 'puts Rails.version'.
2. Si usas :mini_magick, sube mini_magick a 5.1 o superior: con una versión anterior la aplicación parcheada no arranca.
3. En Rails 7.2 o anterior no hay parche. Copia las reglas del policy.xml de la versión corregida a la política de ImageMagick del sistema (por ejemplo /etc/ImageMagick-7/policy.xml): como mínimo, deniega MSL, los coders de Ghostscript y el delegado gs, y verifícalo con magick -list policy. Para el aviso de vídeo, quita VideoPreviewer, VideoAnalyzer y AudioAnalyzer de la configuración de Active Storage.
4. En Rails 8.0, parchea hoy y planifica el salto a 8.1: la serie 8.0 deja de recibir parches de seguridad el 7 de noviembre.
5. Si estabas en el caso de lectura (Disk con ImageMagick), rota secretos: secret_key_base, master key, credenciales de almacenamiento y de base de datos, y tokens de terceros. Rotar secret_key_base cierra las sesiones de los usuarios; es el precio de no dejar la puerta abierta.

Lo que vimos en 395 repositorios públicos de Rails

El 4 de noviembre, horas después del aviso, releímos el Gemfile.lock y la configuración de 395 repositorios públicos y activos de Rails. Son proyectos públicos y su rama principal no tiene por qué ser lo que corre en producción, así que las cifras dan un orden de magnitud, no una auditoría.

• Solo 7 de 395 (1,8 %) tenían ya la versión corregida.
• 185 de 395 (46,8 %) están en Rails 7.2 o anterior, que no recibirá el parche.
• 19 de 395 (4,8 %) usan ImageMagick para Active Storage, la primera condición del fallo crítico; 13 de ellos están en Rails 7.2 o anterior y 11 tienen mini_magick anterior a 5.1.

Relacionado

• CVE-2026-98432: el fallo del kernel de Linux en IPv4 TCP
• Auditoría de seguridad de aplicaciones para empresas en España
• Servicio de seguridad técnica