Una vulnerabilidad con una puntuación CVSS de 9,5 ya está siendo explotada activamente. Investigadores advierten además de que el parche publicado por Rails no elimina por completo una de las rutas que pueden conducir a ejecución remota de código.
Los atacantes ya están aprovechando activamente una vulnerabilidad crítica de Ruby on Rails que puede permitir a un atacante remoto ejecutar código arbitrario en servidores afectados.
El fallo, identificado como CVE-2026-66066 y conocido como KindaRails2Shell, fue corregido oficialmente a finales de julio, pero investigadores de seguridad han descubierto que la protección introducida no cubre completamente todas las posibilidades de explotación.
La vulnerabilidad tiene una puntuación CVSS de 9,5, lo que la sitúa entre los fallos más graves para las aplicaciones Rails afectadas.
Miles de servidores permanecían expuestos
La firma de inteligencia de amenazas VulnCheck informó de que la explotación comenzó aproximadamente un mes después de que Rails publicara las actualizaciones de seguridad.
Antes de que comenzaran los ataques observados, los investigadores habían localizado alrededor de 7.000 instalaciones de Rails accesibles desde Internet que todavía utilizaban configuraciones vulnerables.
El problema fue corregido el 29 de julio, cuando el proyecto Rails publicó un aviso de seguridad recomendando actualizar inmediatamente las aplicaciones que utilizaran libvips con Active Storage para procesar imágenes y permitieran a usuarios no confiables subir archivos.
Precisamente esta combinación es la que convierte determinadas instalaciones en objetivos especialmente atractivos.
El problema comienza con una imagen que no es realmente una imagen
El origen de la vulnerabilidad está en una discrepancia entre la forma en que Rails y las bibliotecas utilizadas para procesar imágenes determinan qué tipo de archivo están manejando.
En determinadas configuraciones, Rails confía en el tipo de contenido declarado por el cliente para determinar que un archivo es una imagen.
Libvips, en cambio, utiliza los llamados magic bytes, es decir, los datos presentes en las primeras posiciones del archivo, para identificar su formato real.
Esa diferencia permite construir archivos especialmente manipulados que son aceptados por Rails como imágenes pero que posteriormente son interpretados de una manera completamente distinta por la cadena de procesamiento.
El atacante puede, por ejemplo, presentar un archivo malicioso como si fuera una imagen y etiquetarlo como MATLAB Level 5.
Cuando libvips intenta procesarlo, entra en funcionamiento el cargador correspondiente a MATLAB, que a su vez utiliza libmatio. Esta biblioteca puede reconocer determinados encabezados como pertenecientes al formato MAT 7.3 y transferir el procesamiento a HDF5.
Es en esta última etapa donde la cadena de ataque adquiere especial gravedad.
HDF5 puede terminar leyendo archivos del servidor
HDF5 incorpora una funcionalidad conocida como External File List, que permite que los datos de un conjunto de información se encuentren físicamente en otro archivo.
En condiciones normales se trata de una característica legítima del formato. Sin embargo, dentro de esta cadena de interpretación, un atacante puede utilizarla para conseguir que el sistema intente leer archivos arbitrarios del servidor.
El resultado es una vulnerabilidad de lectura arbitraria de archivos.
Si el proceso de Rails tiene acceso a determinados archivos sensibles, un atacante podría intentar obtener información como credenciales, claves de almacenamiento, secretos de sesión o datos de configuración.
Y aquí aparece uno de los mayores riesgos: la lectura de secretos puede convertirse en el punto de partida para ataques posteriores.
De leer archivos a ejecutar código
El acceso a información sensible puede permitir a los atacantes avanzar hacia otros objetivos.
Si consiguen obtener secretos utilizados por la aplicación, pueden intentar falsificar sesiones, acceder a otros componentes de la infraestructura o utilizar las credenciales obtenidas para desplazarse lateralmente.
Por tanto, el problema no debe entenderse únicamente como una vulnerabilidad de lectura de archivos. En determinadas circunstancias, puede convertirse en una cadena completa que termine en ejecución remota de código (RCE).
Además, investigadores de seguridad comenzaron a publicar análisis técnicos y pruebas de concepto poco después de la publicación del parche oficial.
Esto reduce considerablemente la barrera de entrada para atacantes que quieran intentar explotar sistemas que todavía no hayan sido actualizados.
El parche tampoco parece cerrar todas las puertas
La situación se complica todavía más por un segundo descubrimiento realizado por VulnCheck.
Durante las pruebas sobre un servidor Rails 8.1.3.1, considerado parcheado frente al problema original, los investigadores comprobaron que todavía existía una vía relacionada con la deserialización de objetos mediante Marshal.
El parche bloquea la ruta de lectura de archivos asociada a libvips, pero una variante basada en una variation key puede seguir alcanzando código potencialmente peligroso si el atacante dispone de una firma criptográfica válida.
Esto significa que instalar la actualización continúa siendo fundamental, pero no necesariamente garantiza por sí solo que todas las rutas relacionadas con la explotación hayan desaparecido.
La condición de disponer de una firma válida hace que este escenario sea diferente de la explotación inicial y añade requisitos adicionales al atacante, pero sigue representando un riesgo que los administradores deberían considerar.
¿Qué servidores están realmente en riesgo?
No todas las aplicaciones Ruby on Rails están expuestas de la misma manera.
El escenario de mayor riesgo combina principalmente estas dos condiciones:
- La aplicación utiliza Active Storage con libvips como procesador de imágenes.
- Permite que usuarios no autenticados o no confiables suban archivos.
Si una aplicación no acepta archivos enviados por usuarios externos, la superficie de ataque disminuye considerablemente.
También existe una diferencia importante cuando se utiliza otro procesador de imágenes en lugar de libvips.
Por este motivo, los administradores deberían comenzar identificando exactamente cómo se procesan las cargas de archivos dentro de sus aplicaciones antes de asumir que una instalación de Rails es segura simplemente porque utiliza una versión reciente.
Los administradores deberían buscar señales de explotación
Además de instalar las actualizaciones correspondientes, las organizaciones afectadas deberían revisar sus sistemas en busca de indicios de actividad maliciosa.
Rails publicó herramientas forenses destinadas precisamente a ayudar a detectar posibles intentos de explotación.
También resulta recomendable revisar los registros relacionados con las cargas de archivos y prestar especial atención a comportamientos anómalos, incluyendo archivos que intenten hacerse pasar por formatos de imagen o que utilicen tipos de archivo poco habituales.
Los archivos declarados como MATLAB merecen especial atención en este contexto, especialmente cuando aparecen en aplicaciones que normalmente no deberían recibir ese tipo de contenido.
El problema de fondo: una cadena de confianza demasiado compleja
CVE-2026-66066 demuestra una vez más que los ataques modernos no siempre dependen de un único fallo aislado.
En este caso, la explotación aprovecha las diferencias entre varias capas de software: Rails, Active Storage, libvips, libmatio y HDF5.
Cada componente puede estar funcionando de acuerdo con sus propias reglas y, sin embargo, la interacción entre todos ellos puede crear una condición de seguridad inesperada.
La disponibilidad pública de pruebas de concepto hace que el tiempo de reacción sea especialmente importante. Los sistemas que continúen expuestos no solo pueden ser encontrados por investigadores, sino también por atacantes con herramientas relativamente accesibles.
Para las organizaciones que utilizan Rails, la prioridad debería ser identificar las aplicaciones afectadas, actualizar las dependencias, comprobar la configuración del procesamiento de imágenes y revisar los registros en busca de actividad sospechosa.
La explotación activa de CVE-2026-66066 demuestra que la ventana entre la publicación de una vulnerabilidad y su aprovechamiento por atacantes puede ser extremadamente corta. Y en este caso, además, los administradores tienen que considerar que el parche inicial podría no haber eliminado todas las rutas potencialmente peligrosas.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
