Esta semana, el equipo de mantenimiento de Ruby on Rails anunció parches de Rails para corregir una vulnerabilidad crítica. El problema, identificado como CVE-2026-66066 y con una puntuación CVSS de 9.5, puede ser aprovechado por atacantes no autenticados para llegar a ejecución remota de código (RCE).
El detalle importante es que el fallo no se limita a “romper” la aplicación: está relacionado con la forma en que Rails procesa variantes de imágenes con Active Storage y una librería externa, libvips. En escenarios concretos, un atacante podría leer archivos arbitrarios del servidor, extraer secretos y usar esa información para escalar el impacto.
Qué hace peligrosa la vulnerabilidad CVE-2026-66066
Según el aviso del proyecto, en la configuración por defecto, una aplicación Rails que muestra variantes de imágenes podría permitir a un atacante no autenticado leer archivos arbitrarios dentro del sistema. La consecuencia es grave porque esa lectura incluye datos sensibles, como el entorno del proceso.
Dentro de lo que puede quedar expuesto, el aviso menciona que los atacantes podrían encontrar el valor de secret_key_base y credenciales destinadas a sistemas externos. Con esa información, el atacante podría escalar el ataque hasta RCE y/o moverse lateralmente hacia otros sistemas.
La cadena de riesgo combina dos elementos: un vector para provocar la divulgación de información y, después, la posibilidad de convertir esa información en control más profundo del sistema.
Cómo encaja Active Storage con libvips
El alcance del problema depende de cómo esté montado el procesamiento de imágenes. El impacto se concentra en aplicaciones que:
- Usan libvips para el procesamiento de imágenes en Active Storage.
- Permiten subidas de imágenes por parte de usuarios no confiables.
El punto técnico descrito en el aviso tiene que ver con el tratamiento de ciertas operaciones de lectura/escritura en el contexto de libvips. La librería marca algunas operaciones como “unfuzzed”, es decir, inseguras para contenido que no es de confianza. Sin embargo, Active Storage no desactivaba esas operaciones.
En la práctica, esto abre la puerta a que un atacante suba un archivo especialmente preparado para activar alguna de esas operaciones inseguras.
El mecanismo de ataque: subida de archivo manipulada
El aviso reconoce explícitamente la existencia de un mecanismo por el cual un atacante, mediante la subida de un archivo manipulado, puede provocar la divulgación del contenido de archivos arbitrarios que estén accesibles en el sistema de la aplicación objetivo.
Esto es coherente con el tipo de impacto observado: la lectura arbitraria permite recuperar secretos que luego pueden convertirse en el “combustible” del siguiente paso de la intrusión. Por eso, el problema no solo es de confidencialidad (exfiltración), sino también de potencial control (RCE), dependiendo de los detalles del despliegue y de la información expuesta.
Versiones afectadas y versiones corregidas
La corrección para CVE-2026-66066 fue incorporada en versiones específicas de Active Storage. Las versiones que incluyen el parche son:
- Active Storage 7.2.3.2
- Active Storage 8.0.5.1
- Active Storage 8.1.3.1
Si tu aplicación usa Active Storage para variantes e imágenes, estas son las actualizaciones clave para cerrar la vulnerabilidad en el componente de Rails relacionado con el procesamiento.
Pero además del parche de Active Storage, el aviso insiste en un segundo paso: actualizar la librería libvips.
Actualización de libvips: requisito para desactivar el riesgo
Los mantenedores recomiendan actualizar libvips a una versión mínima de 8.13. La razón es que las versiones anteriores de la librería no soportan deshabilitar las operaciones “unfuzzed”, que son precisamente las que no debían estar habilitadas para contenido no confiable.
En otras palabras: aunque actualices Active Storage a una versión parcheada, todavía es necesario contar con una librería libvips que permita mitigar el problema de fondo al nivel de procesamiento.
Mitigación y acciones recomendadas
La recomendación principal es clara: actualiza cuanto antes tanto Active Storage (según tu rama) como libvips al menos a la versión indicada. Cuanto más tiempo permanezca el despliegue sin cambios, mayor es la ventana para que el fallo pueda ser aprovechado, especialmente si aceptas cargas desde usuarios no confiables.
Además, el aviso deja un matiz operativo importante:
- Actualizar cierra la vulnerabilidad, pero no borra lo que pudo haberse extraído antes.
- Si el sistema ya estuvo expuesto, debes tratar cada secreto legible por el proceso de la aplicación como potencialmente comprometido.
Esto implica que, tras el parche, el equipo responsable debe revisar rotación de credenciales y secretos que residan en el entorno del proceso o en ubicaciones accesibles para la aplicación.
¿Hay evidencia de explotación activa?
De acuerdo con Rapid7, a fecha de 30 de julio no había indicios de que la vulnerabilidad se estuviera explotando en el mundo real. Aun así, la ausencia de evidencia no equivale a ausencia de riesgo: las correcciones están disponibles y conviene actuar en consecuencia.
También es importante recordar que muchos incidentes comienzan con una fase de recolección de información. Si un atacante puede leer secretos, el impacto puede aparecer incluso después de que el parche se haya aplicado (por exfiltraciones previas).
Consejos rápidos para equipos de desarrollo y operación
Para minimizar el impacto de parches de Rails y este tipo de fallos en entornos reales, puedes centrarte en:
- Revisar dependencias: confirma la versión exacta de Active Storage y de libvips desplegadas en producción.
- Validar el flujo de subidas: identifica dónde se permiten cargas de imágenes de usuarios no confiables.
- Planear rotación de secretos: si existe cualquier sospecha de exposición, rota secretos que la aplicación pueda leer.
- Actualizar y desplegar: no basta con “tener la versión parcheada”; el cambio debe llegar al runtime.
Conclusión
Los parches de Rails para CVE-2026-66066 corrigen una vulnerabilidad crítica que puede permitir lectura arbitraria de archivos y, con los secretos obtenidos, escalar hasta ejecución remota de código (RCE). El caso depende de Active Storage y del papel de libvips en el procesamiento de imágenes.
Por eso, la respuesta recomendada es doble: actualizar Active Storage a las versiones corregidas y llevar libvips al menos a 8.13. Además, si hubo cualquier exposición previa, trata los secretos del proceso como comprometidos y aplica rotación.
Fuente: https://www.securityweek.com/ruby-on-rails-patches-critical-vulnerability/
