Una falla crítica en Rails podría permitir que atacantes no autenticados lean archivos del servidor mediante la carga de imágenes

Ruby on Rails ha publicado correcciones para una vulnerabilidad crítica de Active Storage que podría permitir a atacantes no autenticados leer archivos arbitrarios de servidores de aplicaciones mediante cargas de imágenes manipuladas.

Seguimiento como CVE-2026-66066 (Puntuación CVSS: 9,5), la falla puede exponer el entorno del proceso Rails y secretos como secret_key_basela clave maestra de Rails, las contraseñas de la base de datos, las credenciales de almacenamiento en la nube y los tokens API. Esos secretos pueden permitir la ejecución remota de código (RCE) o el movimiento lateral hacia sistemas conectados.

Las aplicaciones afectadas utilizan libvips para el procesamiento de imágenes de Active Storage y aceptan cargas de imágenes de usuarios que no son de confianza. Rails selecciona Vips en load_defaults 7.0y los valores predeterminados posteriores lo conservan.

Ethiack y GMO Flatt Security enumeran los rangos afectados como Rails 7.0.0 a 7.2.3.1, Rails 8.0.0 a 8.0.5 y Rails 8.1.0 a 8.1.3. Las versiones Rails 6.0.0 a 6.1.7.10 se ven afectadas solo cuando Active Storage está configurado para usar Vips, que no era el procesador predeterminado en Rails 6.

El aviso oficial enumera una gama de paquetes más amplia: activestorage < 7.2.3.2. Ambos equipos de investigación ubican la ruta práctica de ataque Vips en Rails 6.0 y posteriores. Las aplicaciones que utilizan MiniMagick no quedan expuestas a través de esta ruta de ataque específica. Rails 7.0 y 7.1 están al final de su vida útil y no tienen versiones fijas, por lo que las aplicaciones en esas ramas deben actualizarse a Rails 7.2.3.2 o posterior.

Ciberseguridad

Los operadores deben actualizar a Rails 7.2.3.2, 8.0.5.1 u 8.1.3.1 y rotar todos los secretos legibles mediante el proceso de solicitud. Las instalaciones parcheadas requieren libvips 8.13 o posterior y, cuando está instalado ruby-vips, ruby-vips 2.2.1 o posterior.

Ninguno de los equipos de investigación había publicado una prueba de concepto (PoC) a las 17:30 UTC del 29 de julio de 2026. Las búsquedas de términos exactos realizadas por The Hacker News no encontraron ningún repositorio de exploits en los resultados indexados de GitHub, GitLab, Exploit-DB o Packet Storm al mismo tiempo. Rails advirtió que la aplicación del parche no invalida las credenciales que ya hayan sido robadas.

La falla se encuentra en el límite de confianza entre Active Storage y libvips. El Aviso de seguridad de rieles dice que libvips admite cargadores, protectores y otras operaciones, algunas respaldadas por bibliotecas de terceros y marcadas como «no fuzzed» o «no confiables» porque no son seguras para entradas hostiles. Active Storage no los bloqueó, lo que permitió que una carga manipulada invocara uno y revelara archivos legibles por el trabajador de Rails.

Una aplicación vulnerable no necesita exponer una operación de cambio de tamaño o miniatura dedicada. «Generar variantes no es un requisito separado», dijo Rails. El parche público También muestra que tanto el analizador Vips como el transformador pasaron archivos adjuntos no confiables a las operaciones inseguras.

Una solicitud exitosa le da al atacante una primitiva de lectura de archivos arbitraria. La ejecución del código o el movimiento lateral dependería de lo que extraiga el atacante y de lo que esas credenciales puedan alcanzar. Rails les dice a los operadores que giren secret_key_basela clave maestra y las credenciales descifradas, las credenciales de la base de datos, las claves del servicio Active Storage y los tokens de terceros.

El parche llama Vips.block_untrusted(true) cuando se inicia el almacenamiento activo. Las aplicaciones que no pueden actualizar Rails inmediatamente pueden establecer VIPS_BLOCK_UNTRUSTED cuando ejecute libvips 8.13 o posterior, o llame Vips.block_untrusted(true) con ruby-vips 2.2.1 o posterior. Rails dice que las versiones anteriores de libvips no pueden bloquear estas operaciones, por lo que las aplicaciones deben actualizar libvips o eliminarlo de la aplicación.

Ciberseguridad

Rails dio crédito a André Baptista, Bruno Mendes y Rafael Castilho de ethiaky RyotaK de Seguridad plana de OGMcon informar el problema de forma independiente. Los investigadores no han revelado el formato malicioso, la construcción de lectura de archivos ni la cadena RCE. Rails dijo que se publicarán más detalles técnicos a más tardar el 28 de agosto de 2026.

Hacker News se ha puesto en contacto con el equipo de seguridad de Rails sobre la explotación y las versiones afectadas, y con Ethiack sobre la cadena de ataque.

Ni Rails ni los investigadores informaron sobre explotación salvaje en el momento de la publicación. Una revisión realizada por The Hacker News a las 17:30 UTC del 29 de julio encontró que CVE-2026-66066 no figuraba en la versión 2026.07.27 de CISA Catálogo de vulnerabilidades explotadas conocidas.

No se dispone de un recuento fiable de aplicaciones vulnerables ni de víctimas nombradas. La puntuación de 9,5 describe la gravedad según CVSS, no cuántas implementaciones están expuestas: una implementación vulnerable también debe usar Vips, aceptar cargas de imágenes que no sean de confianza e incluir una operación explotable en su compilación libvips.

Un fallo en la extensión de Adobe Acrobat permite que sitios maliciosos lean datos web de WhatsApp – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de un cadena de vulnerabilidad ahora parcheada en la extensión Adobe Acrobat Chrome que tiene más de 314 millones de usuarios y que, de ser explotada, podría facilitar un secuestro silencioso de los datos de WhatsApp de un usuario.

La deficiencia ha sido nombrada en código. Lector hermético por Laboratorios Guardio. Se rastrea oficialmente como CVE-2026-48294 (Puntuación CVSS: 7,4), y la vulnerabilidad se describe como un caso de vulnerabilidad de divulgación de datos de origen cruzado de clase de secuencias de comandos entre sitios universales (UXSS). Afecta a todas las versiones de la extensión (ID: efaidnbmnnnibpcajpcglclefindmkaj) antes e incluyendo 26.5.2.2.

La explotación exitosa de la falla puede eludir la política del mismo origen del navegador y acceder a los datos vinculados a la sesión de la víctima en todos los orígenes. El único requisito previo es que requiera la interacción del usuario. Se debe convencer a la víctima para que visite una URL creada con fines malintencionados o interactúe con una página web comprometida que active la ruta del código vulnerable de la extensión.

Ciberseguridad

En otras palabras, un atacante puede utilizar la falla como arma para obtener acceso de lectura de origen cruzado a datos vinculados a sesiones. Esto puede incluir contenido autenticado de aplicaciones web de terceros cargadas en el navegador de la víctima.

«La configuración es casi insultantemente ordinaria: una página controlada por un atacante, diseñada para parecerse al tipo de página a la que se llega a través de resultados de búsqueda, correos electrónicos de marketing, etc.», dijo el investigador de Guardio Labs, Shaked Biner, en un informe compartido con The Hacker News. «El visitante, que ya tiene instalada la extensión Adobe Acrobat, abre esa página».

«La página activa un motor inactivo dentro de la extensión y llega directamente a WhatsApp Web. Segundos después, la vista web renderizada de WhatsApp (la lista de chat, los nombres de los contactos, los mensajes, el nombre del perfil, el texto de cualquier conversación abierta) es todo WhatsApp en manos del atacante».

Lo notable de la falla es que no requiere que un mal actor instale malware a través de otros medios, phishing las credenciales de un usuario o extraiga su cookie de sesión. Todo lo que necesita es que la víctima visite la página web diseñada.

La secuencia completa de acciones es la siguiente:

  • Una página controlada por un atacante llama a un elemento iframe cargado desde los recursos de extensión.
  • El iframe envía comandos para modificar la configuración y activar el motor Hermes, que maneja la integración de WhatsApp en la extensión solo si se habilita una característica específica («floodgate-add»).
  • La página del atacante abre WhatsApp Web en una pestaña del navegador en segundo plano.
  • El iframe envía comandos directamente al motor dirigidos a la pestaña de WhatsApp después de obtener el ID numérico de la pestaña.
  • El motor manipula WhatsApp Web inyectando un formulario POST en el DOM de WhatsApp para robar datos de WhatsApp.

«¿Por qué enviar un formulario lleva el texto del chat fuera del origen de WhatsApp? Dos habilitadores de las especificaciones HTML: un elemento de opción sin atributo de valor envía su contenido de texto, y el contenido de texto de un nodo es la concatenación de todo lo que se representa debajo de él», explicó Biner. «¡Mueva el cuerpo vivo y el valor enviado de la opción se convertirá en el texto completo de la página renderizada!»

Ciberseguridad

«El segundo facilitador es que la política de seguridad de contenido de WhatsApp Web no incluye ninguna directiva de acción de formulario, y según la especificación, esa ausencia significa que un envío de formulario de nivel superior puede navegar a cualquier origen. Por lo tanto, WhatsApp mismo realiza la navegación, PUBLICANDO su propio DOM renderizado en nuestro punto final controlado y luego procesando diligentemente todo lo que enviamos de regreso».

Como resultado, un actor de amenazas puede explotar HermeticReader para capturar la lista de chat renderizada, los nombres de los contactos, las vistas previas de los mensajes, el nombre del perfil y el texto visible de la conversación abierta.

«La industria centra su atención en las dramáticas clases de hazañas y deja que la plomería suponga que nadie las examinará detenidamente», concluyó Guardio. «La composición es la amenaza. Los defectos a nivel de plomería se convierten en el colapso a nivel del edificio, y cuanto mayor es la base de instalación, más tiempo permanece el edificio antes de que alguien revise las juntas».