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.

La falla de Ruflo MCP permite a atacantes no autenticados ejecutar comandos y envenenar la memoria de la IA – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han señalado una falla de seguridad de máxima gravedad en Ruflóun meta-arnés de agente de código abierto para Anthropic Claude Code y OpenAI Codex, que podría resultar en la ejecución remota de código no autenticado.

La vulnerabilidad, rastreada como CVE-2026-59726 (Puntuación CVSS: 10.0), afecta a todas las versiones del proyecto anteriores a la versión 3.16.3. ha sido nombrado en clave raízruf por el equipo de investigación de Noma Security, Noma Labs.

Lanzado originalmente como Claude Flow, Ruflo es una plataforma y un arnés de orquestación de múltiples agentes de inteligencia artificial que permite a los usuarios implementar enjambres de múltiples jugadores, coordinar flujos de trabajo autónomos y crear sistemas de inteligencia artificial conversacionales. El proyecto cuenta con más de 66.500 estrellas en GitHub.

El quid de la vulnerabilidad es que Ruflo expuso 233 herramientas, incluida la ejecución de comandos de shell, operaciones de bases de datos, administración de agentes y almacenamiento de memoria, a través de un puente de Protocolo de contexto modelo (MCP) no autenticado que está abierto a la red de forma predeterminada.

Ciberseguridad

Específicamente, se encontró que el archivo de configuración YAML «docker-compose.yml» vincula el puerto 3001 a 0.0.0.0 de forma predeterminada, exponiendo el puente en todas las interfaces de red. Dicho esto, el grado de exposición depende de las reglas de firewall, los grupos de seguridad y la segmentación de la red de la implementación. Vale la pena señalar que cualquier instancia accesible en red es completamente explotable sin autenticación.

Como resultado, un único HTTP POST no autenticado en el puerto 3001 hizo posible obtener la ejecución remota completa de código dentro de una implementación Ruflo susceptible, según el investigador de seguridad Eli Ainhorn.

curl -s -X POST https://:3001/mcp -H "Content-Type: application/json" -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"ruflo__terminal_execute","arguments":{"command":"id && hostname"}}}'

Armado con este punto de apoyo, un atacante podría desviar las claves API que Ruflo usa para interactuar con proveedores de modelos de lenguaje grandes (LLM), leer cada conversación de usuario almacenada en la plataforma e interferir con la memoria del sistema de inteligencia artificial para influir en las respuestas y el comportamiento del modelo.

En otras palabras, la ejecución de comandos sirve como un trampolín para un compromiso total, lo que permite el robo de claves API de LLM, la utilización de agentes como armas, el envenenamiento de la memoria de la IA, la recolección de conversaciones y la implementación persistente de puertas traseras al escribir una carga útil maliciosa en el directorio «/app».

«Antes de 3.16.3, la implementación predeterminada de Docker-Compose de Ruflo exponía los puntos finales POST /mcp y POST /mcp/:group del puente MCP sin autenticación, lo que permitía a un atacante de red no autenticado invocar herramientas/llamar a terminal_execute, obtener un shell en el contenedor del puente, leer las claves API del proveedor y envenenar los patrones del almacén de aprendizaje de AgentDB», según un descripción de la falla en la Base de Datos Nacional de Vulnerabilidad (NVD) del NIST.

Tras la divulgación responsable el 30 de junio de 2026, un solución para la vulnerabilidad fue impulsado por el mantenedor del proyecto, Reuven Cohen, dentro de las 24 horas. Como parte del parche, el puente MCP ahora se vincula a la interfaz loopback de forma predeterminada, bloquea «terminal_execute» detrás de los controles de ejecución de la herramienta del lado del servidor y habilita la autenticación MongoDB para evitar el robo de conversaciones, entre otras cosas.

«El envío del puente MCP en ruflo/docker-compose.yml expuso POST /mcp sin autenticación», dijo Cohen en las notas de la versión. «Los valores predeterminados de Docker-Compose vinculan el puente y MongoDB a todas las interfaces».

Ciberseguridad

«En combinación, un atacante de red no autenticado podría invocar herramientas/llamada → terminal_execute dentro del contenedor puente, obtener un shell, leer cada clave API del proveedor desde el entorno del contenedor, generar enjambres controlados por el atacante en las claves de la víctima y persistir un patrón envenenado en el almacén de aprendizaje de AgentDB que dirige futuras salidas de IA».

Se recomienda a los operadores que ejecutan una instancia expuesta cerrar inmediatamente los puertos de firewall 3001 y 27017, rotar todas las claves API de LLM, auditar el almacén de patrones de AgentDB para detectar entradas inyectadas de agentdb_pattern-store y verificar MongoDB para detectar signos de manipulación.

«La vulnerabilidad de Ruflo permitió crear un enjambre de agentes para hacer lo que el atacante quisiera e incluso alterar la memoria de la IA», dijo Noma. «La capacidad de escribir instrucciones maliciosas en la memoria persistente de IA de una plataforma significa que un atacante puede influir en las respuestas que la IA da a cada futuro usuario de la plataforma, mucho después de que la intrusión original haya terminado».

«Para las organizaciones expuestas a una vulnerabilidad como esta, la remediación requiere más que una actualización de software. Las credenciales del proveedor de IA deben tratarse como comprometidas y rotarse, la memoria de IA de la plataforma debe auditarse para detectar manipulación y los contenedores deben reconstruirse a partir de una imagen limpia».

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ó.

Los atacantes aprovechan la falla de inyección de comando de Arista VeloCloud Orchestrator – CYBERDEFENSA.MX

Una falla de seguridad de máxima gravedad que afecta a las versiones locales de Arista VeloCloud Orchestrator (VCO) ha sido objeto de explotación activa en la naturaleza.

La vulnerabilidad, identificada como CVE-2026-16812 (puntuación CVSS: 10.0), es un caso de inyección de comandos del sistema operativo que podría allanar el camino para la ejecución de código arbitrario.

«VeloCloud Orchestrator (VCO) local tiene un problema de seguridad que puede permitir que un atacante remoto acceda a una funcionalidad interna privilegiada y afecte al host de VCO», Arista dicho en un aviso del lunes.

«La explotación exitosa puede comprometer la confidencialidad, integridad y disponibilidad del orquestador y los datos administrados por el orquestador. Esta funcionalidad fue diseñada para uso interno únicamente y no está destinada a ser accesible de forma remota».

Ciberseguridad

La compañía estadounidense de equipos de red dijo que el problema ya se había solucionado de antemano en las versiones alojadas y dedicadas de VCO. Las siguientes versiones se ven afectadas:

  • Versiones de VCO 5.2.x anteriores a 5.2.3.14
  • Versiones de VCO 6.1.x anteriores a 6.1.3.4
  • Versiones de VCO 6.4.x anteriores a 6.4.2.4
  • Versiones de VCO 7.0.x anteriores a 7.0.0.1

Arista reconoció que la vulnerabilidad fue descubierta externamente y se sabía que se explotaba activamente, pero no reveló cuándo se reveló ni cuántos clientes podrían haber sido potencialmente afectados como parte de una actividad cibernética maliciosa que utilizó el error como arma.

Como indicadores de compromiso (IoC), la compañía compartió un conjunto de tres direcciones IP que, según dijo, eran responsables de «realizar los ataques», instando a los clientes a bloquearlas y revisar los registros para determinar si están presentes.

  • 8.19.75.217
  • 206.72.242.124
  • 206.72.242.162

«Si se sospecha un compromiso, los operadores deben preservar los registros de acceso web de VCO, los registros de aplicaciones backend, los registros del sistema, los registros de bases de datos y las marcas de tiempo relevantes del sistema de archivos antes de realizar la reparación cuando sea operativamente factible», agregó.

Si la actualización inmediata a una versión fija de VCO no es una opción, se recomienda restringir el acceso a la interfaz web de VCO a redes administrativas confiables, monitorear el VCO para detectar acceso desde IP de fuentes maliciosas conocidas, verificar actividad de red saliente inesperada desde el host de VCO y revisar la actividad reciente del administrador para detectar cambios inesperados.

«Los compromisos con la plataforma VCO también pueden permitir a los atacantes acceder a los dispositivos VeloCloud Edge», dijo Arista. «Esto puede incluir rotación de credenciales, revisión de la actividad del administrador, validación del estado del dispositivo administrado y restauración o reemplazo de instancias de orquestador afectadas de fuentes confiables».

El desarrollo ha llevado a la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) a agregar la falla de sus vulnerabilidades explotadas conocidas (KEV), que exige que las agencias del Poder Ejecutivo Civil Federal (FCEB) apliquen el parche antes del 30 de julio de 2026.

Ciberseguridad

La noticia de la explotación activa de CVE-2026-16812 llega cuando la agencia también agregó una vulnerabilidad de seguridad de gravedad media que afecta a Fortinet FortiOS SSL-VPN (CVE-2025-68686, puntuación CVSS: 5.3) al catálogo KEV, citando evidencia de explotación activa. Fortinet solucionó el problema a principios de febrero.

«Una exposición de información sensible a una vulnerabilidad de actor no autorizado [CWE-200] En FortiOS SSL-VPN puede permitir que un atacante remoto no autenticado omita el parche desarrollado para el mecanismo de persistencia de enlaces simbólicos observado en algunos casos post-exploit, a través de solicitudes HTTP diseñadas», Fortinet dicho en una alerta en ese momento. «Un atacante primero tendría que haber comprometido el producto a través de otra vulnerabilidad, a nivel del sistema de archivos».

Actualmente no hay detalles sobre cómo se explota la vulnerabilidad en la naturaleza, la escala de los ataques y quién está detrás de ellos. Las agencias federales tienen tiempo hasta el 10 de agosto de 2026 para aplicar los parches.

Otra falla de seguridad que ha sido atacada es CVE-2026-16723 (puntaje CVSS: 9.0), un problema crítico en la biblioteca Fastjson de Alibaba que podría permitir la ejecución remota de código sin interacción del usuario ni privilegios elevados. La vulnerabilidad sigue sin parchearse. Se insta a los desarrolladores que utilizan las versiones 1.2.68 a 1.2.83 a habilitar SafeMode o cambiar a una versión no afectada lo antes posible.

Los atacantes utilizan los ejecutores de acciones de GitHub como armas para apuntar a los servidores cPanel y WHM – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han arrojar luz en una campaña a gran escala que se ha convertido repositorios de GitHub comprometidos en una infraestructura de ataque distribuida diseñada para atacar instancias de cPanel y WebHost Manager (WHM).

La actividad involucra versiones de desarrollo maliciosas de Packagist que abarcan 10 paquetes asociados con un desarrollador legítimo de PHP y DevOps, dinushchathurya, entre el 12 y el 13 de julio de 2026. La lista de paquetes de Packagist afectados se encuentra a continuación:

  • dinushchathurya/lista de nacionalidades
  • dinushchathurya/secretarías-divisionales-de-srilanca
  • dinushchathurya/divisiones-gn-de-srilanka
  • dinushchathurya/autoridades-locales-de-srilanca
  • dinushchathurya/validador-de-número-móvil-de-srilanca
  • dinushchathurya/hospitales-estatales-de-srilanca
  • dinushchathurya/universidades-de-srilanca
  • dinushchathurya/validador-de-número-móvil-del-reino Unido
  • dinushchathurya/código postal del Reino Unido
  • dinushchathurya/websmslk

«Las bibliotecas PHP no eran la ruta de ejecución», dijo Socket en un comunicado. «Los atacantes habían agregado docenas de flujos de trabajo maliciosos de GitHub Actions a los repositorios de origen del mantenedor comprometido».

Ciberseguridad

Los flujos de trabajo, una vez activados por una inserción del repositorio o una ejecución manual, inician ejecutores alojados en GitHub, descargan una carga útil de Linux desde la infraestructura controlada por el atacante y buscan servidores cPanel y WHM vulnerables susceptibles a CVE-2026-41940, una vulnerabilidad de omisión de autenticación que permite a atacantes remotos obtener un control elevado del panel de control.

La carga útil, por su parte, intenta omitir la autenticación y luego procede a recopilar credenciales, archivos de configuración, variables de entorno, acceso a bases de datos, material SSH, tokens Git, claves de nube, credenciales de servicios de pago y otros secretos valiosos.

Aún no está claro el método exacto por el cual el actor de amenazas obtuvo acceso no autorizado a la cuenta del desarrollador e impulsó cambios maliciosos en los repositorios.

«Entre el 12 y el 13 de julio de 2026, Packagist sincronizó automáticamente versiones de desarrollo maliciosas en los diez paquetes asociados con el desarrollador comprometido, lo que refleja los cambios que el actor de amenazas impulsó a los repositorios de GitHub del desarrollador», dijo el investigador de Socket Kirill Boychenko.

Se ha descubierto que cada una de las versiones de desarrollo afectadas contiene entre 55 y 62 archivos de flujo de trabajo maliciosos de GitHub Actions, con un total de 583 archivos en las diez versiones del paquete.

Específicamente, los archivos de automatización YAML inician ejecutores alojados en GitHub cuando el repositorio comprometido recibe un impulso o cuando el flujo de trabajo se inicia manualmente, detectan la arquitectura del procesador de cada ejecutor (por ejemplo, sistemas x86 de 32 bits, x86 de 64 bits, ARM de 32 bits y ARM de 64 bits) y descargan una carga útil de exploración y explotación de Linux compatible desde el servidor de comando y control (C2) en 43.228.157[.]68.

«Los flujos de trabajo informan continuamente el estado de ejecución al actor de la amenaza y cargan los resultados recién recopilados a través de solicitudes HTTP POST», añadió Boychenko. «Los archivos de salida que monitorean incluyen credenciales de AWS, tokens de GitHub y GitLab, credenciales de API de OpenAI y Google, claves de Stripe, credenciales de SendGrid y Mailgun, información de bases de datos, datos SSH, controles remotos de Git y resultados de ejecución remota de código».

A diferencia de otras campañas tradicionales de paquetes maliciosos, la actividad más reciente no depende de los sistemas de los usuarios del paquete. En cambio, el escaneo y la explotación se ejecutan en ejecutores alojados en GitHub lanzados desde repositorios comprometidos, lo que significa que se abusa de GitHub Actions para impulsar una campaña de explotación destinada a buscar servidores cPanel y WHM vulnerables.

Los signos apuntan a una campaña más amplia que se extiende más allá de un mantenedor de PHP, con aproximadamente 6.100 archivos de flujo de trabajo alojados en GitHub que contienen un identificador DNSHook único («f5b0b742-240a-4811-8a5b-b0ba6060685d»).

Socket describió la campaña como un caso de «operación oportunista de robo de credenciales del lado del servidor», que permite a los atacantes aprovechar los datos robados para posteriores compromisos o vías de monetización.

La divulgación se produce cuando la empresa de seguridad de aplicaciones también detalló una campaña con el nombre en código Operación Muck and Load que abusa de una red de 200 repositorios de GitHub en 190 cuentas para entregar malware basado en Windows, incluidos ladrones de información, cargadores y descargadores, droppers, spyware, troyanos de acceso remoto y mineros de criptomonedas Monero.

Ciberseguridad

Los repositorios, algunos de los cuales se hacen pasar por utilidades de desarrollador e integraciones de billeteras de criptomonedas, ocultan una cadena de ataque de varias etapas que descarga un script de PowerShell responsable de consultar varios sitios de entrega muerta como Pastebin, Rlim, Telegram, YouTube, Instagram, Google Docs y Gitcode para recuperar un archivo protegido con contraseña alojado en GitHub, desde el cual se extrae y lanza la carga útil principal.

«Los repositorios de GitHub en este grupo no eran sólo señuelos», dijo Boychenko. «Varios también funcionaron como repositorios de malware, incorporando cargas útiles maliciosas directamente en el árbol de origen o entregándolas a través de activos de lanzamiento de GitHub».

La actividad comparte superposiciones tácticas con la actividad previamente observada asociada con el «ischhfd83@rambler[.]ru», que ha sido rastreada bajo el nombre de Water Curse por Trend Micro. Se evalúa que el grupo de amenazas opera una red fantasma basada en GitHub para redirigir a los usuarios desprevenidos a páginas de GitHub que albergan cargas útiles con malware.

«Este modelo ofrece a los actores de amenazas una forma escalable de convertir el descubrimiento de software ordinario en una puesta en escena de malware, especialmente cuando los señuelos se dirigen a usuarios que ya están inclinados a ejecutar herramientas que no son de confianza, como la automatización de criptomonedas, utilidades de billetera, trampas de juegos, criptadores y herramientas ofensivas», dijo Socket.

Los atacantes de Qilin Ransomware aprovechan la omisión de autenticación de PAN-OS para el acceso inicial – CYBERDEFENSA.MX

Se ha observado que los actores de amenazas explotan una vulnerabilidad PAN-OS de alta gravedad de Palo Alto Networks, ahora parcheada, como punto de entrada para implementar el ransomware Qilin (también conocido como Agenda) en los entornos de las víctimas.

Arctic Wolf Labs dijo que investigó múltiples intrusiones en junio de 2026 que comenzaron con la explotación de CVE-2026-0257 (Puntuación CVSS: 7,8), una falla de omisión de autenticación que afecta los componentes del portal y la puerta de enlace del software PAN-OS.

La explotación exitosa de la falla permite a atacantes remotos no autenticados eludir la autenticación y establecer sesiones VPN sin credenciales válidas cuando las cookies de anulación de autenticación están habilitadas con configuraciones de certificado específicas.

Ciberseguridad

«El arte posterior a la explotación varió según las intrusiones, desde operaciones rápidas de solo cifrado hasta doble extorsión completa, lo que posiblemente sugiere que múltiples afiliados operan bajo el paraguas de ransomware como servicio (RaaS) de Qilin», dijo la compañía de ciberseguridad. dicho.

«Los atacantes demostraron patrones operativos consistentes a pesar de las variaciones en el oficio: organizar el ransomware en C:\PerfLogs\, usar PsExec para la ejecución lateral a través de recursos compartidos administrativos, implementar cargas útiles de ransomware protegidas con contraseña e implementar rutinas integrales de limpieza de registros».

Se ha descubierto que los actores de amenazas utilizan la falla como arma para obtener acceso autenticado a las redes de las víctimas estableciendo sesiones VPN SSL, seguido de intensificar sus ataques para facilitar la recolección de credenciales y el movimiento lateral a través de recursos compartidos administrativos de Windows a través de cuentas administrativas comprometidas.

La actividad también se caracteriza porque los atacantes toman medidas deliberadas para borrar los registros de eventos y deshabilitar la protección en tiempo real de Microsoft Defender antes de ejecutar la carga útil del ransomware para minimizar la probabilidad de detección y evitar dejar evidencia forense.

A pesar de las similitudes en las rutas de preparación del ransomware, la ejecución basada en PsExec y un patrón de persistencia inusual en el Registro de Windows (es decir, un asterisco seguido de seis caracteres alfabéticos en minúsculas aleatorios), los ataques posteriores variaron entre las víctimas.

Ciberseguridad

Esto iba desde cifrado en toda la empresa sin filtración de datos y reconocimiento extenso a través de herramientas de acceso remoto como AnyDesk, Ngrok o LogMeIn hasta robo de credenciales a gran escala e instancias de filtración de datos al servicio en la nube MEGA antes de la implementación de ransomware usando Rclone, Proton Drive y FileZilla.

«Esta variabilidad es consistente con los modelos RaaS, en los que múltiples afiliados pueden aprovechar la infraestructura de acceso inicial compartida y las herramientas de ransomware mientras aplican sus propias metodologías post-explotación preferidas», dijo Arctic Wolf.

El nuevo defecto central de WordPress wp2shell permite a atacantes no autenticados ejecutar código – CYBERDEFENSA.MX

Una solicitud HTTP anónima puede ejecutar código en un sitio de WordPress. El error está en el núcleo, por lo que se puede explotar una instalación simple sin complementos.

Todos los sitios 6.9 y 7.0 estuvieron dentro del alcance hasta el viernes, cuando WordPress envió 6.9.5 y 7.0.2 y habilitó lo que llama actualizaciones forzadas a través de su sistema de actualización automática.

Adam Kues de Assetnote, el brazo de gestión de superficies de ataque de Searchlight Cyber, encontró la falla y la informó a través de WordPress. programa hackerone. El escribirpublicado bajo el nombre wp2shelldice que el ataque «no tiene condiciones previas y puede ser explotado por un usuario anónimo».

La empresa está sentada en los detalles técnicos por ahora y ha presentado un inspector en wp2shell.com, para que los propietarios puedan probar su propia instancia.

WordPress lanzó 6.9.5 y 7.0.2 el 17 de julio de 2026, cerrando un RCE de autenticación previa en el núcleo que una solicitud anónima puede activar contra una instalación predeterminada sin complementos. Dos rangos se ven afectados:

  • 6.9.0 a 6.9.4, corregido en 6.9.5
  • 7.0.0 a 7.0.1, arreglado en 7.0.2

WordPress no ha dicho si el envío forzado llega a los sitios que desactivaron las actualizaciones automáticas. Verifique lo que realmente está ejecutando en lugar de asumir que aterrizó.

Ciberseguridad

7.1 beta2 incluye la misma solución. Los sitios que todavía están en 6.8 también tienen una actualización esperando, pero 6.8.6 es para el segundo error de inyección SQL en la misma ronda, informado por un equipo diferente.

La publicación de Searchlight estima que más de 500 millones de sitios web ejecutan WordPress. Esa cifra es la base instalada total, no la población vulnerable: el código defectuoso solo existe desde la versión 6.9 en adelante, y la 6.9 se envió el 2 de diciembre de 2025. Por lo tanto, cada sitio afectado ejecuta una versión de menos de ocho meses y ninguno de los avisos dice cuántos sitios cubre.

WordPress es más comunicativo sobre la clase de error que el investigador. Es publicación de lanzamiento describe el hallazgo de Kues como «una confusión de rutas por lotes de API REST y un problema de inyección de SQL que conduce a la ejecución remota de código». El lanzamiento cubre una falla crítica y otra de alta gravedad, y WordPress no dice cuál es cuál.

El página de versión enumera los tres archivos tocados por 7.0.2, cubriendo ambas correcciones: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php y /wp-includes/rest-api.php. El punto final por lotes no es nuevo. WordPress lo ha enviado desde 5.6 en noviembre de 2020 y documentó públicamente el formato de la solicitud desde entonces. Nada publicado hasta ahora explica qué cambió en 6.9 para abrirlo.

Ninguno de los avisos incluye un ID CVE ni una puntuación CVSS, y no había aparecido ningún registro CVE hasta el 18 de julio. Los escáneres e inventarios con clave CVE no marcarán este, y CISA necesita un CVE antes de poder agregar algo al catálogo KEV. En su lugar, realice un seguimiento por número de versión.

Si no puedes actualizar hoy

Todas las mitigaciones que ofrece Searchlight se reducen a mantener a las personas que llaman anónimas fuera del punto final por lotes. Tres opciones, todas ellas provisionales hasta que actualices, y todas ellas capaces de romper integraciones legítimas:

  • En un WAF, bloquee /wp-json/batch/v1 y rest_route=/batch/v1. La empresa es explícita en que ambos tienen que desaparecer, porque una regla que cubre solo la ruta /wp-json deja abierta la ruta de la cadena de consulta.
  • Deshabilitar la API REST de WPque elimina al por mayor el acceso REST no autenticado.
  • un corto complemento directo que publica y rechaza solicitudes anónimas /batch/v1 en rest_pre_dispatch.

No se ha reportado ningún intento de explotación hasta el 18 de julio. Sin CVE para etiquetar y sin firma pública que coincida, nadie está realmente mirando todavía.

Ciberseguridad

La explotación masiva de WordPress es ahora una industria. Antes de que su servidor se filtrara en junio, un solo fallo en el complemento de almacenamiento en caché llevó al equipo de WP-SHELLSTORM a más de 17.000 sitios, según su propio recuento. Ese error ya era público, ya estaba parcheado y solo funcionaba en una configuración no predeterminada.

Cuando Drupal parchó una inyección SQL anónima en su propio núcleo en mayo, Searchlight convirtió esa solución pública en una desmontaje el mismo día con dos pruebas de concepto funcionales. Eso fue error de otro y parche de otro, y nada obliga a la firma a hacer lo mismo con los suyos. Pero fue necesario un día, y las personas que pusieron en marcha ese reloj son las que ahora apuestan que el silencio les da tiempo a los defensores.

El núcleo de WordPress es de código abierto, y tanto 7.0.1 como 7.0.2 se encuentran en el archivo de lanzamiento públicopor lo que la comparativa está disponible para quien la desee. Ese es el problema de todo proyecto de código abierto: no se puede enviar la solución sin enviar el mapa del error, y la única palanca que queda es qué tan rápido el parche llega a los sitios antes de que alguien lo lea.

WordPress tiró de esa palanca el viernes. El tráfico contra el lote/v1 mostrará cuándo llegan los atacantes, y las estadísticas de la propia versión de WordPress mostrarán si el parche llegó primero. Sólo uno de esos números aparece en las noticias.

Una falla en la aspiradora Shark sin parches podría permitir a los atacantes controlar otras aspiradoras en toda la región – CYBERDEFENSA.MX

Retire el certificado del flash de un robot aspirador Shark RV2320EDUS y podrá ejecutar comandos raíz en los aspiradores Shark de otras personas en la misma región de AWS: mire la cámara, conduzca el robot, lea el mapa de la casa y tome la contraseña de Wi-Fi en texto plano.

Un investigador que publica bajo el nombre tokay0 poner el método en línea el lunes, después de haberlo probado sólo con aspiradoras que compró él mismo. El defecto no se solucionó entonces.

Dice que SharkNinja, la compañía detrás de las marcas de electrodomésticos Shark y Ninja, ha recibido su informe desde marzo.

La política adjunta a ese certificado nunca tuvo como alcance el dispositivo que lo posee. Preséntelo al corredor en la nube de Shark y el corredor aceptará todo lo que publique, dirigido a cualquier dispositivo al que sirva.

Sin corrupción de memoria, sin escalada de privilegios, sin contraseña que adivinar. El comando que se ejecuta es un campo normal en la sombra del dispositivo, el documento de estado por dispositivo que AWS mantiene en la nube.

Utilizando el certificado de un RV2320EDUS, el investigador se suscribió a $aws/things/# y observó el tráfico que cruzaba el corredor, recopilando números de serie a medida que avanzaba. La publicación funciona de la misma manera. La sombra lleva un campo Exec_Command que el demonio de administración appd lee y entrega a una función llamada ejecutar_command, que ejecuta cualquier cosa de menos de 1000 bytes a través de popen.

Envíe una actualización paralela que lleve ese campo al tema de un dispositivo. Si ese dispositivo implementa el controlador, ejecuta el comando.

Probó el camino entre modelos, colocando un proyectil inverso en un AV1102ARUS que compró simplemente como objetivo, y luego usó ese proyectil para obtener una transmisión en vivo de la cámara integrada del modelo mientras el robot conducía.

El certificado se quita con un destornillador. La placa base expone los pines UART, la consola U-Boot no solicita contraseña e init=/bin/sh en los argumentos de arranque lo lleva a un shell raíz, donde la clave por dispositivo y el certificado se encuentran en /mnt/res/vapp/certs/ como archivos normales.

Ciberseguridad

Los certificados están fijados a su región de AWS, lo más parecido aquí a un límite: una clave levantada en una región solo llega a los dispositivos de esa región. Para llegar a otra región se necesita otro certificado, aprovisionado allí, y que lleva la misma política rota.

Amazon tiene una verificación de auditoría para esta forma de política exacta. Device Defender, el servicio de auditoría de flotas de IoT de AWS, marca políticas de dispositivos que permiten publicar o suscribirse en $aws/things/* en lugar de fijar el tema al dispositivo que se conecta con ${iot:Connection.Thing.ThingName}.

Aparece como IOT_POLICY_OVERLY_PERMISSIVE_CHECK y AWS lo califica como crítico, advirtiendo en su documentacion que un certificado comprometido que lleva dicha política permite a un atacante «leer o modificar sombras, trabajos o ejecuciones de trabajos para todos sus dispositivos».

No todos los certificados son una clave maestra. Un vacío cuyo certificado lleva la política rota es la clave de un atacante. Cualquier vacío que ejecute Exec_Command es un objetivo, independientemente de si su propio certificado tiene el alcance correcto o no. El AV1102ARUS es un destino y no una clave: su certificado tenía el alcance correcto y no se pudo realizar una suscripción comodín. Su firmware era varios años más nuevo.

Él lo interpreta como una solución de aprovisionamiento que nunca alcanzó los certificados de la flota más antigua. Es por eso que el modelo cruzado funcionó, y por qué su afirmación de que cada aspiradora Shark conectada a Internet es vulnerable debe dividirse en dos.

El titular de su publicación dice millones. La cifra que verificó es más estrecha. Al observar una región de AWS durante 24 horas, tokay0 contó 1.517.605 números de serie únicos de Shark, de los cuales 673.816, o el 44%, emitieron un Exec_Response, que considera como una confirmación de que el dispositivo ejecuta el controlador de comandos. Se trata de dispositivos observados respondiendo, no dispositivos probados o comprometidos, y dice que el número real probablemente sea mayor.

Cuatro meses y contando

Según el relato de la correspondencia de tokay0, se comunicó con SharkNinja el 1 de marzo y envió detalles el 11 de marzo. La compañía acusó recibo al día siguiente, le dijo el 27 de abril que el informe estaba bajo revisión y el 3 de julio dijo que enviaría una fecha de finalización confirmada para el viernes 10 de julio. No llegó ningún correo electrónico.

Lo publicó el 13 de julio. Dice que el proveedor minimizó la gravedad y cuestionó si «un CVE es apropiado».

En lo que respecta específicamente a los informes de IoT, SharkNinja publicó política de divulgación de vulnerabilidades compromete a la empresa a «proporcionar actualizaciones periódicas hasta que se resuelva la vulnerabilidad informada». La misma política pide a los investigadores que permanezcan en silencio hasta que la empresa confirme una solución o autorice la divulgación por escrito.

SharkNinja no había publicado nada sobre el defecto hasta el jueves. The Hacker News se comunicó con la compañía para comentar sobre el estado del parche y el cronograma de divulgación, y actualizará esta historia con cualquier respuesta.

Ciberseguridad

Tampoco hay CVE. Le pidió una identificación al CNA de último recurso de MITRE, el asignador que maneja las vulnerabilidades que ningún proveedor cubre, el 11 de junio y no había escuchado nada cuando publicó. Sin identificador, sin CVSS, sin aviso: nada que un programa de gestión de vulnerabilidades pueda ingresar.

La solución está en el lado del servidor

La solución no la debe instalar el propietario. Vive en la cuenta AWS de SharkNinja, no en el firmware del robot. Según AWS guía de remediaciónuna política que no cumple se reemplaza al enviar una versión con alcance con CreatePolicyVersion y el indicador setAsDefault, lo que hace que esa versión sea operativa para todos los certificados que usan la política.

No se requiere implementación de firmware. Reemitir los certificados correctamente, algo que tokay0 recomendó en marzo, es el trabajo más largo que hay detrás.

Hasta que SharkNinja haga una u otra cosa, la única mitigación disponible para el propietario es desconectar la aspiradora del Wi-Fi. Esto pone fin al control de aplicaciones, la programación y los mapas, y convierte el producto nuevamente en un vacío.

tokay0 retuvo sus guiones mientras la falla esté activa. Consideró que sus otros hallazgos eran demasiado menores para escribirlos.

Tampoco examinó el resto de la línea conectada de SharkNinja, las parrillas inteligentes y las sondas inalámbricas para carne, que, según él, probablemente también sean vulnerables. Esos productos provienen de la misma empresa cuya política promete actualizaciones periódicas hasta que se resuelva una falla. Cuatro meses después, éste no lo es.

La falla en el intercambio de tokens n8n podría permitir a los atacantes iniciar sesión como usuarios de otro emisor – CYBERDEFENSA.MX

n8n, la plataforma de automatización del flujo de trabajo, entregó las cuentas equivocadas al iniciar sesión. En instancias empresariales configuradas para confiar en más de un emisor de token externo, hizo coincidir un JWT entrante con un usuario local en el sub reclamo solo e ignorado iss.

Un token válido del emisor A que lleva un sub que pertenece a alguien del emisor B, inició sesión como esa persona. Su contraseña nunca apareció. n8n envió la solución el 24 de junio.

El defecto se rastrea como CVE-2026-59208. El registro CVE no se hizo público hasta el 9 de julio. n8n acredita el informe a la cuenta de GitHub ososyankeescuyo perfil incluye a Strix, que fabrica un agente de pruebas de penetración de IA.

estrix dice Señaló que el agente en el flujo de intercambio de tokens encontró el error de vinculación de identidad allí.

Dos emisores, una cuenta

El intercambio de tokens es la ruta empresarial de n8n para Socios OEM que integran el productoun Implementación de RFC 8693 eso ahorra a sus usuarios una segunda pantalla de inicio de sesión.

El socio firma un JWT de corta duración con su propia clave, n8n lo verifica con una clave pública configurada, hace coincidir los reclamos con una cuenta local y el usuario está dentro. Las claves confiables entran N8N_TOKEN_EXCHANGE_TRUSTED_KEYSy el documentos de implementación aún etiquete la función como vista previa.

Ciberseguridad

El token en sí se verifica. La coincidencia es el error. A sub Solo se garantiza que el valor será único dentro del emisor que lo acuñó. RFC 7519 pide que «tenga un alcance para ser localmente único en el contexto del emisor» o globalmente único. El identificador de un usuario es, por tanto, el par, iss más sub.

n8n codificado en la mitad. Nada impide que dos emisores emitan la misma cadena de asunto y, cuando lo hacen, ambos aterrizan en una cuenta n8n.

¿Qué tan importante es esto?

La falla alcanza una instancia solo si el intercambio de tokens está activado y la configuración confía en al menos dos emisores externos. n8n dice nada más se ve afectado. El intercambio de tokens es solo empresarial y todavía está marcado como una vista previa, por lo que el conjunto expuesto es pequeño y específico: implementaciones OEM, donde confiar en un segundo emisor es una configuración admitida.

Lo que el aviso no especifica es cómo un atacante obtiene el token. Sólo dice que pueden obtener uno. La cuestión práctica es si un usuario normal de un emisor de confianza puede influir en la sub ellos reciben. El registro público no lo contesta. El vector CVSS 4.0 de GitHub marca los requisitos de ataque como presentes y se detiene allí.

GitHub asignó ese vector. Como aquí la CNA pone CVE-2026-59208 a 7.6 en CVSS 4.0, alto. NVD coloca el mismo error en 6.8 en CVSS 3.1, medio, y no ha emitido ninguna evaluación de 4.0; su registro lleva CWE-287 y CWE-346. La evaluación SSVC de CISA del 13 de julio registra ninguna explotación, y The Hacker News no encontró ninguna prueba pública de concepto en las búsquedas del 16 de julio.

Dos semanas antes de la corrección del 24 de junio, los mantenedores parchearon CVE-2026-54305otro defecto exclusivo de Enterprise. Permite que cualquier usuario autenticado sobrescriba o revoque los tokens OAuth almacenados de otro usuario a través de los puntos finales de Credenciales dinámicas. Ése era un control de propiedad faltante, no una vinculación de identidad. Bicho diferente, misma superficie.

Ciberseguridad

The Hacker News se ha puesto en contacto con n8n para obtener confirmación sobre el alcance y el impacto de CVE-2026-59208 y actualizará esta historia con cualquier respuesta.

Parchear o cortar la lista de emisores

CVE-2026-59208 afecta a todas las versiones de n8n inferiores a 2.27.4 y 2.28.0. La solución llegó por primera vez a 2.27.4 y 2.28.1. Esos son el piso. El 16 de julio, el paquete npm de n8n llevaba la versión 2.30.6 en ambos latest y stable etiquetas. Envía un nuevo menor la mayoría de las semanas por su propia cuenta, así que verifique la etiqueta y tome la versión estable más nueva que admita su implementación.

Si la aplicación de parches tiene que esperar, averigüe qué está ejecutando: N8N_TOKEN_EXCHANGE_TRUSTED_KEYS contiene las claves de firma confiables y un indicador de vista previa independiente controla si el intercambio de tokens está activado. Vuelva a centrarse en un único emisor de confianza o desactive la función.

El aviso llama a ambas medidas a corto plazo y dice que ninguna remedia completamente el riesgo. Esto es un texto repetitivo, idéntico en al menos otros tres avisos de n8n, incluido el del 10 de junio. Según la propia declaración de alcance de n8n, una instancia con intercambio de token desactivado no se ve afectada.

Ninguna nota de la versión menciona la solución. The Hacker News comprobó ambos: entre ellos, el 2.27.4 y 2.28.1 Los registros de cambios cubren una corrección de importación de Python, una actualización de un nodo de Google Ads, una verificación del flujo de trabajo de IA y un cambio en la creación de nodos, y nada sobre la identidad.

El aviso es donde éste vive. Si sus decisiones de actualización se basan en registros de cambios, este es el tipo de solución que pasa desapercibida.