Vulnerabilidad crítica en Rails permite escribir archivos mediante subidas de ImageMagick

Una grave vulnerabilidad de seguridad en Ruby on Rails permite a atacantes no autenticados escribir archivos arbitrarios en un servidor mediante la subida de imágenes especialmente diseñadas. El proyecto Rails publicó correcciones en las versiones 8.1.4.1 y 8.0.5.2 el 4 de noviembre de 2026, abordando un fallo en el componente Active Storage cuando se utiliza con ImageMagick.

Qué ocurrió

La vulnerabilidad reside en cómo Active Storage gestiona las subidas de archivos cuando está configurado para usar ImageMagick para el procesamiento de imágenes. Cuando una aplicación acepta una subida de archivo, Active Storage ejecuta un analizador para determinar el tipo de archivo. Este proceso hace que ImageMagick inspeccione el contenido, seleccionando un manejador de formato, conocido como coder, basado en lo que encuentra dentro del archivo. Algunos de estos coders están diseñados para actuar sobre archivos externos referenciados dentro de los datos de la imagen, en lugar de solo sobre la imagen misma.

En este caso específico, un atacante puede subir un archivo SVG que invoca el coder MSL, un formato de script capaz de leer y escribir archivos especificados en su script. Dado que Active Storage no restringía qué coders podían usarse durante el análisis, la política predeterminada de ImageMagick del servidor se convirtió en la única línea de defensa. En muchos sistemas, incluidos aquellos que ejecutan Debian o Ubuntu, la política predeterminada no bloquea estos coders peligrosos. Como consecuencia, simplemente adjuntar un archivo malicioso es suficiente para explotar el fallo, sin necesidad de generar vistas previas ni transformar la imagen.

Si la aplicación almacena archivos utilizando el servicio Disk, el atacante también puede leer cualquier archivo al que la aplicación tenga permiso de acceso. Esto suele incluir credenciales sensibles como secret_key_base, contraseñas de bases de datos y tokens de API de terceros. El acceso a estos secretos puede conducir a la ejecución remota de código o al movimiento lateral hacia otros sistemas conectados. El equipo de Rails calificó esta vulnerabilidad con 9.8 sobre 10 en la escala CVSS, lo que indica una severidad casi máxima.

Detalles clave

• La vulnerabilidad está registrada como GHSA-f3w6-w445-fwh9 y afecta a las versiones de Rails anteriores a la 8.0.5.2 y la 8.1.4.1.
• Requiere que la aplicación utilice config.active_storage.variant_processor = :mini_magick, que es el valor predeterminado en configuraciones antiguas de Rails.
• El vector de ataque implica la subida de un archivo manipulado, como un SVG, que activa el coder MSL de ImageMagick durante la fase de análisis del adjunto.
• Las aplicaciones que usan el servicio Disk para el almacenamiento tienen un mayor riesgo porque los atacantes pueden leer archivos de configuración sensibles y secretos desde el servidor.
• La corrección introduce una estricta política de seguridad de ImageMagick que bloquea coders peligrosos como MSL, Ghostscript y aquellos que permiten la indirección de archivos.
• También se corrigió una segunda falla de alta severidad, GHSA-v924-7rp8-4mxh, relacionada con cómo las extensiones de archivo influyen en la selección del decodificador en FFmpeg e ImageMagick.

Contexto

Active Storage es el framework estándar en Rails para gestionar adjuntos de archivos. Delega las tareas de procesamiento de imágenes en bibliotecas externas, comúnmente ImageMagick o libvips. ImageMagick es una herramienta potente que soporta cientos de formatos de imagen, cada uno gestionado por un coder específico. Si bien esta flexibilidad es útil para los desarrolladores, introduce riesgos de seguridad si ciertos coders tienen permitido ejecutar scripts o acceder al sistema de archivos más allá del archivo de imagen inmediato.

Las políticas de seguridad en ImageMagick se definen en archivos XML que especifican qué operaciones y coders están permitidos. Históricamente, muchas distribuciones Linux incluían políticas permisivas para garantizar la compatibilidad con diversos flujos de trabajo. Esta vulnerabilidad destaca el peligro de confiar en los valores predeterminados del sistema para la seguridad de la aplicación, especialmente al procesar entradas de usuario no confiables. La reciente corrección traslada la responsabilidad al framework de la aplicación al incluir una política restrictiva directamente con Rails.

Por qué importa

Para los equipos que ejecutan aplicaciones Rails autoalojadas, esta vulnerabilidad representa una amenaza directa para la integridad de la infraestructura. A diferencia de algunos bugs que requieren condiciones complejas para ser explotados, este se activa mediante el acto básico de subir un archivo. Si su aplicación acepta subidas de usuarios públicos o incluso de personal interno, está potencialmente expuesta. La capacidad de un atacante para escribir archivos significa que podría plantar puertas traseras, modificar el código de la aplicación o exfiltrar datos leyendo archivos de configuración.

El impacto se complica para las aplicaciones que utilizan el servicio Disk, ya que la exposición de secretos como secret_key_base compromete todo el modelo de seguridad de la aplicación. Una vez que un atacante tiene estas claves, puede falsificar cookies de sesión, descifrar credenciales almacenadas y suplantar a los usuarios. Esto hace que la remediación inmediata sea crítica, dado que la ventana de explotación es amplia y el daño potencial es extenso. Además, las versiones antiguas de Rails ya no reciben parches de seguridad, lo que obliga a los equipos en sistemas heredados a buscar estrategias de mitigación alternativas.

Qué puede hacer

• Actualice inmediatamente a Rails 8.1.4.1 o 8.0.5.2, y asegúrese de tener instalada la versión 5.1 o posterior de la gema mini_magick.
• Verifique que la nueva política de ImageMagick esté activa ejecutando bin/rails runner 'puts MiniMagick.identify { |i| i.list "policy" }'.
• Si no puede actualizar, copie manualmente la política restrictiva desde activestorage/lib/active_storage/image_magick/policy.xml al archivo de política de ImageMagick de su sistema.
• Rotee todos los secretos inmediatamente si su app usa el servicio Disk, incluyendo secret_key_base, credenciales de base de datos y tokens de API, ya que podrían haber sido expuestos.
• Revise las configuraciones personalizadas de ImageMagick que podrían anular las nuevas restricciones, como comodines en policy.xml que rehabiliten coders bloqueados.
• Considere migrar a libvips si es posible, ya que no se ve afectado por esta cadena específica de vulnerabilidades relacionada con ImageMagick.