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.

JFrog confirma que los modelos OpenAI explotaron el día cero artificial antes de abrazar la violación de la cara – CYBERDEFENSA.MX

JFrog ha confirmado que los modelos OpenAI explotaron un día cero en sistemas autohospedados. Artifactorio mientras intenta llegar a Internet abierto desde un entorno de evaluación sellado.

Artifactory es el administrador de repositorios de software de JFrog. OpenAI dice que los modelos luego aumentaron los privilegios y se movieron lateralmente hasta llegar a un nodo conectado a Internet. JFrog dice que desde entonces ha desarrollado y lanzado correcciones para clientes autohospedados y en la nube.

El exploit Artifactory ocurrió dentro del entorno de OpenAI. OpenAI dice que una ruta de ataque separada llegó más tarde a los sistemas de Hugging Face. JFrog afirma que sus clientes de la nube ya están protegidos. Los usuarios autohospedados deben revisar el Notas de la versión artificial y pasar a la compilación de reparación para su rama mantenida.

El 27 de julio se publicaron varios registros CVE de Artifactory con rangos de versiones afectadas y umbrales de versión fijos, pero ni JFrog ni OpenAI han dicho si alguno de esos registros corresponde a las vulnerabilidades utilizadas durante la evaluación.

Ciberseguridad

Al menos tres de esos registros, CVE-2026-65618, CVE-2026-65923 y CVE-2026-66018, dan crédito a los investigadores de OpenAI.

Los registros no asignan ningún CVE al incidente, no identifican el acceso requerido antes de la explotación ni explican por qué OpenAI se refiere a un proxy de día cero mientras que JFrog se refiere a múltiples vulnerabilidades.

El incidente comenzó como una de las pruebas de capacidad cibernética de OpenAI. OpenAI dijo La evaluación de ExploitGym se realizó sin los clasificadores de producción que normalmente bloquean la actividad cibernética de alto riesgo. GPT-5.6 Sol y un modelo de prelanzamiento más capaz también se ejecutaron con rechazos cibernéticos reducidos.

OpenAI dijo que la única ruta de red del entorno sellado era un proxy y caché de registro de paquetes alojado internamente, que JFrog identificó más tarde como Artifactorio. Los modelos utilizaron importantes recursos informáticos para buscar una salida.

OpenAI dice que los modelos aumentaron los privilegios y se movieron lateralmente hasta que alcanzaron un nodo con acceso abierto a Internet, luego infirieron que Hugging Face podría albergar modelos, conjuntos de datos o soluciones de ExploitGym. La compañía dijo que los modelos finalmente obtuvieron soluciones de prueba directamente de la base de datos de producción de Hugging Face.

En un ejemplo descrito por OpenAI, un modelo utilizó credenciales robadas y más días cero para encontrar una ruta de ejecución remota de código en los servidores de Hugging Face. Hugging Face reveló la intrusión el 16 de julio sin saber qué modelo estaba detrás.

Ni OpenAI ni Hugging Face explican cómo ese ejemplo de RCE se relaciona con la cuenta de acceso inicial de Hugging Face a través de la ejecución de un conjunto de datos malicioso.

Ciberseguridad

JFrog presentó su cuenta en un publicación de blog por el director de tecnología, Yoav Landman. La compañía dijo que el equipo de seguridad de OpenAI reveló los hallazgos, después de lo cual desarrolló, validó y publicó correcciones para implementaciones en la nube y autohospedadas. Landman enmarcó el episodio en torno a la velocidad de respuesta: un día cero encontrado por un modelo y dejado reposar durante semanas, escribió, es «un regalo para los atacantes».

JFrog no ha revelado el número exacto de vulnerabilidades de Artifactory utilizadas, los ID de CVE correspondientes, los permisos disponibles antes de la explotación o la versión de Artifactory que se ejecuta dentro de OpenAI. Tampoco ha dicho si alguna de las fallas fue explotada fuera de la evaluación controlada.

OpenAI calificó el episodio como un «incidente cibernético sin precedentes». Dijo que agregó Hugging Face a su programa de acceso confiable y que todavía está investigando junto con la compañía.

The Hacker News se comunicó con JFrog para obtener más detalles y actualizará esta historia si recibe una respuesta.

24.650 BMC expuestos a Internet divulgan hashes de contraseñas de IPMI antes de iniciar sesión – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han hecho sonar una alerta después de encontrar más de 36.000 interfaces de gestión de controladores de gestión de placa base (BMC) que exponen el protocolo de interfaz de gestión de plataforma inteligente (IPMI) a la Internet pública.

De las 36.872 interfaces de administración de servidores expuestas a Internet que ejecutan IPMI, se ha descubierto que 24.650 revelan hashes de autenticación derivados de contraseñas antes de iniciar sesión debido a una vulnerabilidad en la propia especificación IPMI v2.0, según un nuevo informe Lava compartió con The Hacker News. IPMI v2.0 fue introducido en febrero de 2024.

La cuestión en cuestión es CVE-2013-4786 (Puntuación CVSS: 7,5), una falla de divulgación de información de alta gravedad que permite a atacantes remotos obtener hashes de contraseñas para cuentas válidas y realizar ataques de adivinación de contraseñas fuera de línea obteniendo el HMAC de una respuesta de mensaje del Protocolo de intercambio de claves autenticado (RAKP) RMCP+ de un BMC.

por un consultivo publicado por Dell, «este es un problema inherente a la especificación IPMI v2.0», y el fabricante de PC señaló que no hay ningún parche.

«Más del 30% de los hashes devueltos estaban asociados con contraseñas que podían recuperarse utilizando listas de palabras comunes y formatos predecibles de pegatinas de chasis de fábrica», dijo el investigador de seguridad Michael Katchinskiy. «La exposición también afectó a los servidores modernos Supermicro y HPE operados por proveedores de GPU, incluidos los sistemas que todavía usaban contraseñas emitidas de fábrica».

Ciberseguridad

Los BMC son procesadores de administración especializados integrados en la placa base de un servidor que controlan la energía, el firmware, el acceso remoto a la consola, la instalación del sistema operativo y la recuperación del sistema. También actúan como un componente crucial para la automatización y el tiempo de actividad del centro de datos remoto para monitorear la telemetría del hardware y facilitar la implementación masiva de actualizaciones de firmware y configuraciones de BIOS.

Para conectar comandos remotos al hardware, el BMC normalmente se comunica mediante protocolos como IPMI y Redfish. Como lo destaca la empresa de seguridad de firmware Eclypsium en A finales de 2022 y principios de 2023, la posición privilegiada de la que disfrutan las BMC también puede convertirlas en objetivos de ataque ideales para los delincuentes que buscan obtener control remoto e implementar malware persistente.

Debido a que los BMC se ejecutan de forma completamente independiente del sistema operativo host, un mecanismo conocido como administración fuera de banda (OOB), un atacante que logra comprometer con éxito un BMC expuesto puede eludir los controles de seguridad tradicionales, sobrevivir a las reinstalaciones del sistema operativo y mantener el acceso.

«En los centros de datos de IA modernos, donde el mismo entorno básico a menudo alberga a múltiples inquilinos, un solo BMC expuesto puede potencialmente poner en riesgo las cargas de trabajo de varias organizaciones a través de una infraestructura compartida o movimiento lateral, lo que lo convierte en un importante punto ciego en la infraestructura que sustenta el auge de los centros de datos de IA», dijo la compañía israelí.

En el centro de la investigación se encuentra CVE-2013-4786, una debilidad de 20 años en IPMI 2.0, que un atacante puede aprovechar para recuperar contraseñas débiles, reutilizadas, configuradas de fábrica o formateadas de manera predecible.

«Durante el proceso de autenticación, el BMC puede devolver un mensaje de respuesta que contiene un código de autenticación HMAC-SHA1 calculado utilizando la contraseña de la cuenta y los valores de sesión conocidos por el solicitante», explicó Katchinskiy. «Una parte remota no autenticada que pueda alcanzar el puerto UDP 623 puede solicitar esta respuesta y probar las adivinanzas de contraseña fuera de línea. A diferencia de los repetidos intentos de inicio de sesión en línea, el proceso fuera de línea no requiere una nueva solicitud al BMC para cada candidato de contraseña».

Al 6 de mayo de 2026, una búsqueda en Internet pública de servicios IPMI expuestos en el puerto UDP 623 descubrió 36.872 hosts únicos, de los cuales más de 14.000 están ubicados en los EE. UU. Los sistemas restantes se concentran en Alemania, China, los Países Bajos y el Reino Unido.

Un análisis más detallado ha determinado que casi 25.000 expusieron materiales de autenticación derivados de contraseñas antes de iniciar sesión, lo que permitió descifrar credenciales fuera de línea. Quizás aún más preocupante es que un total de 6240 BMC devolvieron material de autenticación para un nombre de usuario vacío que coincidía con una contraseña candidata débil y otros 2340 BMC devolvieron datos de autenticación para una cuenta con nombre como ADMIN o root que coincidía con una contraseña de listas de palabras disponibles públicamente.

Ciberseguridad

En las pruebas realizadas por Lava, las contraseñas de fábrica de HPE iLO se pudieron recuperar en un minuto utilizando hardware GPU moderno, mientras que las contraseñas de fábrica de Supermicro se pudieron recuperar en aproximadamente una hora a pesar de ser asignado de forma única a cada servidor. En respuesta a los hallazgos, Supermicro dijo que evaluará posibles mejoras a la política de contraseña predeterminada para futuras revisiones de hardware.

«CVE-2013-4786 no es nuevo, pero el riesgo que lo rodea ha cambiado», dijo Lava. El craqueo de GPU ha hecho que la recuperación de contraseñas fuera de línea sea más rápida, mientras que la IA moderna y los entornos básicos han hecho que cada servidor expuesto sea más valioso.

Además de eso, ha surgido evidencia de que los actores de amenazas ya están apuntando a interfaces BMC expuestas a Internet, incluidos los operadores de ransomware que dejan una nota de extorsión en una página de inicio de sesión de HPE iLO 4. No está claro quién está detrás de la actividad. Dicho esto, los servidores HPE iLO han sido seleccionados ya en 2020 para implementar un rootkit llamado iLOBleed.

Para contrarrestar el riesgo, se recomienda bloquear el puerto UDP 623 en el borde de la red, rotar las contraseñas emitidas de fábrica durante el aprovisionamiento, deshabilitar opciones heredadas o débiles como IPMI 1.5, restringir el acceso de BMC a una red de administración privada dedicada y aplicar controles de acceso a la red para garantizar que solo los sistemas administrativos aprobados puedan acceder a las interfaces de BMC.

«Las organizaciones han pasado años fortaleciendo las cargas de trabajo y los sistemas operativos en la nube, pero muchas han pasado por alto la infraestructura que se encuentra debajo de ellos», dijo Yakir Kadkoda, CTO y cofundador de Lava, en un comunicado.

«Estos controladores de gestión contienen las claves de los servidores y centros de datos. Una vez comprometidos, los atacantes pueden operar por debajo de la visibilidad de casi cualquier herramienta de seguridad, mantener la persistencia incluso después de que se reconstruyan los sistemas y potencialmente profundizar en la infraestructura crítica. A medida que la infraestructura de IA se expande rápidamente, asegurar esta capa se ha vuelto mucho más urgente».

Claude AI acaba de descifrar un esquema de prueba poscuántico y encontró un ataque AES de 7 rondas más rápido – CYBERDEFENSA.MX

Antrópico dice Vista previa de Claude Mythos ayudó a obtener un ataque de recuperación de claves de extremo a extremo contra HAWK-256 y una aceleración de 200 a 800 veces para un ataque contra AES-128 de siete rondas.

El ataque HAWK explota una simetría no utilizada anteriormente en la red detrás del esquema de firma. La implementación lanzada de Anthropic ofrece un tiempo de ejecución esperado de un extremo a otro de aproximadamente tres horas y 42 minutos en un servidor de 96 núcleos. El resultado de AES elimina un paso de adivinación de 256 vías de un ataque de encuentro en el medio existente.

Anthropic dijo que ninguno de los resultados afecta los sistemas de producción. HAWK sigue siendo candidato en un proceso de estandarización poscuántica del Instituto Nacional de Estándares y Tecnología (NIST), y el código de recuperación público solo apunta al parámetro más pequeño HAWK-256.

El resultado del Estándar de cifrado avanzado (AES) se aplica a siete de las diez rondas de AES-128 y aún requiere una cantidad poco práctica de textos sin formato elegidos. La compañía dijo que, como resultado, no es necesario cambiar el software de producción.

antrópico publicó los hallazgos junto con dos artículos técnicos y artefactos de reproducibilidad. La compañía dijo que Mythos Preview realizó en gran medida la investigación por sí mismo, y que los humanos proporcionaron la dirección del proyecto, los recursos informáticos y la verificación exhaustiva.

Una simetría escondida en la red de HAWK

HAWK es el único esquema basado en celosía entre los nueve candidatos que el NIST avanzó a la tercera ronda de su proceso adicional de firma digital poscuántica en mayo de 2026. Sus conjuntos de parámetros de nivel de seguridad NIST son HAWK-512 y HAWK-1024; HAWK-256 es un parámetro de desafío proporcionado como un objetivo criptoanalítico.

La recuperación directa de claves HAWK es una instancia del módulo de búsqueda Lattice Isomorphism Problem (smLIP). Un atacante debe recuperar una transformación oculta entre dos redes.

A artículo de Daniël van Gent y Ludo Pulles demostró que un automorfismo no trivial, una simetría que preserva la red, reduciría la recuperación de la clave HAWK a encontrar un vector corto en una red de aproximadamente la mitad de la dimensión original.

Ese trabajo abrió la vía del ataque, pero los autores dijeron que no afectó a HAWK. Anthropic dice que Mythos Preview encontró el automorfismo adicional necesario para explotar el camino.

Ciberseguridad

El resultado Ataque HAWK-n construye lo que los investigadores llaman una red de cociclo τ a partir de la clave pública. Luego utiliza la reducción y el tamizado de la red para recuperar vectores cortos antes de reconstruir una base secreta que pueda firmar mensajes para la clave pública original.

antrópico implementación liberada verifica la clave recuperada firmando un mensaje y verificándolo con la implementación de referencia del NIST. No recupera la semilla de clave secreta original de 96 bytes. En cambio, produce una clave decodificada de 592 bytes que contiene material de firma funcionalmente equivalente.

El código publicado de Anthropic solo admite HAWK-256 y rechaza todas las entradas que no sean HAWK-256. El repositorio incluye dos claves públicas que Anthropic dice haber atacado con éxito. También admite la generación y prueba de claves HAWK-256 nuevas.

Anthropic estima que el factor de trabajo de recuperación clave esperado del HAWK-256 cae de 264 a 238. En un anuncio del foro NIST el mismo díadijo que la estimación del recuento de puertas cae de 2150 a 2108 para HAWK-512 y de 2288 a 2182 para HAWK-1024. Ambos parámetros más amplios siguen siendo poco prácticos de atacar.

A partir de esta revisión, el registro público no muestra si el NIST o los remitentes de HAWK cambiarán los parámetros del esquema, las afirmaciones de seguridad o la posición en el proceso de estandarización en respuesta a esas estimaciones más bajas, en todo caso.

El ataque sigue siendo exponencial. No es una ruptura de tiempo polinomial de HAWK, y Anthropic dijo que no se extiende a otros candidatos de firma del NIST ni a la criptografía reticular en general.

Anthropic dijo que Mythos Preview desarrolló y verificó el resultado durante aproximadamente 60 horas en un entorno de múltiples agentes. Un investigador humano proporcionó orientación ocasional sobre la gestión de proyectos, pero no era un especialista en criptografía reticular. La empresa estimó el coste de la interfaz de programación de aplicaciones (API) en unos 100.000 dólares.

Más rápido, pero aún poco práctico

El segundo resultado apunta al AES-128 reducido de diez rondas a siete. El estudio de cifrados de ronda reducida es una práctica criptoanalítica estándar porque mide cuánto margen de seguridad queda antes de que un ataque alcance su construcción completa.

El ataque supone que un adversario puede obtener alrededor de 2105 textos claros seleccionados cifrados bajo una clave fija desconocida. Ese requisito por sí solo lo sitúa muy lejos del uso en el mundo real.

Los ataques anteriores de encuentro en el medio intercambian memoria por cálculo almacenando estados de cifrado intermedios y haciendo coincidir cálculos realizados desde extremos opuestos del cifrado. Una etapa del ataque anterior requirió probar 256 valores posibles antes de buscar en la tabla.

Mythos desarrolló una huella digital invariante que los antrópicos llaman Puente de Möbius. Debido a que la huella digital no cambia en ese valor estimado, el ataque puede eliminar la enumeración de 256 vías. Después de tener en cuenta el costo de la transformación y otras optimizaciones, Anthropic estima que el ataque AES-128 de siete rondas es de 200 a 800 veces más rápido, dependiendo de cómo se mide el tiempo de ejecución.

el acompañante papel AES presenta la construcción matemática, mientras que la artefacto liberado proporciona código para cada experimento citado en el artículo.

El código de Anthropic realiza una recuperación completa de la clave de caja negra contra un cifrado más pequeño tipo AES con una clave de 24 bits. Para AES-128 real de siete rondas, mide las entradas de mesa individuales y los candidatos en línea. Implementaciones separadas de C, Python y Rust prueban las afirmaciones de los componentes, y Anthropic proyecta esas medidas para el ataque completo. No ejecuta la recuperación AES-128 completa de principio a fin.

El resultado práctico es más limitado de lo que podrían implicar los nombres HAWK y AES. La recuperación completa de HAWK tiene como objetivo HAWK-256, un parámetro de desafío en lugar de cualquiera de los conjuntos de parámetros de nivel de seguridad NIST. Para el AES-128 de siete rondas, Anthropic proyecta el costo completo del ataque a partir de las mediciones de los componentes, y el ataque sigue siendo inviable a una escala realista.

La compañía dijo que el modelo inicialmente se negó a participar, insistiendo en que era imposible mejorar AES. Anthropic publicó las contundentes indicaciones de seguimiento del investigador, con errores tipográficos y todo, que impulsaron al modelo a seguir buscando.

Ciberseguridad

Anthropic dijo que Mythos Preview encontró el puente Möbius después de unos tres días y varios cientos de millones de tokens de salida. Refinó el método durante los días siguientes y finalmente generó aproximadamente mil millones de tokens de salida.

El mayor costo fue humano. La ejecución del modelo costó aproximadamente 100.000 dólares en uso de API, pero los investigadores dedicaron varios cientos de horas a comprobar el método. Anthropic dijo que dos investigadores tardaron casi un mes en llegar a estar seguros de que era correcto. En opinión de Anthropic, la verificación era el cuello de botella visible.

Las revelaciones siguen a la publicación del 20 de julio de Banco de Criptoanálisisun punto de referencia de 191 tareas desarrollado por investigadores de ETH Zurich, Anthropic, la Universidad de Haifa, Technische Universität Berlin y la Universidad de Tel Aviv. Cinco modelos rompieron entre el 65% y el 86% de sus esquemas más fáciles de primer nivel y de seis a 12 esquemas completos en su segundo nivel.

Ese punto de referencia evaluó Mythos 5, que Anthropic describe como la última actualización de Mythos Preview. La divulgación de HAWK y AES nombra específicamente Mythos Preview.

A partir del 29 de julio de 2026, el NIST continuó incluyendo a HAWK como candidato de tercera ronda. El anuncio de Anthropic en el foro NIST agradeció al equipo HAWK por ayudar a verificar el resultado y brindar comentarios, pero no dijo si eso implicó revisar la prueba, ejecutar el artefacto público o ambas cosas.

El hilo público no contenía respuestas cuando se revisó, y The Hacker News no localizó una reproducción independiente de la recuperación HAWK-256 de Anthropic durante esta revisión.

Tengu Botnet reinicia dispositivos Linux comprometidos cuando los defensores interrumpen su proceso – CYBERDEFENSA.MX

Una nueva botnet derivada de Mirai llamada Tengu puede utilizar el dispositivo de vigilancia de hardware de un dispositivo Linux comprometido para activar un reinicio cuando los defensores finalizan su proceso principal.

Si eso sucede, los otros mecanismos de persistencia de Tengu tendrán otra oportunidad de relanzarlo. Nozomi Networks Labs observó que el gotero llegaba a sus honeypots a través de la fuerza bruta de la credencial Telnet.

Tengu admite 25 métodos distribuidos de denegación de servicio (DDoS). También puede ejecutar un proxy SOCKS5, ejecutar comandos de shell y recopilar datos del sistema y de la red. El malware puede actualizarse y recuperar cargas útiles adicionales de formato ejecutable y vinculable (ELF) o paquete de Android (APK).

Nozomi enumeró ejemplos de arquitectura específica para i386, amd64, MIPS, ARM, PowerPC y m68k. El informe no identifica ningún proveedor o modelo de dispositivo específico. Tampoco nombra ningún operador, recuento de infecciones ni víctimas de DDoS del mundo real. Muestra lo que Tengu puede hacer, no hasta dónde se ha extendido.

Los defensores deberían comenzar eliminando la exposición a Internet de Telnet y otros servicios administrativos innecesarios y reemplazando las credenciales predeterminadas. Nozomi también recomienda actualizar el firmware, segmentar las redes de Internet de las cosas (IoT) y revisar los servicios systemd, los scripts de inicio, los archivos de inicio del shell y las rutas relacionadas con cron antes de devolver al servicio un dispositivo sospechoso.

Ciberseguridad

Laboratorios de redes Nozomi publicó su análisis el 27 de julio de 2026. Nozomi dijo que la persistencia y el código de autodefensa de Tengu lo hicieron destacar entre las muestras derivadas de Mirai que rastrea. «La mayoría de las variantes de Mirai implementan pocas o ninguna de estas capacidades de autodefensa», dijeron los investigadores.

Una vez en ejecución, el bot bifurca un guardián independiente que verifica el proceso principal de malware cada 60 segundos y reinicia el binario instalado si se detiene. También puede crear un servicio systemd falso, agregar scripts init y RC, alterar los archivos de inicio del shell y marcar su binario instalado como inmutable. Hay una rutina de persistencia basada en cron, pero Nozomi dijo que su referencia a /proc/self/exe parece inacabada o rota.

Un segundo mecanismo abusa del mecanismo de vigilancia del hardware del dispositivo. Un trabajador de fondo se hace pasar por [kworker/0:0]vuelve a abrir el dispositivo de vigilancia si está disponible, lo activa con un tiempo de espera de aproximadamente 30 segundos y envía señales de mantenimiento de actividad solo mientras el proceso principal de malware permanece activo. Finalice el proceso y el perro guardián dejará de recibir alimentación, lo que permitirá que el dispositivo se reinicie. Los otros mecanismos de persistencia de Tengu pueden entonces intentar relanzarlo.

Tengu también incluye una lista codificada de utilidades de reinicio y apagado. Sobrescribe sus encabezados ELF con la cadena ELFOOD, lo que puede interferir con los comandos normales que los defensores pueden usar para reiniciar o apagar de forma segura un dispositivo comprometido.

La muestra analizada se configuró para comunicarse con un servidor de comando y control (C2) en 64[.]89.163.8 a través del puerto TCP 9931. El registro, el tráfico de latidos y la salida de comandos se envían en texto sin formato, mientras que los comandos y actualizaciones del servidor utilizan un esquema de cifrado autenticado personalizado similar a ChaCha20/Poly1305.

Tengu también puede obtener un identificador de contenido proporcionado por C2 desde una puerta de enlace del Sistema de archivos interplanetario (IPFS) en el mismo servidor, validar el resultado como ELF o APK y ejecutarlo o instalarlo.

Nozomi evaluó que la ruta APK probablemente apunta a dispositivos mal protegidos Cajas de TV con Android o dispositivos similares, pero no documentaron víctimas confirmadas de Android.

Ciberseguridad

URLhaus grabado de forma independiente 17 URL de malware en 64[.]89.163.8 a partir del 17 de junio de 2026. Los registros incluían un script de shell, varios archivos ELF etiquetados como Mirai y un APK. Las entradas de carga útil más recientes de URLhaus se vieron por primera vez el 7 de julio y las 17 URL estaban fuera de línea el 28 de julio.

URLhaus no identifica los archivos como Tengu. Hasta el 28 de julio, ninguno de los hashes SHA-256 enumerados en su registro de host coincidía con el hash de muestra publicado por Nozomi. Por lo tanto, su telemetría solo confirma alojamiento malicioso relacionado con Mirai en la dirección.

The Hacker News se comunicó con Nozomi Networks para obtener detalles adicionales sobre la escala observada de Tengu, el estado de la infraestructura y el enlace de la muestra, y actualizará la historia con cualquier respuesta.

Ni Nozomi ni URLhaus establecen si se podía acceder al servicio C2 en el puerto 9931 o a la puerta de enlace IPFS en el puerto 8080. El estado de URLhaus se aplica únicamente a las URL de descarga enumeradas. Nozomi tampoco dice si el servidor C2 configurado en 64[.]89.163.8:9931 emitió algún comando.

Nimbus Manticore implementa NightLedger y convierte los sistemas de víctimas en retransmisiones encubiertas – CYBERDEFENSA.MX

El grupo de piratería respaldado por el estado iraní rastreado como Mantícora Nimbus (también conocido como GalaxyGato, Mirage Kitten, Smoke Sandstorm, Subtle Snail y UNC1549) se ha atribuido a un nuevo conjunto de ataques dirigidos a entidades de todo Oriente Medio, África y el sur de Asia.

Las intrusiones implican el uso de una puerta trasera de Windows no documentada anteriormente llamada NightLedger y dos túneles WebSocket personalizados, BridgeHead y ArcBridge, con el objetivo de mantener el acceso encubierto.

Los objetivos de la campaña incluyen Egipto, PYMES y entornos gubernamentales en Jordania y Tanzania, organizaciones de aviación en Pakistán, empresas de telecomunicaciones en Etiopía y entidades del sector financiero en Burkina Faso, según Kaspersky.

«El conjunto de herramientas incluye NightLedger, una nueva puerta trasera de Windows para reconocimiento, ejecución de comandos, operaciones de archivos, descubrimiento de procesos y captura de pantalla; y dos túneles personalizados basados ​​en WebSocket, ArcBridge y BridgeHead, para acceso encubierto a la red y túneles controlados por operadores», dijeron los investigadores de Kaspersky Omar Amin y Vasily Berdnikov. dicho.

Actualmente se desconoce el método exacto de acceso inicial utilizado en los ataques, aunque se sabe que el adversario emplea señuelos de phishing altamente personalizados con temas de oportunidades laborales disfrazados de marcas confiables y plataformas de contratación, así como páginas de videoconferencia similares, para redirigir a los destinatarios a archivos maliciosos alojados en servicios de intercambio de archivos de terceros.

Ciberseguridad

Luego se abusa de la ruta de acceso aún indeterminada para entregar cargas útiles maliciosas, incluido NightLedger, que se inicia como una DLL a través de la carga lateral de DLL. El malware está diseñado para contactar a un servidor externo a través de HTTPS para analizar y ejecutar comandos de una manera análoga a TWOSTROKE, otra puerta trasera implementada por el actor de amenazas en el pasado. La lista de comandos admitidos se encuentra a continuación:

  • Recopilar información de identidad del usuario y del host
  • Ejecutar un proceso/programa
  • Listar directorios
  • Descargar un archivo al sistema infectado
  • Recopilar información del host y de la red.
  • Copiar o eliminar archivos
  • Actualizar intervalo de baliza
  • Tomar una captura de pantalla
  • Cargar una DLL
  • Terminar un proceso o hilo
  • Cargue el archivo al servidor de comando y control (C2) mediante una solicitud HTTP POST
  • Enumerar unidades lógicas
  • Listar procesos
  • Recopile C:\Windows\debug\NetSetup.log (un archivo de diagnóstico utilizado para solucionar problemas de unión a dominios) junto con la salida de la lista de procesos.

Otras dos familias de malware entregadas como parte de los ataques son BridgeHead («unbcl.dll»), un proxy de túnel SOCKS5 observado en entornos de Egipto y Pakistán que comparte cierto nivel de superposiciones funcionales con MiniFast (también conocido como MiniUpdate y Retrograde) y ArcBridge, otra herramienta de túnel WebSocket observada en abril de 2026 en actividad dirigida a víctimas en el Medio Oriente.

«El servidor C2 inicia todas las conexiones del túnel enviando comandos binarios a través del WebSocket; el implante simplemente reenvía el tráfico entre los objetivos especificados por el servidor y el canal WebSocket», dijeron los investigadores sobre BridgeHead. «Esto lo convierte en un nodo de retransmisión: el operador ejecuta herramientas en el lado del servidor y todo el tráfico TCP resultante se canaliza a través de la máquina de la víctima como si se originara en la red de la víctima».

Ciberseguridad

El uso de BridgeHead y ArcBridge indica el uso continuo de utilidades de túneles por parte del actor de amenazas, lo que se ha observado anteriormente basándose en túneles personalizados como LIGHTRAIL y POLLBLEND.

La divulgación se produce días después de que Group-IB descubriera una nueva muestra de malware con nombre en código HOLLOWGRAPH que está vinculado al marco Cavern (también conocido como Cav3rn) utilizado por un equipo de piratería iraní denominado Cavern Manticore.

«HOLLOWGRAPH abusa de la API de Microsoft Graph para transformar un calendario de Microsoft 365 comprometido en un canal encubierto de comando y control bidireccional», decía.

«Utilizando la API Microsoft Graph, trata el calendario del buzón comprometido como un punto muerto de dos vías: los operadores colocan las tareas como eventos del calendario y el implante extrae archivos robados creando sus propios eventos con datos cifrados adjuntos. Para evitar captar la atención del propietario del buzón, cada evento tiene una fecha muy lejana en el futuro (13 de mayo de 2050) con cargas útiles adjuntas como archivos al evento».

Un investigador dice que la IA ayudó a desarrollar la carrera de control del tráfico de Linux hacia el exploit de raíz – CYBERDEFENSA.MX

STAR Labs ha publicado un exploit del kernel de Linux que convierte a un usuario local normal en root en la compilación CentOS Stream 9 a la que apunta. El defecto, rastreado como CVE-2026-53264 (Puntuación CVSS: 7,8), es una carrera de uso después de liberación en el subsistema de control de tráfico de red del kernel.

El investigador Lee Jia Jie dijo que la inteligencia artificial (IA) lo ayudó a encontrar el error y acelerar el desarrollo del exploit. Se trata de una escalada de privilegios local, no de una ejecución remota de código, por lo que un atacante necesita un punto de apoyo en la máquina antes de que se aplique algo de esto.

El exploit demostrado también requiere espacios de nombres de usuario sin privilegios, el CONFIG_NET_ACT_GACT y CONFIG_NET_CLS_FLOWER opciones del kernel y una cadena de programación orientada al retorno (ROP) específica del kernel que contiene compensaciones codificadas. Esas condiciones reducen la exposición inmediata, pero el código fuente de explotación total ahora es público.

La solución ascendente llegó el 1 de junio de 2026 y desde entonces ha sido compatible con varias ramas estables del kernel. El Registro CNA de Linux enumera rangos vulnerables que comienzan con Linux 4.14. Las versiones corregidas son 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.94, 6.18.36 y 7.0.13, y la corrección principal ingresa a 7.1-rc7.

Los usuarios de Linux deben instalar un kernel de distribución que contenga la solución en lugar de depender únicamente del número de versión ascendente. The Hacker News no encontró ninguna entrada para la falla en Catálogo de vulnerabilidades explotadas conocidas de CISA y no hay informe oficial de explotación en la naturaleza al 28 de julio de 2026.

Ciberseguridad

Lee dijo en un redacción técnica que la IA ayudó con el descubrimiento de vulnerabilidades, la producción de una prueba de concepto de Kernel Address Sanitizer (KASAN) y la optimización de la ventana de carrera. STAR Labs también lanzó el Código de explotación dirigido a CentOS.

Sin el modelo, indicaciones, servicio o registro de interacción, la divulgación es difícil de utilizar como base. punto de referencia de la capacidad de la IA o separar la contribución del sistema de la dirección y el juicio de Lee.

Hacker News solicitó a STAR Labs detalles sobre el sistema de inteligencia artificial, el entorno de prueba y el cronograma de divulgación y actualizará esta historia con cualquier respuesta.

«La IA todavía tiene muchos puntos ciegos y fallos en la capacidad de razonamiento», dijo Lee, añadiendo que el juicio humano siguió siendo necesario durante todo el trabajo.

La vulnerabilidad se encuentra en el manejo del ciclo de vida de las acciones de control de tráfico de Linux. Concurrente RTM_NEWTFILTER y RTM_DELTFILTER Las operaciones pueden dejar un hilo leyendo un objeto de acción después de que otro hilo lo haya liberado. El parche ascendente soluciona la carrera posponiendo la operación gratuita hasta que los lectores de lectura, copia y actualización (RCU) existentes hayan finalizado.

El exploit crea sus propios espacios de nombres de usuario y de red, dándole un espacio de nombres local. CAP_NET_ADMIN sin requerir derechos de administrador de host. Llega al camino vulnerable a través de un clsact qdisco y flower filtrar. Las operaciones Timerfd y epoll amplían la ventana de carrera, mientras que las asignaciones clave de carga útil recuperan el objeto liberado. La cadena ROP luego sobrescribe core_pattern.

El exploit coloca una copia de sí mismo en un memfd y bloquea deliberadamente un proceso hijo, lo que hace que Linux ejecute el binario respaldado por memfd como controlador raíz de volcado de núcleo en el espacio de nombres inicial.

Lee informó que el exploit tuvo éxito en sus 10 ejecuciones de prueba, tardando entre nueve y 111 segundos en una computadora portátil con CentOS Stream 9. Esas cifras de confiabilidad no se han reproducido de forma independiente. Las compensaciones fijas del dispositivo del exploit también significan que se debe reconstruir para otros paquetes del kernel y es posible que no se pueda adaptar a algunas compilaciones más nuevas.

El riesgo práctico es menor de lo que podría sugerir una etiqueta genérica de «explotación de raíz de Linux», pero el código de explotación público plantea la urgencia de que los sistemas compatibles permanezcan sin parches.

Ciberseguridad

Los créditos del parche ascendente Kyle Zeng, que usa el mango KyleBotcomo el reportero. Lee dijo que encontró la falla de forma independiente y solo más tarde se enteró de que Zeng la había informado poco antes de la competencia TyphoonPwn 2026. Lee publicó el análisis técnico posterior y el código de explotación.

El estado de distribución se mantuvo desigual al 28 de julio: Debian enumera los núcleos fijos para las versiones estables compatibles, ubuntu todavía marca múltiples paquetes de kernel mantenidos como vulnerables, y SUSE enumera el problema como pendiente en varios productos. SUSE asigna por separado a la falla una puntuación de 5,5, utilizando un vector que registra sólo el impacto en la disponibilidad, por debajo de la evaluación de 7,8 de Linux CNA.

Esos rastreadores muestran el estado del paquete, no cuántos sistemas implementados tienen los espacios de nombres requeridos, las opciones del kernel y una compilación del kernel compatible. Las fuentes públicas revisadas no establecen la población en riesgo inmediato.

Lee escribió que el proceso con mucha IA hizo que la búsqueda de errores «pareciera más como si estuviera haciendo un análisis de n días incluso en errores nuevos».

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.

Microsoft dice que el nuevo modelo de IA de ciberseguridad ayuda a MDASH a alcanzar el 95,95% a la mitad del costo – CYBERDEFENSA.MX

Microsoft ha lanzado su primer modelo específico de ciberseguridad en su interior MDASHsu arnés de identificación y remediación de vulnerabilidades multimodelo.

La compañía dice que MDASH, utilizando MAI-Cyber-1-Flash y GPT-5.4, obtuvo una puntuación del 95,95% en CyberGym. También afirma que la configuración cuesta un 50% menos que su mejor combinación MDASH actual de GPT-5.4, GPT-5.4 mini y GPT-5.3 Codex. El acceso está limitado a clientes MDASH aprobados a través de una versión preliminar privada de Azure AI Foundry.

MAI-Cyber-1-Flash está diseñado para manejar hasta el 90% de las tareas MDASH, con GPT-5.4 reservado para el 10% más difícil. Está disponible solo dentro de MDASH, no como un modelo público independiente o una interfaz de programación de aplicaciones de propósito general.

La puntuación principal pertenece a MDASH que ejecuta MAI-Cyber-1-Flash junto con GPT-5.4, no al nuevo modelo en sí. CyberGym Nivel 1 es una prueba de reproducción de vulnerabilidad conocida. Le da al agente una descripción de la vulnerabilidad y el código fuente correspondiente sin parches, luego verifica si puede producir una prueba de concepto funcional. No mide el descubrimiento ciego de vulnerabilidades ni si un parche generado es correcto.

CyberGym’s tabla de clasificación pública no incluyó el resultado del 95,95% de Microsoft cuando se verificó el 28 de julio de 2026. Aún incluyó la presentación MDASH de Microsoft del 12 de mayo con un 88,4%. Los materiales públicos de Microsoft no dicen si el resultado se envió para su inclusión en la lista.

Ciberseguridad

El resultado anterior de Microsoft de 96,55% MDASH no resuelve la comparación. Esa cifra de junio contó cualquier falla, incluidas las vulnerabilidades no objetivo. Los materiales de julio no dicen si el resultado del 95,95% utiliza el mismo criterio, por lo que los dos puntajes no pueden leerse con seguridad como una tendencia de desempeño de antes y después.

Según Microsoft tarjeta modeloMAI-Cyber-1-Flash es un transformador de escasa mezcla de expertos con 137 mil millones de parámetros totales, cinco mil millones de parámetros activos y una ventana de contexto de 256 000 tokens. Es un ajuste fino de ciberseguridad de MAI-Código-1-Flashque se desarrolló a partir de un punto de control de mitad de entrenamiento de MAI-Thinking-1.

La tarjeta modelo dice que la configuración evaluada reemplazó el 80% de los modelos existentes de MDASH y elevó el resultado informado de CyberGym del 88,4% al 95,95%. Esa cifra del 80% es la proporción de modelos reemplazados. La cifra separada del 90% es la proporción máxima de tareas que Microsoft dice que puede realizar el modelo más pequeño.

En conjunto, el diseño revelado apunta al enrutamiento como la afirmación técnica central: MAI-Cyber-1-Flash está diseñado para manejar la mayoría de las tareas, GPT-5.4 se encarga del resto más difícil y Microsoft informa el resultado a nivel del sistema MDASH.

Microsoft anuncio de lanzamiento define el ahorro del 50% en comparación con su mejor combinación actual de modelos MDASH de GPT-5.4, GPT-5.4 mini y GPT-5.3 Codex. La página del producto describe por separado que el sistema ofrece «rendimiento comparable al 50% del costo de los modelos líderes». El anuncio y la tarjeta modelo no revelan el uso del token, el volumen de llamadas, la latencia, la combinación de tareas o la asignación de cómputo detrás de esa comparación, por lo que la cifra aún no se puede reproducir ni normalizar de forma independiente con respecto a otros sistemas.

«El modelo es un insumo, el sistema que lo rodea es el producto».

Ciberseguridad

Taesoo Kim, vicepresidente de seguridad agente de Microsoft, utilizó esa distinción cuando describiendo MDASH en junio. Bajo un arnés de terminal liviano, la tarjeta modelo reporta puntuaciones de 0,314 en CVEBench, 0,553 en inteligencia de amenazas CyberSecEval4, 0,33 en su prueba de análisis de malware y 0,651 en CRSBench con POV=1200.

El modelo obtuvo una puntuación de cero en las categorías de kernel, espacio de usuario y navegador de ExplotarGymque solicita a los agentes que conviertan las vulnerabilidades proporcionadas y las entradas de fallas en exploits de ejecución de código que funcionen. Esos resultados provienen de diferentes tareas y escalas de puntuación, por lo que ninguna es una puntuación CyberGym independiente para MAI-Cyber-1-Flash.

Microsoft dijo que todas las pruebas de referencia se llevaron a cabo en un entorno de red aislado sin acceso a los sistemas de producción, a la Internet pública ni a servicios externos. La tarjeta modelo también advierte que el texto y el código generados pueden ser inexactos o estar incompletos y deben revisarse antes de cualquier uso posterior.

La gestión de vulnerabilidades de software utilizando MAI-Cyber-1-Flash dentro de MDASH es el primer escenario que Microsoft ha anunciado para Project Perception, su sistema más amplio para coordinar agentes de seguridad defensiva. Percepción del proyecto está programado para entrar en versión preliminar pública el 3 de agosto, y Microsoft planea extender el modelo más allá del trabajo de vulnerabilidad de software a flujos de trabajo de seguridad adicionales.