El fallo de seguridad crítico que afecta a casi cualquier app Rails con subida de imágenes

Si tienes una aplicación Rails 7.x o 8.x y utilizas Active Storage junto con vips como procesador de variantes, tendrás que actualizar cuanto antes para parchear una vulnerabilidad crítica. Se trata de la CVE-2026-66066 y permite, en el peor caso, lectura arbitraria de ficheros del servidor y ejecución remota de código a partir de cualquier imagen subida por un usuario malicioso.

No es un fallo raro que necesite configuración rara: es la configuración por defecto de Active Storage en estas versiones de Rails que queda expuesta.

De un vistazo

¿Qué está pasando técnicamente?

Active Storage usa una biblioteca llamada libvips a través de la gema ruby-vips para procesar imágenes. Esto incluye crear versiones más pequeñas de las imágenes, cambiar su tamaño o recortarlas. Libvips soporta muchos formatos de imagen y también tiene algunas operaciones que no son tan seguras.

El problema es que Active Storage no deshabilitaba estas operaciones inseguras cuando un usuario subía una imagen. Un atacante podría crear una imagen especial que, en lugar de cambiar su tamaño de manera normal, haría que el sistema ejecutara una de estas operaciones peligrosas. Esto podría permitir que el atacante accediera a los archivos del sistema o, en el peor de los casos, ejecutara código en el servidor.

Para que tu aplicación sea vulnerable, deben ocurrir dos cosas al mismo tiempo:

• La configuración de Active Storage debe estar seteada para usar vips como procesador de variantes (config.active_storage.variant_processor = :vips). Esto es el valor por defecto en versiones recientes de Rails, así que si no has cambiado esto, probablemente estés usando vips.

• Tu aplicación debe permitir que los usuarios suban imágenes, como en formularios públicos, durante el registro o en perfiles de usuario.

No es necesario que tu código llame explícitamente a la función para crear variantes para estar en riesgo. Basta con que Active Storage pueda procesar la imagen en algún momento, ya sea analizando, previsualizando o transformándola.

Las versiones 6.x de Rails no están afectadas por defecto porque no usan vips como procesador por defecto. Sin embargo, si estás usando Rails 6.x y también estás usando vips, debes revisar esto. No se han publicado los detalles exactos de cómo explotar esta vulnerabilidad y no se publicarán hasta el 28 de agosto de 2026. Así que asume que hay un tiempo limitado antes de que aparezca una prueba de concepto pública.

¿Por qué esto no es “solo un bug de imágenes”?

Para las personas que no están acostumbradas a tratar con temas técnicos en su vida diaria, es importante entender que esta vulnerabilidad no solo afecta una función en particular, sino que pone en peligro todo el servidor. La capacidad de leer archivos de manera arbitraria significa que un atacante puede acceder a información confidencial como el secreto de la aplicación (config/master.key), credenciales de bases de datos, variables de entorno o cualquier otro secreto que se encuentre en el servidor.

Si la forma en que se explota esta vulnerabilidad permite la ejecución de código remoto (RCE), el problema deja de ser solo una fuga de datos y se convierte en un control total del servidor. Esto tiene implicaciones muy serias, especialmente en entornos donde se manejan datos personales de clientes, información de pagos o datos de terceros.

El impacto económico de esta situación no se limita a simplemente actualizar una librería. En realidad, obliga a realizar una rotación de secretos, lo que puede ser un proceso costoso tanto en tiempo como en dinero. Además, si ya ha habido una exposición, es posible que sea necesario notificar a los clientes, lo que puede dañar la reputación de la empresa. Si no se aborda el problema a tiempo, se tendrá que invertir tiempo y recursos en atender un incidente de seguridad que podría haberse evitado. Por lo tanto, es más económico y sensato tratar esta vulnerabilidad como una actualización urgente hoy, en lugar de esperar y tener que enfrentar las consecuencias como un incidente de seguridad la semana que viene.

Checklist de mitigación

1. Comprueba tu versión de Active Storage. Estás expuesto si usas activestorage < 7.2.3.2, >= 8.0 < 8.0.5.1, o >= 8.1 < 8.1.3.1.

2. Actualiza Rails a una versión parcheada: 7.2.3.2, 8.0.5.1 u 8.1.3.1. Si gestionas upgrades de Rails en producción y esto te parece un salto grande a ciegas, es el tipo de migración donde vale la pena tener a alguien que ya tenga experiencia en ello.

3. Actualiza también libvips, no solo la gema de Rails. Necesitas libvips >= 8.13: es la primera versión capaz de deshabilitar las operaciones “unfuzzed”. Si tu imagen de sistema (Docker base, AMI, paquete del SO) trae una libvips más antigua, el parche de Rails por sí solo no te protege.

4. Si no puedes actualizar ahora mismo, aplica el workaround: puedes poner una variable de entorno VIPS_BLOCK_UNTRUSTED=1 (requiere libvips >= 8.13) o, desde el código, Vips.block_untrusted(true) en un initializer (requiere ruby-vips >= 2.2.1). Es un parche temporal, no una solución.

5. Si solo usas ruby-vips para análisis y no necesitas variantes, valora eliminar la dependencia hasta que no esté parcheada.

6. Rota secretos si tu aplicación estuvo expuesta con una versión vulnerable en producción: secret_key_base, master key, credenciales de servicios y de base de datos, y tokens de terceros. Trátalo como si la exposición ya hubiera ocurrido, no como hipótesis.

7. Revisa quién puede subir ficheros sin autenticar en tu app: formularios de contacto, soporte, registro. Es tu frente de ataques para este CVE.

Conclusión

Cada vez que una gema importante como Active Storage utiliza una librería nativa como libvips, también puede heredar todos los problemas de seguridad de esa librería. Por lo tanto, cuando se realiza una auditoría de dependencias, es útil preguntarse no solo “¿qué versión de la librería estoy utilizando?” sino también “¿qué hace exactamente esta librería en el fondo que no estoy viendo?”.

Con la versión 6.x de Rails, no hay exposición por defecto, pero con las versiones 7.x y 8.x, la situación es diferente y hay exposición por defecto. Esto nos recuerda que no siempre es más seguro utilizar versiones antiguas de Rails. En este caso, la versión antigua resultó ser más segura solo por casualidad, debido a la configuración, y no por diseño.