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.

Una falla crítica de OpenWrt DHCPv6 podría permitir que atacantes no autenticados ejecuten código como raíz – CYBERDEFENSA.MX

OpenWrt ha enviado la versión 24.10.8 para cerrar un desbordamiento crítico de la pila DHCPv6 y un conjunto más amplio de fallas activables de forma remota en los servicios de red habilitados de forma predeterminada.

La cuestión crítica, rastreada como CVE-2026-53921 y con una puntuación de 9,8 en CVSS 3.1 en el aviso de GitHub de OpenWrt, permite que un atacante no autenticado capaz de acceder al servidor DHCPv6 sobrescriba un búfer de pila en odhcpd mediante una SOLICITUD DHCPv6 diseñada.

odhcpd se ejecuta como root, y el aviso señala que el hardware integrado comúnmente carece de valores canarios de pila y de aleatorización del diseño del espacio de direcciones (ASLR), lo que hace que la ejecución de código sea un resultado realista en dispositivos típicos.

El aviso incluye código público de prueba de concepto de Python para ambas rutas de desbordamiento documentadas. Los usuarios de la rama 24.10 deben instalar 24.10.8, mientras que los usuarios de la versión 25.12 deben instalar 25.12.5; Las imágenes de firmware están disponibles a través del Selector de firmware OpenWrt.

Hasta el 28 de julio, los materiales de OpenWrt revisados ​​no reportaron explotación en la naturaleza. La falla tampoco estaba en el catálogo de vulnerabilidades explotadas conocidas (KEV) de CISA. versión 2026.07.27aunque la ausencia de KEV no demuestra que no se haya producido explotación.

El lanzamiento llegó junto con una auditoría separada asistida por IA realizada por Casa hacker que identificó debilidades de inyección de comandos, recorrido de ruta y secuencias de comandos entre sitios (XSS) en componentes opcionales de LuCI. OpenWrt encontró un problema separado de XSS almacenado y faltaba protección contra falsificación de solicitudes entre sitios (CSRF) mientras preparaba las correcciones.

Estas correcciones separadas de LuCI no formaban parte de OpenWrt 24.10.8 y permanecieron bajo revisión el 28 de julio.

Un paquete al servidor DHCP predeterminado

El aviso asociado con CVE-2026-53921 documenta dos sitios de desbordamiento independientes en la ruta de procesamiento de solicitudes DHCPv6. En ambos, las opciones de IA diseñadas dejan espacio insuficiente en un búfer de pila fijo de 512 bytes antes de que el código agregue datos de respuesta adicionales sin una verificación de límites suficiente.

El desencadenante final es una SOLICITUD DHCPv6 no autenticada enviada al puerto UDP 547. La prueba de concepto de la primera ruta crea cinco enlaces IA_NA con una SOLICIT anterior; el segundo se activa mediante una única SOLICITUD diseñada.

El aviso enumera odhcpd master en la confirmación e432dd6 y todas las versiones anteriores que contienen dhcpv6_ia_handle_IAs() y build_ia() como afectadas. OpenWrt enumera 24.10.8 y 25.12.5 como las versiones compatibles que llevan la actualización de seguridad odhcpd relevante.

Ciberseguridad

El aviso asocia sus dos sitios documentados con CVE-2026-53921, pero las notas de la versión 24.10.8 enumeran el desbordamiento RECONF_ACCEPT por separado como un problema de alta gravedad sin un CVE. OpenWrt solucionó las escrituras subyacentes verificando la capacidad restante del búfer de respuesta antes de agregar los datos afectados.

El aviso de OpenWrt agrupa ambos sitios desbordados bajo CVE-2026-53921, mientras que las notas de la versión enumeran RECONF_ACCEPT por separado sin un CVE. El mapeo exacto aún no está claro.

Las notas de la versión de OpenWrt describen la falla como alcanzable por un atacante no autenticado adyacente a la red. El vector CVSS 3.1 del aviso utiliza AV:N (Red), no AV:A (Adyacente), y ninguna fuente explica la diferencia. Un atacante todavía necesita acceso de red al servicio DHCPv6. Una explotación exitosa podría darle al atacante el control del enrutador en lugar de simplemente bloquear el servicio.

El Versión 24.10.8 También aborda otras debilidades de la autenticación previa en odhcpd, incluida una escritura fuera de límites, uso después de la liberación, divulgación de memoria, denegación de servicio, sobrelectura de pila y suplantación de proxy de descubrimiento de vecinos. Otras correcciones del servicio predeterminado cubren tres errores de contrabando de solicitudes HTTP en uhttpd y una falla de inyección de nombre de host DHCPv6, rastreada como CVE-2026-62948, que puede producir XSS almacenado cuando un administrador abre la página de arrendamientos de LuCI.

El mismo lanzamiento incluye CVE-2026-62947 en cgi-io, que puede exponer archivos arbitrarios legibles por raíz a través del recorrido de ruta. Ese problema requiere una sesión autenticada con el permiso de descarga cgi-io y una concesión de lectura de archivos comodín aplicable. No es una falla de lectura de archivos anónima.

OpenWrt 24.10 se encuentra en mantenimiento de seguridad y el final de su vida útil se proyecta para septiembre de 2026. El proyecto recomienda migrar a serie 25.12 antes de eso. Los paquetes instalados por separado de la imagen del firmware también pueden requerir actualizaciones por separado.

Los parches aún en revisión

Matthew Hickey, también conocido como Hacker Fantastic y CTO y cofundador de Hacker House, dijo públicamente que se habían publicado correcciones para problemas de ejecución remota de código y recorrido de ruta que informó a OpenWrt.

Publicado el mantenedor de OpenWrt, Hauke ​​Mehrtens Solicitud de extracción de LuCI n.º 8878 el 26 de julio, acreditando explícitamente a Hickey y Hacker House. Una revisión realizada por The Hacker News el 28 de julio encontró que la solicitud de extracción aún estaba abierta y sin fusionar.

Fuente de la imagen: Casa Hacker

Hacker House dijo que auditó las ramas principales de LuCI y uhttpd, utilizando el compromiso de LuCI. 3b4f44d8e3d9d5de35127b42dd449babe2d19fe5 del 27 de mayo y compromiso uhttpd 7b1bec45826bd78c8afc993435bdc0f1df2fe399 desde el 13 de junio.

Describió tres rutas de autenticación previa para comprometer el dispositivo: recorrido de directorio en luci-app-bmx7, XSS almacenado en luci-app-olsr e inyección de comandos en luci-app-commands. Los cuatro restantes requerían credenciales LuCI y podían usarse para ejecutar comandos en el dispositivo.

La firma dijo que cinco hallazgos fueron tratados inicialmente como rutas de ejecución de comandos posteriores a la autenticación, pero las pruebas de OpenWrt mostraron que un caso de luci-app-commands podría funcionar sin una sesión cuando un administrador había configurado un comando como público y parametrizado. La carga útil OLSR también se puede inyectar sin credenciales LuCI, aunque solo se ejecuta cuando un administrador abre la página de vecinos.

La solicitud de extracción de OpenWrt no asigna un compromiso a cada uno de los siete envíos de Hacker House. Dentro de la solicitud de extracción #8878, seis confirmaciones corresponden al informe de Hacker House, dos abordan debilidades de seguridad adicionales que OpenWrt encontró mientras preparaba las correcciones y una corrige un problema de nombre de archivo que no es de seguridad. La solicitud de extracción también identifica dos hallazgos del mismo conjunto de informes que ya se habían corregido en el maestro, por lo que los siete envíos no se asignan uno por uno a sus nueve confirmaciones.

The Hacker News todavía está esperando la respuesta de OpenWrt sobre el mapeo de CVE, las versiones afectadas y el estado del parche.

Los cambios de seguridad en la solicitud de extracción n.° 8878 incluyen:

  • Comandos-de-la-aplicación-luci: Un carácter de tubería simple pasaba la lista de permitidos de argumentos de la aplicación y permitía que los comandos se ejecutaran como root. OpenWrt descubrió que la ruta también funcionaba sin una cookie de sesión o un token CSRF cuando un administrador había configurado un comando con el ‘1’ público y el parámetro ‘1’.
  • luci-aplicación-ddns: La configuración ddns_dateformat podría inyectar comandos en una operación de ejecución raíz, mientras que service_name permitía el recorrido de ruta. OpenWrt encontró un problema de XSS almacenado por separado mientras preparaba las correcciones.
  • luci-proto-openvpn: Los valores de configuración controlados por el atacante podrían llegar a los comandos del shell a través del tipo de clave, mientras que los parámetros del directorio de claves exponían las condiciones de recorrido de ruta.
  • luci-aplicación-olsr: Un nodo de malla malicioso podría anunciar un nombre de host diseñado que ejecuta un script en el navegador cuando un administrador ve la página de vecinos OLSR.

La ruta luci-app-commands no autenticada tiene condiciones previas materiales. La aplicación opcional debe estar instalada y un administrador debe haber expuesto deliberadamente un comando parametrizado como público. Las otras rutas de ejecución de comandos requieren acceso LuCI autenticado y los permisos de configuración relevantes. La explotación exitosa ejecuta comandos como root. No son fallas generales de autenticación previa que afecten a todos los enrutadores OpenWrt.

un separado Solicitud de extracción de scripts ddns aborda la misma configuración insegura de ddns_dateformat fuera de LuCI. Un operador DDNS delegado podría colocar la sintaxis del shell en el valor, y la ejecución se producirá cuando se inicie el actualizador, incluso después de la reconfiguración o el reinicio. La misma verificación del 28 de julio encontró que la solicitud de extracción estaba abierta y no fusionada.

Ciberseguridad

Otros dos hallazgos del mismo conjunto de informes ya se habían solucionado en la rama maestra de LuCI: un recorrido de ruta de lectura de archivos no autenticado en luci-app-bmx7 e inyección de comandos a través de ttyd_start en luci-app-dockerman. OpenWrt dijo que ambos todavía requerían backports para liberar ramas.

Hacker House dijo que el cruce de BMX7 se incluyó en su divulgación del 8 de julio y lo caracterizó como una ruta de autenticación previa para comprometer el dispositivo. OpenWrt aviso publico describe el impacto de manera más específica como acceso no autenticado a archivos legibles por el proceso CGI y acredita a nebusecurity como el reportero. Hacker House dijo que no sabe si los informes eran duplicados o por qué el crédito difiere.

IA en descubrimiento y revisión de parches

Hacker House describió la auditoría de OpenWrt como un proceso de inferencia difusa de cuatro etapas que comienza con un modelo de amenaza. El método examina repetidamente el código para generar un amplio conjunto de posibles vulnerabilidades.

Debido a que ese grupo contiene muchos falsos positivos, la etapa final utiliza un modelo de mayor precisión para filtrar los resultados. Luego, los investigadores confirman manualmente los hallazgos restantes en el código y, cuando sea práctico, en un sistema en ejecución antes de informarlos.

Hacker House dijo que Qwen 3.6 35B Heretic se utiliza para la etapa de inferencia difusa centrada en el recuerdo. Para la clasificación de la cuarta etapa en proyectos de código abierto, utiliza un modelo de frontera como Claude Opus 4.6 de Anthropic. Qwen 3.5 115B se puede sustituir cuando una auditoría debe ejecutarse completamente fuera de línea, permitiendo que el código fuente privado permanezca dentro del entorno del cliente.

Después de la clasificación, los investigadores inspeccionan manualmente el código y, cuando sea práctico, confirman el problema en tiempo de ejecución mediante pruebas de seguridad de aplicaciones dinámicas (DAST) estándar. Hacker House dijo que solo presenta hallazgos que ha confirmado como vulnerabilidades, aunque las cargas útiles de exploits pueden requerir ajustes durante la validación manual.

La firma dijo que les da a los proyectos de código abierto de siete a 10 días hábiles para reconocer un informe y luego trabaja con los mantenedores en su cronograma de remediación preferido. Si no llega ningún acuse de recibo, puede publicar detalles limitados para alentar al proyecto a responder o abordar el hallazgo.

OpenWrt también utilizó IA durante partes del proceso de remediación. Varias confirmaciones propuestas incluyen un tráiler Asistido por: Claude:claude-opus-5, y una revisión automatizada de la solicitud de extracción de LuCI dice que se generó con Claude Code. Por lo tanto, los modelos contribuyeron al descubrimiento de candidatos, la clasificación y la revisión de parches, mientras que los investigadores y mantenedores verificaron manualmente los hallazgos y las correcciones.

Para las correcciones enviadas, los usuarios deben instalar OpenWrt 24.10.8 o 25.12.5 y actualizar los paquetes instalados por separado. Los administradores también deben revisar los permisos delegados de LuCI, eliminar aplicaciones opcionales que no utilizan y comprobar si algún comando en luci-app-commands es público y está parametrizado.

A partir del 28 de julio, las dos solicitudes de extracción no enumeraban CVE, puntuaciones CVSS, rangos completos de versiones afectadas ni versiones fijas de paquetes estables. Ninguno informó explotación en la naturaleza.

Una falla crítica de TeamCity podría permitir a los atacantes ejecutar comandos del sistema operativo sin iniciar sesión – CYBERDEFENSA.MX

JetBrains es instando a los clientes de versiones locales de TeamCity para actualizar a la última versión luego del descubrimiento de un problema de seguridad crítico que podría resultar en la ejecución de código arbitrario.

La vulnerabilidad, asignada CVE-2026-63077 (Puntuación CVSS: 9,8), afecta a todas las versiones locales de TeamCity. Se ha solucionado en las versiones 2025.11.7 y 2026.1.3. Las instancias de TeamCity Cloud ya han sido actualizadas. JetBrains le ha dado crédito a Antoni Tremblay por descubrir e informar la falla el 10 de julio de 2026.

«Si se explota, esta falla puede permitir que un atacante no autenticado con acceso HTTP(S) a un servidor TeamCity evite los controles de autenticación y ejecute comandos arbitrarios del sistema operativo con los privilegios del proceso del servidor TeamCity», dijo JetBrains.

La falla permite la ejecución remota de código no autenticado a través del protocolo de sondeo del agente para eludir las comprobaciones de autenticación y lograr la ejecución de comandos. Dependiendo de los privilegios otorgados al proceso del servidor TeamCity, un compromiso exitoso puede provocar la exposición de los datos, las configuraciones y las credenciales almacenadas de TeamCity, o la modificación del estado del servidor.

Ciberseguridad

Además de lanzar las versiones 2025.11.7 y 2026.1.3, JetBrains ha lanzado una complemento de parche de seguridad para las versiones 2017.1+ para que los clientes que no puedan aplicar una actualización aún puedan parchear sus entornos. No hay evidencia que indique que la falla haya sido explotada en la naturaleza.

«El complemento del parche de seguridad abordará sólo la vulnerabilidad descrita anteriormente (CVE-2026-63077)», advirtió JetBrains. «Siempre recomendamos actualizar su servidor a la última versión para beneficiarse de muchas otras actualizaciones de seguridad».

Como mejores prácticas, se recomienda a los clientes que consideren requerir conexiones VPN o implementar una capa adicional de seguridad para evitar el acceso no autorizado a los servidores de TeamCity con acceso a Internet.

«Incluso exponer la pantalla de inicio de sesión de TeamCity o la API REST puede proporcionar a los atacantes posibles puntos de entrada para explotar vulnerabilidades recientemente reveladas», añadió.

Zimbra parchea la inyección crítica de comandos SNMP y cuatro vulnerabilidades XSS – CYBERDEFENSA.MX

Zimbra tiene correcciones implementadas para abordar múltiples problemas críticos de seguridad, incluida una falla de inyección de comandos en el componente de monitoreo del Protocolo simple de administración de red (SNMP).

Se han solucionado hasta nueve vulnerabilidades de seguridad Zimbra 10.1.20. Encabezando la lista se encuentra una vulnerabilidad de inyección de comandos en el componente de monitoreo SNMP cuando las notificaciones SNMP están habilitadas.

También se han solucionado cuatro fallos de secuencias de comandos entre sitios (XSS) en el cliente web clásico:

  • Una vulnerabilidad de secuencias de comandos entre sitios (XSS) almacenadas que podría permitir que nombres de archivos adjuntos maliciosos ejecuten secuencias de comandos en condiciones específicas.
  • Una vulnerabilidad XSS donde los campos manipulados podrían ejecutar un script malicioso en condiciones específicas.
  • Una vulnerabilidad XSS donde un campo diseñado podría ejecutar un script malicioso cuando se procesa.
  • Una vulnerabilidad XSS donde los archivos adjuntos diseñados podrían ejecutar un script malicioso cuando se procesan.

Por otra parte, se han publicado correcciones para una omisión de restricción de reenvío de correo (CVE-2026-50055) que podría permitir a los usuarios autenticados filtrar correo electrónico a pesar de que las restricciones de reenvío de correo estén habilitadas. Al investigador de seguridad de Rapid7, Jonah Burgess, se le atribuye el mérito de descubrir e informar la falla.

Ciberseguridad

La compañía no compartió ningún detalle adicional y afirmó que «de acuerdo con las mejores prácticas de la industria, la divulgación de información está limitada para corregir vulnerabilidades de seguridad».

El lanzamiento llega poco más de una semana después de que Zimbra parcheara una falla crítica XSS almacenada en el Cliente Web Clásico que podría resultar en la ejecución de código arbitrario.

Aunque ninguna de las vulnerabilidades identificadas ha sido marcada como explotada activamente, los errores XSS en el software de correo electrónico han sido explotados repetidamente por malos actores en el pasado, lo que hace crucial que los clientes apliquen las actualizaciones para mantener el entorno seguro.

Falla crítica en la plataforma de IA de ServiceNow explotada para la ejecución de código no autenticado – CYBERDEFENSA.MX

Los actores de amenazas ahora están explotando una falla de seguridad crítica recientemente revelada que afecta a ServiceNow AI Platform, según Cibernético desactivado.

En una publicación compartida en X, la firma de inteligencia de amenazas dijo que está observando la explotación salvaje de CVE-2026-6875 (Puntuación CVSS: 9,5), una vulnerabilidad de escape de sandbox que podría permitir a un usuario no autenticado ejecutar código arbitrario.

Los parches para el defecto fueron liberado por ServiceNow durante todo junio en las siguientes versiones:

  • Brasil EA y Brasil GA
  • Parche australiano 2
  • Parche Zurich 7b y Parche Zurich 9
  • Revisión 1b del parche 12 de Yokohama y parche 13 de Yokohama
Ciberseguridad

Searchlight Cyber, que reveló detalles técnicos adicionales, dijo que informó el problema el 1 de abril de 2026 y agregó que permite un compromiso completo de la instancia de ServiceNow, así como de todos los servidores proxy conectados.

Además de implementar una solución, ServiceNow está «mejorando la seguridad de las instancias al restringir severamente el tipo de código que se puede ejecutar en contextos sandbox», dijo el investigador de seguridad Adam Kues. anotado.

Según Defused, los esfuerzos de explotación apuntan al mismo punto final de autenticación previa («/assessment_thanks.do») mediante solicitudes POST HTTP, aunque el dispositivo de escape de la zona de pruebas conduce a la misma primitiva de ejecución de código por una ruta diferente documentada en el exploit de prueba de concepto (PoC).

A la luz de la explotación activa, se recomienda a los clientes de versiones autohospedadas que apliquen las correcciones, si aún no lo han hecho, para contrarrestar la amenaza.

La vulnerabilidad crítica de NGINX puede bloquear a los trabajadores y permitir la ejecución remota de código – CYBERDEFENSA.MX

F5 ha enviado correcciones para una falla crítica de nginx que permite a un atacante remoto no autenticado desencadenar un desbordamiento del búfer de montón en el proceso de trabajo con solicitudes HTTP diseñadas. CVE-2026-42533 fue parcheado el 15 de julio en nginx 1.30.4 (estable) y 1.31.3 (línea principal)y en NGINX Plus 37.0.3.1; cualquiera que tenga una versión anterior debería actualizar.

Activarlo puede bloquear o reiniciar al trabajador, provocando una denegación de servicio; donde ASLR está deshabilitado o se puede omitir, F5 dice que también puede permitir la ejecución remota de código.

El desbordamiento reside en el motor de secuencias de comandos de nginx, el código que ensambla cadenas a partir de directivas en el momento de la solicitud. Sólo aparece bajo una configuración específica: una basada en expresiones regulares map cuya variable de salida está referenciada en una expresión de cadena después de una captura de una coincidencia de expresiones regulares anterior.

Bajo ese patrón, la evaluación de dos pasadas del motor se desmorona. La primera pasada mide cuántos bytes necesita el resultado y asigna un búfer para que quepa; la segunda pasada escribe los bytes. Ambos leen el mismo estado de captura compartido y la evaluación de la expresión regular del mapa entre las dos pasadas lo sobrescribe.

Entonces, la pasada de medición dimensiona el búfer para la captura original, una referencia como $1 desde la coincidencia de ubicación, mientras que el pase de escritura lo completa desde uno diferente, del tamaño de un atacante. El búfer es demasiado pequeño y tanto la longitud como el contenido del desbordamiento provienen directamente de la solicitud.

Ciberseguridad

Esto no afecta a todos los servidores nginx; la exposición depende de la configuración, no solo de la versión. F5 consultivo enumera la falla que afecta a NGINX Ingress Controller, Gateway Fabric, App Protect WAF e Instance Manager junto con el servidor central y NGINX Plus, aunque en el momento de la publicación, F5 no había enumerado compilaciones fijas para esos cuatro productos.

F5 obtiene una puntuación de 9,2 en CVSS v4 y 8,1 en la escala v3.1 anterior, y califica la complejidad del ataque como alta. Cada versión de nginx de 0.9.6 a 1.31.2 es vulnerable, un rango que se remonta a 2011, cuando map obtuvo soporte para expresiones regulares.

CVE-2026-42533 fue informado a F5 de forma independiente por más de una docena de investigadores; el proveedor les agradeció por «hacernos llegar este problema de forma independiente». El propio registro de cambios de nginx atribuye la solución a Mufeed VH de Winfunc Research y al mantenedor Maxim Dounin.

Uno de los periodistas, Stan Shawque publica como ciberstansacar un redacción detallada eso va más allá del aviso. F5 condiciona que la ejecución de código en ASLR esté deshabilitada o se pueda omitir, y el argumento de Shaw es que la falla proporciona la omisión en sí. Le dijo a The Hacker News que la captura de datos también se ejecuta a la inversa: cuando la captura de datos es más pequeña que la original, el búfer de gran tamaño devuelve datos del montón no inicializados, y en una compilación predeterminada de Ubuntu 24.04, un único GET no autenticado recupera las direcciones que necesita una carga útil.

«Un lector del aviso de F5 podría concluir razonablemente que esto es sólo DoS en sistemas predeterminados. No lo es», dijo Shaw. Es una afirmación más fuerte que la que hace F5, una que, según él, alcanzó 10 de 10 en sus propias pruebas, y está reteniendo los detalles de explotación y una prueba de concepto por ahora, por lo que nadie puede verificarlo de forma independiente todavía.

La solución es actualizar a nginx 1.30.4 o 1.31.3, o NGINX Plus 37.0.3.1. Para cualquiera que no pueda parchear de inmediato, la mitigación temporal de F5 es cambiar los mapas de expresiones regulares afectados a capturas con nombre, lo que, según Shaw, cierra la ruta principal y cubre la mayoría de las configuraciones.

Pero dijo a The Hacker News que la mitigación deja abierto un camino más estrecho: un map que define el mismo grupo con nombre como expresión regular de ubicación alcanza el mismo desbordamiento a través de una segunda ruta de código, que confirmó con AddressSanitizer y que el aviso de F5 no menciona. «Actualizar a 1.30.4/1.31.3 es la única solución completa», afirmó.

La exposición a grep for es estrecha: una expresión regular map cuya variable aparece en una expresión de cadena junto a una captura numerada ($1, $2) de una expresión regular anterior, con la captura escrita delante de la variable del mapa.

Ciberseguridad

el propio shaw escáner automatiza esa verificación en una configuración, sigue las inclusiones y marca solo el orden explotable; no explota nada, pero como herramienta del reportero no es un producto de vendedor.

Este es el tercer desbordamiento del montón en el código de evaluación de expresiones de nginx revelado en aproximadamente dos meses, después de Rift (CVE-2026-42945) en mayo y un error de capturas superpuestas en el módulo de reescritura (CVE-2026-9256) días después.

Los tres son la misma clase de falla: el motor de script de dos pasadas de nginx dimensiona un búfer en una pasada y escribe en él en la siguiente, y cada vez que la escritura supera el tamaño medido. El desencadenante es diferente: una bandera obsoleta en Rift, capturas superpuestas en el error de reescritura, estado de captura golpeado aquí. La debilidad compartida, como señala el investigador, es un diseño de dos pasos que confía en su propia medición.

A partir del 20 de julio, CVE-2026-42533 no estaba en la lista de CISA. Catálogo de vulnerabilidades explotadas conocidas y no había aparecido ningún código de explotación público. Shaw dice que publicará su propia prueba de concepto 21 días después del parche, y Rift es el caso de precaución: su exploit se hizo público a los pocos días y atrajo una explotación activa poco después. Esa es la razón para actualizar antes de que llegue este.

The Hacker News preguntó a F5 si el cambio a capturas con nombre cierra completamente CVE-2026-42533, dada la variante de los documentos de Shaw, y cuándo se enviarán las compilaciones fijas para los productos posteriores afectados. F5 no había respondido mediante publicación.

Zoom corrige una falla crítica de Windows que podría permitir la apropiación de cuentas – CYBERDEFENSA.MX

Zoom ha publicado actualizaciones de seguridad para una falla de seguridad crítica que afecta a Zoom Workplace para Windows y que podría facilitar la apropiación de cuentas.

La vulnerabilidad, rastreada como CVE-2026-53412 (Puntuación CVSS: 9,8), afecta a Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows.

«La validación de entrada incorrecta en Zoom Desktop Client para Windows, Zoom VDI Client para Windows y Zoom Meeting SDK para Windows puede permitir que un usuario no autenticado realice una apropiación de cuenta a través del acceso a la red», Zoom dicho en un aviso publicado esta semana.

Las últimas correcciones de seguridad también abordan tres fallas de alta gravedad:

  • CVE-2026-53411 (Puntuación CVSS: 7,8): una vulnerabilidad de validación de entrada incorrecta en el complemento VDI de Zoom Workplace para Windows anterior a la versión 6.6.14 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
  • CVE-2026-53410 (Puntuación CVSS: 7.0): una vulnerabilidad de condición de carrera de tiempo de verificación a tiempo de uso (TOCTOU) en el proceso de instalación y desinstalación de ciertos clientes Zoom para Windows que podría permitir que un usuario local autenticado escale privilegios.
  • CVE-2026-53409 (Puntuación CVSS: 7,8): una vulnerabilidad de gestión de privilegios inadecuada en Zoom Rooms para Windows anterior a la versión 7.1.0 que puede permitir a un usuario autenticado realizar una escalada de privilegios a través del acceso local.
Ciberseguridad

Vale la pena señalar que CVE-2026-53410 afecta a los siguientes productos:

  • Zoom Workplace para Windows antes de la versión 7.0.5
  • Cliente Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
  • Complemento Zoom Workplace VDI para Windows anteriores a 6.5.17 y 6.6.14 en sus respectivas ramas
  • Zoom Rooms para Windows anteriores a 7.0.5
  • Control remoto para Zoom Contact Center para Windows anterior a la versión 7.0.0

Al momento de escribir este artículo, no hay indicios de que alguna de las fallas esté siendo explotada en ataques del mundo real. Los usuarios pueden mantenerse protegidos aplicando las últimas actualizaciones.

Una falla crítica de Zimbra podría permitir que los correos electrónicos elaborados ejecuten código malicioso en las sesiones de los usuarios

Zimbra insta a los clientes a aplicar actualizaciones para abordar una vulnerabilidad de seguridad crítica que afecta al cliente web clásico y que podría resultar en la ejecución de código arbitrario.

La vulnerabilidad ha sido descrito como un caso de secuencias de comandos entre sitios (XSS) almacenadas que podrían permitir que correos electrónicos especialmente diseñados ejecuten secuencias de comandos maliciosas en la sesión de un usuario. Todavía no se le ha asignado un identificador CVE.

«La actualización soluciona un problema de seguridad en el cliente web clásico donde un correo electrónico especialmente diseñado podría ejecutar código malicioso cuando se abre el correo electrónico», Zimbra dicho. «Si se explota, podría permitir el acceso a la información del buzón, a los datos de la sesión o a la configuración de la cuenta».

Las vulnerabilidades XSS ocurren cuando una aplicación incluye datos que no son de confianza en una página web sin la validación o el escape adecuados. Esto permite a los atacantes inyectar y ejecutar JavaScript malicioso en los navegadores de las víctimas, lo que puede provocar secuestro de sesión, robo de credenciales y compromiso de la cuenta.

Ciberseguridad

XSS almacenado, o XSS persistente, es un tipo de falla XSS en la que el script inyectado se almacena permanentemente en los servidores de destino en una base de datos en forma de un comentario aparentemente inofensivo o una publicación en un foro, lo que hace que cualquier visitante del sitio se vea comprometido tan pronto como la página que contiene JavaScript se carga en su navegador web.

Aunque Zimbra no menciona la vulnerabilidad que se está explotando en la naturaleza, las fallas XSS en Zimbra han sido un imán de ataques durante años, y los malos actores intentaron convertir tales vulnerabilidades en armas desde diciembre de 2021.

En octubre pasado, se alegaba que una falla XSS almacenada en el cliente web clásico (CVE-2025-27915, puntuación CVSS: 5.4) había sido explotada como día cero en ataques dirigidos al ejército brasileño, aunque Zimbra le dijo a The Hacker News en ese momento que no encontró evidencia que lo respaldara.

Otras fallas XSS que han sido explotadas por actores de amenazas incluyen CVE-2023-37580 y CVE-2024-27443. Dado su alto potencial de abuso, se recomienda a los usuarios actualizar a Zimbra Collaboration Suite versión 10.1.19 para una protección óptima.

PoC pública publicada para falla crítica de SSH del lado del cliente libssh2 CVE-2026-55200 – CYBERDEFENSA.MX

Ya está disponible una prueba de concepto pública CVE-2026-55200un defecto crítico en libssh2 que permite que un servidor SSH malicioso o comprometido provoque daños en la memoria de un cliente que se conecta, con posible ejecución de código. Sin credenciales, sin interacción del usuario. El error afecta a todas las versiones hasta e incluyendo 1.11.1 y lleva una puntuación CVSS 4.0 de 9.2.

libssh2 es una biblioteca SSH del lado del cliente, no un servidor. Esa distinción importa. Está integrado en curl, Git, PHP, agentes de respaldo, actualizadores de firmware y una larga lista de dispositivos.

Cualquier cosa que lo vincule y llegue a un punto final SSH que no es de confianza es un objetivo potencial. Muchas de esas copias están vinculadas estáticamente, por lo que una actualización del paquete de distribución no las afectará y es posible que no sepas que están allí.

Cómo funciona el error

La falla reside en ssh2_transport_read() en transport.c, la función que analiza los paquetes SSH entrantes durante el protocolo de enlace. Leyó el campo de longitud de paquete controlado por el atacante y solo rechazó valores inferiores a 1. Nunca impuso un límite superior.

Ciberseguridad

El cálculo del tamaño agrega la longitud del paquete a un par de valores pequeños usando aritmética de 32 bits, por lo que una longitud de 0xffffffff se ajusta a un número pequeño. libssh2 luego asigna un búfer del tamaño del número pequeño, mientras que el código posterior escribe el paquete completo y de gran tamaño en él.

El resultado es una escritura en el montón fuera de los límites, clasificada como CWE-680desbordamiento de enteros a desbordamiento de búfer, una primitiva clásica para la ejecución de código. El arreglar agrega la verificación que falta, rechazando cualquier longitud de paquete superior a LIBSSH2_PACKET_MAXPAYLOAD antes de que se ejecuten las matemáticas.

libssh2 ha tropezado con esto antes. En 2019, lanzó la versión 1.8.1 para corregir un lote de nueve fallas lideradas por CVE-2019-3855, un desbordamiento de enteros casi idéntico en su lectura de transporte que también permitía que un servidor malicioso ejecutara código en un cliente conectado. Siete años después, la misma clase de error vuelve a aparecer en el mismo código.

El investigador de seguridad Tristan Madani informó del problema. Los mantenedores fusionaron el parche a través de solicitud de extracción #2052 el 12 de junio. VulnCheck publicó el CVE el 17 de junio.

Se ha realizado una prueba de concepto pública. publicado en «exploitarium», un archivo GitHub de código de explotación cuyo autor dice que las entradas se publicaron sin informe previo. El archivo contiene un andamio de activación SSH verificado localmente y un arnés RCE local controlado para el error libssh2, no un exploit remoto llave en mano. La ejecución confiable de código en una aplicación activa aún dependería del binario de destino, el comportamiento del asignador, las mitigaciones y cómo el software incorpora libssh2.

Vale la pena sopesar el contexto. El autor admite que el archivo salió incompleto, con algunas entradas débiles y la IA provocando la confusión. A partir de ahora, la calificación de explotación de CISA para CVE todavía es nula y no se ha informado de ningún uso silvestre.

que hacer

Aún no hay una versión fija de libssh2. El parche se encuentra en la fuente principal y se publica una versión etiquetada. todavía estando preparadopor lo que las distribuciones de Linux y los proyectos posteriores lo respaldan ellos mismos; Debian, por ejemplo, ya tiene una compilación reparada en pruebas.

Ciberseguridad

NHS England Digital tiene emitió un aviso instando a las organizaciones afectadas a actualizarse.

  • Haga un inventario de todo lo que vincula libssh2, incluidas las copias estáticas o empaquetadas que los administradores de paquetes no marcarán. Las implementaciones de curl, Git y PHP son portadores comunes.
  • Aplique una compilación que incluya la confirmación 97acf3d, ya sea un backport de distribución o una compilación de código fuente parcheada, y observe el canal de asesoramiento de su proveedor para conocer el estado de la versión.
  • Hasta que se aplique el parche, restrinja las conexiones SSH salientes a servidores confiables y verifique las claves del host. Dar prioridad a los clientes que llegan a servidores SSH externos o resolver hosts mediante nombres que un atacante podría redirigir. Esté atento a anomalías de paquetes de gran tamaño y fallas inexplicables de clientes.

Parche también el resto del lote: CVE-2026-55199 (CVSS 8.2), una denegación de servicio que atrapa a un cliente que se conecta en un bucle de CPU mediante un recuento de extensiones falso, y CVE-2025-15661 (CVSS 8.3), una sobrelectura del montón SFTP.

El problema principal es un error de corrupción de memoria previo a la autenticación en el código que se incluye en más clientes y dispositivos de los que nadie ha mapeado por completo.

Las preguntas abiertas son qué tan rápido alguien convierte el arnés local en un exploit remoto confiable y cuántas copias empaquetadas permanecen vulnerables porque nadie recuerda que enviaron libssh2 dentro.

Una falla crítica de Splunk Enterprise permite a los atacantes ejecutar código sin autenticación – CYBERDEFENSA.MX

Splunk ha publicado actualizaciones de seguridad para abordar una falla de seguridad crítica en Splunk Enterprise que podría explotarse para realizar operaciones de archivos no autenticados e incluso la ejecución remota de código.

La vulnerabilidad, rastreada como CVE-2026-20253tiene una calificación de 9,8 en el sistema de puntuación CVSS.

«En las versiones de Splunk Enterprise inferiores a 10.2.4 y 10.0.7, un usuario no autenticado podría crear o truncar archivos arbitrarios a través de un punto final de servicio secundario de PostgreSQL», Splunk dicho en una alerta esta semana.

«La vulnerabilidad existe porque el punto final del servicio complementario PostgreSQL carece de controles de autenticación, lo que permite que cualquier usuario accesible en la red invoque operaciones de archivos sin credenciales».

Ciberseguridad

El problema se ha solucionado en las siguientes versiones:

  • Splunk Enterprise 10.0.0 a 10.0.6: corregido en 10.0.7
  • Splunk Enterprise 10.2.0 a 10.2.3: corregido en 10.2.4
  • Splunk Enterprise 10.4: no afectado

Splunk, que es parte de Cisco, dijo que Splunk Cloud no se ve afectado por la vulnerabilidad ya que los sidecars de Postgres no se utilizan en el producto.

De qué se trata el defecto

El viernes, mira Tower Labs liberado detalles técnicos adicionales de CVE-2026-20253, que indican que podría explotarse para lograr la ejecución remota de código previamente autenticado en sistemas susceptibles a través de los puntos finales «/v1/postgres/recovery/backup» y «/v1/postgres/recovery/restore».

La cadena de ataque funciona de la siguiente manera:

  • Conéctese a una base de datos controlada por un atacante y descargue su contenido en un archivo arbitrario usando el punto final /backup
  • Cargue el volcado de la base de datos controlada por el atacante en la instancia local de PostgreSQL utilizando el punto final /restore incluyendo un argumento «passfile» que especifique la ruta a un «.pgpass«archivo («/opt/splunk/var/packages/data/postgres/.pgpass») que contiene la contraseña para el usuario «postgres_admin»
  • Las consultas SQL definidas en el volcado de la base de datos serán ejecutadas por la instancia PostgreSQL de Splunk

Un atacante podría convertir esta debilidad en un arma para definir una nueva función que usa lo_exportar – una función utilizada para extraer un BLOB de la base de datos y guardarlo como un archivo en el sistema de archivos – para escribir contenido controlado por el atacante en un archivo, tras lo cual la función se ejecuta durante el proceso de restauración.

«En este punto, podemos autenticarnos, restaurar el SQL controlado por el atacante e interactuar con la base de datos local», dijeron los investigadores de seguridad Piotr Bazydlo y Yordan Ganchev. «Una vez que pudimos restaurar el SQL controlado por el atacante en la instancia local de PostgreSQL, rápidamente armamos una plantilla de volcado de base de datos que nos proporcionó una escritura de archivo controlada».

Ciberseguridad

Armado con una primitiva de escritura de archivos arbitraria en el sistema de archivos Splunk, un atacante podría escalar aún más a la ejecución remota de código sobrescribiendo un script de Python que Splunk ejecuta con frecuencia (por ejemplo, «/opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py») para incluir la carga maliciosa.

La secuencia completa de acciones se encuentra a continuación:

  • Cree una base de datos y configúrela de modo que un usuario pueda autenticarse sin contraseña y otorgarle permisos suficientes para invocar funciones como lo_export.
  • Utilice el punto final /backup para colocar un volcado de la base de datos remota en el sistema de archivos Splunk
  • Utilice el punto final /restore para cargar el volcado de la base de datos malicioso, desencadenar la ejecución de la función maliciosa durante el proceso de restauración y escribir un script Python controlado por el atacante en el sistema de archivos Splunk.

Aunque no hay evidencia de que la falla haya sido explotada en la naturaleza, la disponibilidad de los detalles específicos de la vulnerabilidad puede ser suficiente para impulsar a los actores de amenazas a desencadenar intentos oportunistas. Es esencial que los usuarios actúen rápidamente para aplicar las correcciones y mantenerse protegidos.