Alerta crítica en Rails Active Storage expone secretos y permite leer archivos arbitrarios

Una vulnerabilidad crítica en Active Storage de Ruby on Rails, registrada como CVE-2026-66066 (CVSS 9.5), permite a un atacante no autenticado leer archivos arbitrarios desde el servidor de aplicaciones a través de cargas de imágenes manipuladas. La raíz del fallo no es Rails en sí, sino la interacción entre Active Storage y la biblioteca de procesamiento de imágenes libvips: Active Storage pasaba contenidos no confiables a operaciones de libvips marcadas como "untrusted" o "unfuzzed", que pueden invocar cargadores y salvadores inseguros capaces de devolver cualquier fichero accesible por el proceso de Rails.

El escenario práctico que convierte ese acceso en una intrusión grave es la exposición de secretos en el entorno del proceso Rails: secret_key_base, la master key de Rails, credenciales desencriptadas, contraseñas de bases de datos, claves de servicios de almacenamiento y tokens de APIs. Con esas credenciales un atacante podría realizar ejecución remota de código (RCE) sobre servicios conectados, moverse lateralmente dentro de la infraestructura o vaciar datos sensibles en servicios en la nube. La explotación exige además que la aplicación use libvips para procesado de imágenes y acepte cargas desde usuarios no confiables; aplicaciones que usan MiniMagick no están afectadas por esta ruta concreta.

Las ramas y versiones afectadas identificadas por los equipos de investigación son Rails 7.0.0 hasta 7.2.3.1, Rails 8.0.0 hasta 8.0.5 y Rails 8.1.0 hasta 8.1.3, y Rails 6.0.0 hasta 6.1.x solamente cuando Active Storage está configurado para usar Vips (en Rails 6 Vips no era el procesador por defecto). Rails ha publicado parches y las versiones recomendadas para actualizar son 7.2.3.2, 8.0.5.1 y 8.1.3.1. Además, las instalaciones parcheadas requieren libvips 8.13 o superior y, si usan ruby-vips, la versión 2.2.1 o posterior. Puede consultar las notas de lanzamientos y la actividad del proyecto en el repositorio oficial de Rails y en los recursos de ruby-vips y libvips para confirmar versiones y parches: https://github.com/rails/rails/releases y https://github.com/libvips/ruby-vips.

Para operadores que no pueden aplicar el parche de Rails de inmediato existe una mitigación temporal: habilitar el bloqueo de operaciones no confiables de libvips. Si su entorno tiene libvips 8.13 o superior puede exportar la variable de entorno VIPS_BLOCK_UNTRUSTED=true, o invocar programáticamente Vips.block_untrusted(true) desde ruby-vips 2.2.1 o posterior. Si su instalación usa una versión anterior de libvips sin esa capacidad, la única alternativa segura es actualizar libvips o dejar de usar Vips para Active Storage hasta que pueda parchear Rails y la biblioteca subyacente.

Es fundamental entender que aplicar el parche no invalida credenciales que ya hayan sido expuestas. Rails advierte explícitamente que, tras parchear, debe procederse a la rotación de todos los secretos que el proceso de Rails puede leer. Como mínimo, esto incluye secret_key_base, la master key y las credenciales desencriptadas, contraseñas de bases de datos, claves del servicio de Active Storage (S3/GS/etc.) y tokens de terceros. La rotación debe acompañarse de auditoría y verificación: busque accesos inusuales, solicitudes a endpoints que aceptan imágenes, transferencias de datos inesperadas y creación de cuentas o claves nuevas en sistemas vinculados.

En paralelo a la rotación, los equipos de respuesta deberían capturar y analizar logs relacionados con cargas y procesamiento de imágenes, revisar snapshots y copias de seguridad por actividad sospechosa, y comprobar integridad de imágenes y vectores de ejecución. Si existen sospechas de exfiltración o compromiso previo, trate la incidencia como una intrusión completa: aísle servicios comprometidos, reemplace credenciales en todos los sistemas dependientes, y considere auditorías forenses. Dado que aún no se ha publicado un PoC público ni se han confirmado explotaciones en la naturaleza al momento del aviso, los indicadores de compromiso pueden ser escasos; sin embargo, la posibilidad de lectura de archivos remotos convierte cualquier signo de acceso anómalo en algo a investigar con prioridad.

Desde una perspectiva de arquitectura y defensa en profundidad conviene adoptar medidas que reduzcan el impacto de fallos similares en el futuro: minimice la superficie de lectura del proceso de Rails (ejecutándolo con el menor conjunto de permisos necesarios), segmente las credenciales por servicio con roles y políticas de acceso limitadas, limite los tipos y tamaños de archivos que acepta Active Storage y aplique validación de contenido en el lado servidor antes de pasar archivos a procesadores nativos. También es recomendable instrumentar alertas para operaciones extrañas de Active Storage y mantener un inventario de dependencias nativas como libvips fuera del ciclo de paquetes Ruby para poder parchearlas por separado.

Los descubridores del fallo fueron acreditados por Rails como investigadores de Ethiack y GMO Flatt Security. Rails ha indicado que ofrecerá detalles técnicos adicionales no más tarde del 28 de agosto de 2026, fecha en la que es probable que lleguen más técnicas de detección y descripciones más finas del vector de ataque. Hasta entonces, la recomendación prioritaria es parchear rápido, actualizar libvips y ruby-vips donde corresponda, y rotar todas las claves y secretos legibles por el proceso de Rails.

Finalmente, recuerde que el puntaje CVSS 9.5 refleja severidad técnica, no exposición masiva: para ser explotable la aplicación debe usar Vips para procesar imágenes, aceptar cargas de usuarios no confiables y tener una build de libvips que incluya las operaciones inseguras. Aun así, si su servicio cumple esos requisitos, trate esta vulnerabilidad como una emergencia operativa y proceda con las actualizaciones y rotaciones recomendadas con la máxima urgencia.