libvips lee y escribe formatos a través de operaciones, algunas de las cuales marca como unfuzzed — inseguras para contenido no confiable. Active Storage no las deshabilitaba, por lo que un atacante que pueda subir un archivo especialmente diseñado puede alcanzarlas.

Una aplicación está expuesta solo cuando se cumplen las cuatro condiciones siguientes:

1. activestorage está en un rango de versiones afectadas
2. Active Storage está en uso
3. config.active_storage.variant_processor se resuelve a :vips
4. La aplicación acepta subidas de archivos de usuarios no confiables

La condición 3 es la determinante. El rango afectado < 7.2.3.2 incluye todas las versiones de Rails 6.x, pero 6.x usa :mini_magick por defecto, por lo que 6.x solo está expuesto con una configuración no predeterminada, y las versiones anteriores a 6.0 no tienen ningún ajuste variant_processor en absoluto. Rails 7.0 y posteriores usan :vips por defecto mediante config.load_defaults 7.0, que es la razón por la que la configuración habitual está expuesta. Rails 8.1 también acepta :disabled, lo que hace que la condición 3 sea falsa.

Instalación

Como plugin de Claude Code, a través del marketplace incluido en este repositorio:

Con la CLI de skills, que instala la misma skill en Claude Code, Codex, Cursor, Copilot CLI y otros agentes:

O manualmente:

~/.agents/skills/ funciona como ubicación transversal entre runtimes para Codex, Copilot CLI y Gemini CLI. Nada en la skill depende de dónde esté instalada — no hay rutas absolutas, y collect-evidence.sh resuelve todo en relación con la raíz de la aplicación a la que se apunta.

Uso

La skill tiene dos modos, y ambos aceptan múltiples rutas de aplicación.

Instalada como plugin, cada modo es también un comando, por lo que el modo no tiene que escribirse como argumento:

Los comandos son puntos de entrada para ti, no para el agente: están marcados para que Claude nunca los ejecute por su cuenta. Claude sigue invocando la skill por sí mismo cuando una solicitud coincide con ella, por eso fix no puede comenzar sin que un humano lo pida.

report es el modo por defecto. fix requiere primero un veredicto de report para la misma aplicación, porque la remediación correcta depende de él: Rails 6.x, 7.0.x y 7.1.x no tienen un parche de la misma serie, así que allí fix aplica la mitigación provisional e informa de que se requiere una actualización del framework en lugar de intentar una.

La recopilación de evidencia también puede ejecutarse por separado:

El script recopila hechos y, deliberadamente, no contiene lógica de veredicto. Pasa la raíz de una aplicación, no una raíz de monorepo indiferenciada. Para un monorepo, pasa cada directorio Rails desplegable con su propio Gemfile.lock y config/application.rb como argumento separado. El recopilador excluye esas raíces de aplicación anidadas del flujo de evidencia del padre, mientras conserva las raíces de lockfile anidadas que pueden ser engines montados o dependencias de ruta.

Lo que no te dirá

• La versión de libvips en tiempo de ejecución. No se puede conocer de manera concluyente desde un repositorio, y es importante: por debajo de libvips 8.13, las operaciones inseguras no se pueden deshabilitar en absoluto. En una aplicación sin parchear, eso significa que ninguna mitigación puede funcionar; en una parcheada, significa que Active Storage lanza una excepción durante el arranque en lugar de ejecutarse sin protección, por lo que una actualización sin verificar hace fallar el despliegue en lugar de dejar un agujero silencioso. Verifícalo con vips --version donde se ejecuta la aplicación. Los informes mantienen este punto bajo preparación del runtime y remediación, en lugar de hacer que el veredicto de exposición dependa de ello.
• Si una mitigación está activa. VIPS_BLOCK_UNTRUSTED en un Dockerfile no demuestra que el entorno desplegado la establezca. La skill limita esos hallazgos a «interim mitigation present, upgrade still required» y nunca permite que uno de ellos produzca un veredicto limpio.

Resumen de remediación

Actualiza a 7.2.3.2, 8.0.5.1 o 8.1.3.1, según tu serie. Confirma primero libvips >= 8.13 y ruby-vips >= 2.2.1 en tiempo de ejecución: donde ruby-vips esté instalado, el Active Storage parcheado lanza una excepción durante el arranque a menos que ambas condiciones se cumplan, y esa comprobación se aplica también a las aplicaciones :mini_magick.

Mitigaciones provisionales, ninguna de las cuales sustituye a la actualización:

• Establece la variable de entorno VIPS_BLOCK_UNTRUSTED (libvips >= 8.13; no es necesario cambiar ninguna gema)
• Llama a Vips.block_untrusted(true) desde un inicializador (ruby-vips >= 2.2.1, más libvips >= 8.13)

Con ruby-vips < 2.2.1, la vía del inicializador llama a un método que aún no existe, así que sube primero la versión de la gema u opta por la vía de la variable de entorno, que no depende de ella.

Si una aplicación estuvo expuesta, trata todos los secretos legibles por el proceso de la aplicación como comprometidos y rótalos: secret_key_base, la clave maestra, las credenciales del servicio de Active Storage, las credenciales de la base de datos y los tokens de terceros.

Un WAF no es una mitigación aquí. Que pueda ver el payload depende del servicio de almacenamiento y del método de subida, por lo que su efectividad depende demasiado de la configuración como para poder confiar en ella.

Descargo de responsabilidad

• Usa esta skill únicamente en repositorios de tu propiedad o para los que tengas autorización explícita de auditar.
• Los veredictos son análisis estático de mejor esfuerzo. Un veredicto NOT AFFECTED no es prueba de no exposición: las variables de entorno del despliegue y el código en otros servicios son invisibles para una auditoría de repositorio. El libvips en tiempo de ejecución se informa por separado porque afecta a la mitigación y a la preparación del despliegue, no a si el repositorio cumple las condiciones de exposición.
• La skill no contiene código de explotación y no reconstruirá la cadena de ataque, sin importar cómo se formule la solicitud.
• Proporcionada bajo la Licencia MIT, sin garantía de ningún tipo. Actuar sobre la base de un informe —actualizaciones, mitigaciones, rotación de secretos— sigue siendo responsabilidad del operador.

Fuentes

• Rails security advisory GHSA-xr9x-r78c-5hrm
• Ethiack — KindaRails2Shell: Rails RCE (CVE-2026-66066)
• Rails guides — Configuring Rails Applications

La vulnerabilidad fue encontrada y reportada de forma independiente por RyotaK de GMO Flatt Security y por un equipo de Ethiack formado por André Baptista, Bruno Mendes y Castilho, y se divulgó en coordinación con los mantenedores de Rails.