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.

Exploit público lanzado para falla de ejecución del código de autenticación previa de vBulletin parcheado – CYBERDEFENSA.MX

Los detalles públicos del exploit publicados el 27 de julio muestran cómo una solicitud no autenticada puede llegar a PHP eval() funcionar dentro vBoletín y ejecutar código en un servidor de foro sin parches. El ataque no requiere cuenta, acceso administrativo ni interacción de otro usuario.

SSD Secure Disclosure enumera vBulletin 6.2.1 y anteriores, y 6.1.6 y anteriores, como afectados, pero no proporciona un límite de versión inferior. vBoletín publicado parches de seguridad para 6.2.1, 6.2.0 y 6.1.6 a finales de junio y lanzó la versión corregida 6.2.2 el 1 de julio, casi cuatro semanas antes de que el exploit se hiciera público.

Los administradores que ejecutan instalaciones autohospedadas deben aplicar el parche para su rama o actualizar a 6.2.2. vBulletin dice que sus sitios en la nube ya han sido parcheados contra la falla.

SSD no informó explotación activa. Al 27 de julio de 2026, ninguna fuente había confirmado ataques en estado salvaje y CVE-2026-61511 no figuraba en el catálogo de vulnerabilidades explotadas conocidas de CISA. La compañía publicó una prueba de concepto interactiva, pero el script publicado contiene un error de un carácter, una letra donde pertenece un dígito, que impide que se ejecute sin cambios.

Ciberseguridad

El error es trivial de corregir y no afecta la vulnerabilidad subyacente. Una cosa que el registro público no aclara es si la falla se utilizó en las aproximadamente cuatro semanas entre el parche de finales de junio y la divulgación del 27 de julio; ni el aviso de SSD ni los avisos de vBulletin abordan esa ventana.

Análisis técnico de SSD lo identifica como CVE-2026-61511una falla de ejecución remota de código no autenticado en el motor de plantillas de vBulletin. Al momento de escribir este artículo, no había ningún registro de CVE.org o de la base de datos nacional de vulnerabilidades, por lo que no había ninguna puntuación de gravedad oficial disponible; El NVD dejó de enriquecer rutinariamente nuevos CVE con puntuaciones CVSS a principios de este año.

SSD le da crédito a un investigador independiente anónimo, aunque el exploit publicado está firmado como «EgiX», el nombre de Egidio Romano, quien reveló la cadena de ejecución de código del motor de plantilla 2025 de vBulletin.

El código vulnerable se encuentra en /includes/vb5/template/runtime.phpdentro del vB5_Template_Runtime::runMaths() método, que maneja matemáticas en línea en plantillas. La función elimina los caracteres fuera de un conjunto restringido y luego pasa lo que queda directamente a eval(). El filtro bloquea letras pero permite dígitos, paréntesis, concatenación, operadores aritméticos y operadores binarios como XOR, suficientes para reconstruir cadenas PHP y nombres de funciones invocables sin letras, utilizando una técnica de caracteres restringidos que el aviso llama «phpfuck».

Para llegar a él no es necesario el panel de administración. vBulletin genera plantillas a través de una ruta pública, ajax/render/pagenavy la acción pagenav La plantilla copia una información proporcionada por el visitante. pagenav[pagenumber] valor en un {vb:math} etiqueta, que se la pasa a runMaths().

Esa cadena es lo que convierte un error de plantilla en una ejecución remota de código de autenticación previa; PoC de SSD lo usa para reconstruir PHP system funciona y ejecuta un comando del sistema operativo, devolviendo el resultado en la respuesta HTTP.

Hacker News reprodujo localmente la lógica de filtrado y evaluación revelada para comprobar el error informado. Con el error tipográfico corregido, un inofensivo strlen() carga útil de prueba ejecutada; sin él, la lista de permitidos eliminó la letra perdida y dejó PHP sintácticamente inválido. La prueba confirmó la falla de creación de expresiones, no un ataque completo contra un servidor vBulletin en vivo.

Ciberseguridad

El propio banner del exploit llama al problema un día cero, pero los parches del proveedor y la versión 6.2.2 precedieron la divulgación pública por casi cuatro semanas. El código de explotación es nuevo; el defecto al que apunta ya estaba solucionado. Con Cloud supuestamente parcheado y las correcciones autohospedadas hace casi un mes, el riesgo real se concentra en foros autohospedados en Internet que no se han actualizado, una población más específica de lo que implica un simple «vBulletin RCE».

Los defensores pueden revisar las solicitudes POST que llevan routestring=ajax/render/pagenav con inusualmente largo o con mucho operador pagenav[pagenumber] valores, un patrón derivado de la PoC pública en lugar de la guía de detección del proveedor.

Este es el mismo rincón de vBulletin que anteriormente produjo la ejecución del código de autenticación previa. La cadena de mayo de 2025, CVE-2025-48827 y CVE-2025-48828abusó del motor de plantillas a través de una ruta diferente y provocó intentos de explotación a los pocos días de la divulgación, después de que el proveedor lo parcheara silenciosamente meses antes y muchos foros nunca aplicaron la solución.

Cada ronda ha transcurrido de la misma manera. Primero se publica una solución silenciosa, semanas después aparece un exploit funcional y, para entonces, muchos foros de Internet todavía ejecutan las versiones vulnerables.

La falla de ChatGPT AgentForger podría implementar agentes de espacio de trabajo no autorizados a través de un enlace de phishing

Investigadores de ciberseguridad han revelado una vulnerabilidad crítica en los agentes del espacio de trabajo ChatGPT de OpenAI que podría haber permitido que un único enlace de phishing construyera, autorizara y desplegara sigilosamente un agente autónomo de inteligencia artificial (IA) dentro de la organización de una víctima.

La vulnerabilidad ha sido nombrada en código. AgenteForger por Laboratorios Zenity. Desde entonces, OpenAI abordó el problema a partir del 8 de junio de 2026, luego de una divulgación responsable.

«Un solo enlace podría secuestrar el ChatGPT Agent Builder de OpenAI para crear un agente de IA controlado por un atacante con acceso de empleado real y sus aprobaciones desactivadas», la compañía de seguridad de IA dicho en un informe de dos partes compartido con The Hacker News.

El ataque ocurre cuando un empleado desprevenido hace clic para abrir un enlace ChatGPT de apariencia benigna, lo que genera un nuevo agente de inteligencia artificial dentro de los límites de confianza de la empresa que cumple las órdenes del atacante. El problema es un caso de falsificación de solicitudes entre sitios (CSRF) que falsifica un agente de IA autónomo controlado por un atacante.

Generador de agentes es un lienzo visual de arrastrar y soltar que permite a los usuarios crear flujos de trabajo de agentes de varios pasos. El mes pasado, OpenAI anunciado que dejará de usar el producto a partir del 30 de noviembre de 2026, instando a los usuarios a cambiar al SDK de agentes.

Zenity dijo que sus pruebas encontraron que la herramienta Builder acepta un estado de inicialización a través de parámetros de URL, dos de los cuales incluyen una plantilla de agente y el mensaje al Builder.

Ciberseguridad

«Descubrimos que cuando se carga la página, el valor de inicial_assistant_prompt no se coloca simplemente en el cuadro de aviso. Se envía y ejecuta automáticamente», dijo Mike Takahashi, investigador del equipo rojo de IA. «Eso significa que una instrucción incrustada dentro de una URL puede convertirse en el primer comando sobre el que actúa el Constructor».

Dado que se puede insertar un mensaje directamente en la URL, un atacante puede enviar la URL a un objetivo en forma de enlace de phishing que siga el siguiente patrón: «chatgpt[.]es/agentes/estudio/new?template_name=[template name]&initial_assistant_prompt=[malicious prompt]».

Si un usuario que ha iniciado sesión hace clic en el enlace, ChatGPT abre el Constructor en la sesión autenticada de la víctima y envía automáticamente el mensaje incrustado en la URL sin requerir ninguna interacción adicional. Sin embargo, el atacante debe cumplir los siguientes requisitos previos:

  • Una víctima que ha iniciado sesión en ChatGPT
  • La víctima tiene acceso a Workspace Agents
  • La víctima tiene al menos un conector autorizado (es decir, una integración ChatGPT ya existente con una aplicación empresarial como Outlook, Gmail, Google Calendar, Google Drive, Slack o Teams).

La integración del conector es necesaria porque la URL de ChatGPT diseñada pasa como entrada una plantilla de jefe de personal que permite al agente extraer los datos necesarios de las aplicaciones del espacio de trabajo para preparar un «resumen operativo de alta señal».

Específicamente, la carga útil pasada a través del mensaje malicioso le indica al Constructor que realice la siguiente secuencia de acciones:

  • Cree un agente a partir de la plantilla de jefe de personal.
  • Conecte todos los conectores ya disponibles y configure cada conector en «Nunca preguntar» para que no se necesite la aprobación del usuario.
  • Haga que el agente esté activo y prográmelo para que se ejecute cada hora, convirtiéndolo en un mecanismo de persistencia.
  • Durante cada ejecución, busque correos electrónicos de una dirección de correo electrónico específica cuya línea de asunto comience con la frase «TASK», ejecute esas tareas e informe los resultados enviando un mensaje de correo electrónico a la dirección del atacante.
  • Invoque el modo de vista previa para ejecutar el agente inmediatamente.

«El modo de vista previa está destinado a permitir a los usuarios probar un agente antes de publicarlo», explicó Zenity. «En este flujo, sin embargo, la Vista previa no es sólo una vista previa visual o un ensayo. Ejecuta el agente recién creado contra las cuentas conectadas de la víctima utilizando la configuración de aprobación que acaba de configurarse».

«En otras palabras, el agente falsificado se convierte en un operador persistente. El clic original lo instala; la programación lo mantiene vivo; y las aplicaciones conectadas le brindan una fuente de comandos, acceso a acciones y datos confidenciales, así como una ruta para devolver resultados».

Armado con esta capacidad, el agente falsificado puede profundizar en la organización, realizar reconocimientos, recopilar documentos confidenciales de servicios de almacenamiento en la nube y robar contraseñas mencionadas en los mensajes de Slack, convirtiéndolo esencialmente en un interno persistente y autónomo capaz de hacer lo que el atacante quiere hacer.

Ciberseguridad

Es más, el agente malicioso del espacio de trabajo puede hacerse pasar por la víctima para enviar enlaces de phishing en Teams en su nombre, que luego pueden redirigir a los destinatarios a una página de inicio de sesión falsa de Microsoft diseñada para desviar sus credenciales. Este escenario es preocupante ya que puede abrir la puerta a un compromiso más amplio y otros escenarios de compromiso del correo electrónico empresarial (BEC).

«El atacante no necesita que la víctima haga clic en otro enlace», Takahashi explicado. «No necesitan que la pestaña Builder permanezca abierta. Una vez que el agente se publica y programa, el atacante puede seguir enviándole asignaciones a través del buzón de correo de la víctima. Cada correo electrónico de TAREA se convierte en una nueva asignación para el agente. El agente no está esperando otro clic. Está esperando instrucciones».

«En esencia, AgentForger es una falla de confianza del agente: la plataforma confía en que el usuario creó, aprobó, programó y operó intencionalmente el agente».

Los hallazgos llegan casi un mes después de que la empresa de seguridad de IA reveló que malos actores son explotando Vulnerabilidades críticas de LiteLLM y puntos finales expuestos de Ollama y secuestro de infraestructura de IA para realizar ataques contra terceros y potenciar los suyos propios. operaciones ofensivas. Estos esfuerzos implican el abuso de CVE-2024-6587, CVE-2026-40217y CVE-2026-35029.

«Los servidores modelo autohospedados y los marcos de agentes se siguen implementando mientras están mal configurados y no autenticados, en puertos predecibles, dispuestos a servir a cualquier cliente», dijo Zenity. «Esto convierte la infraestructura de IA expuesta en un cómputo de backend conveniente y negable para agentes de IA ofensivos».

La falla de Claude Cowork podría permitir que el agente AI escape de su máquina virtual y acceda a archivos de Mac – CYBERDEFENSA.MX

Investigadores de ciberseguridad han descubierto una vulnerabilidad de escape de sandbox en Anthropic Claude Cowork eso hace posible salir de los límites de una máquina virtual (VM) de Linux dentro de la cual se ejecuta el agente para leer o escribir archivos en cualquier lugar de la Mac.

Accomplish AI, que compartió detalles de la vulnerabilidad con The Hacker News antes de su publicación, dijo que alrededor de 500.000 usuarios de macOS que ejecutaban sesiones locales de Cowork se vieron afectados antes de que se parcheara. ha sido nombrado en clave Raíz compartida.

«Conectamos una carpeta a una nueva sesión de Claude Cowork, enviamos un mensaje corto y vimos al agente escapar de la zona de pruebas», dijo Oren Yomtov, investigador principal de seguridad de Accomplish AI, dicho. «Desde el interior de la máquina virtual, llegó al host Mac y leyó y escribió archivos por todas partes, muy fuera de la carpeta que habíamos conectado, sin solicitar permiso en ninguna parte».

Con este nivel de acceso, el agente puede acceder a cualquier dato almacenado en la Mac a través de la cuenta del usuario, incluidas claves SSH, credenciales de la nube y otra información valiosa.

Tras una divulgación responsable, Anthropic cerró el informe como informativo sin publicar una solución. Dicho esto, la última versión de Cowork utiliza de forma predeterminada la ejecución en la nube, lo que soluciona el problema. Pero los usuarios que optan por ejecutar el agente localmente todavía están expuestos al problema.

Ciberseguridad

La aplicación de escritorio macOS de Claude Cowork se ejecuta como el usuario que ha iniciado sesión en el sistema. El trabajo real relacionado con el agente, por otro lado, ocurre en una máquina virtual Linux creada a través de Apple. Marco de virtualización. Cada sesión tiene su propio usuario desechable sin privilegios, junto con un filtro de Modo de Computación Segura (seccomp) para el sandboxing de aplicaciones. Las carpetas conectadas por el usuario se comparten en la VM mediante un demonio raíz llamado coworkd.

«Un detalle importa más que el resto: el sistema de archivos del host se comparte en esa VM de lectura y escritura», explicó Yomtov. «Todo el host ‘/’ está montado de modo que solo el invitado raíz dentro de la VM pueda verlo, en /mnt/.virtiofs-root».

Debido a que todo el sistema de archivos del host está montado en la máquina virtual del agente con privilegios de lectura y escritura, cualquier ruta a la raíz del invitado puede otorgar al agente acceso al host subyacente, escapando efectivamente del entorno limitado.

Esto implica cargar el subsistema de edición de paquetes de control de tráfico (tc) «act_pedit» del kernel de Linux en un espacio de nombres de usuario sin privilegios y explotar CVE-2026-46331 en el kernel invitado, una falla recientemente revelada llamada pedit COW, para obtener la raíz invitada. Desde allí, el agente puede acceder a todo el host («https://thehackernews.com/») con privilegios elevados, lo que le permite leer o escribir archivos desde y hacia el sistema de archivos de Mac como usuario de escritorio conectado.

Or Hiltch, cofundador y CTO de Accomplish AI, dijo a The Hacker News que la creación de espacios de nombres de usuarios y redes le da a la sesión CAP_NET_ADMIN dentro de su espacio de nombres de red privada, lo que le permite realizar diversas operaciones relacionadas con la red.

«Esa capacidad proporciona acceso a la ruta vulnerable del kernel tc/act_pedit utilizada por pedit COW», añadió Hiltch. «Los espacios de nombres no son el exploit; ponen su prerrequisito normalmente privilegiado a disposición de un usuario normal».

El desarrollo adquiere importancia ante las revelaciones de que los modelos de OpenAI lograron salir de su entorno aislado durante una prueba de seguridad que resultó en la violación de la infraestructura de producción de Hugging Face en su intento de engañar al punto de referencia ExploitGym en el que estaban siendo calificados.

Ciberseguridad

«act_pedit es un error en una categoría», dijo Yomtov. «El subsistema net/sched de Linux lanza esta forma exacta de escalada de privilegios en una cadencia regular: un módulo autocargable, una ruta de configuración que un usuario sin privilegios puede alcanzar, un error de memoria al final. Parche este y habrá arreglado este. La cadena se rearma en el siguiente, con todo lo que está encima del kernel intacto».

«Y el siguiente siempre está por llegar. En cualquier momento dado, es probable que haya un error de escalada de privilegios al que todavía está expuesto, a veces solucionado en el sentido anterior pero aún no en su imagen, a veces aún no solucionado en ninguna parte, con un exploit funcional que funciona en cuestión de horas. Este no es un problema que se solucione más rápido. Estás estructuralmente un error detrás, todo el tiempo».

Para mitigar la amenaza, es esencial deshabilitar espacios de nombres de usuarios sin privilegiosevite hacer que el filtro seccomp sea demasiado permisivo, detenga la carga automática de módulos y restrinja el uso compartido de todo el host en la máquina virtual.

«Aléjelo a las carpetas que realmente estaban conectadas en lugar de a todas /, o al menos móntelo como de solo lectura, y ejecute coworkd con ProtectSystem=strict en su propio espacio de nombres de montaje para que no vuelva a ejecutar archivos binarios que un usuario de sesión pueda envenenar», dijo Accomplish. «Entonces, incluso una raíz invitada completa no tiene nada donde aterrizar, los dos últimos pasos de la cadena no tienen adónde ir».

La falla de RefluXFS Linux de nueve años de antigüedad brinda a los usuarios locales acceso root en las instalaciones predeterminadas de RHEL

RefluXFSun nuevo Fallo del kernel de Linux divulgado el 22 de julio y rastreado como CVE-2026-64600permite a un usuario local sin privilegios sobrescribir archivos propiedad de root en un sistema de archivos XFS y obtener acceso de root persistente.

Qualys dijo que las instalaciones predeterminadas de Red Hat Enterprise Linux y sus derivados, Fedora Server y Amazon Linux pueden cumplir las condiciones de explotación.

La empresa demostró la carrera contra /etc/passwd y binarios de raíz setuid. La sobrescritura llega a la capa del bloque. Sobrevive a un reinicio y deja intactos la propiedad, los permisos, las marcas de tiempo y el bit setuid del objetivo, por lo que un binario setuid-root modificado aún se ejecuta como root.

La solución se fusionó el 16 de julio y los proveedores de Linux comenzaron a enviar kernels respaldados. El parche rastrea el error hasta Linux 4.11 en 2017: a Fixes: compromiso de nomenclatura de etiquetas 3c68d44a2b49 y una solicitud de backport estable marcada # v4.11.

quien esta expuesto

La explotación requiere tres condiciones:

  • El sistema ejecuta Linux 4.11 o posterior sin la solución RefluXFS.
  • El sistema de archivos XFS fue creado con reflink=1.
  • El objetivo legible y un directorio en el que el atacante puede escribir están en el mismo sistema de archivos XFS.

qualys dicho parchear primero los sistemas expuestos y multiinquilino, lo que significa cualquier host XFS habilitado para reflink donde el código que no es de confianza pueda ejecutarse localmente, ya sea a través de un shell, un trabajo de CI o un servicio comprometido.

Ciberseguridad

El aviso enumera las instalaciones predeterminadas que pueden cumplir esas condiciones: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux y CloudLinux 8, 9 y 10, Fedora Server 31 y posteriores, Amazon Linux 2023 e imágenes de Amazon Linux 2 desde diciembre de 2022 en adelante. Los sistemas de archivos RHEL 7 no se ven afectados porque son anteriores al soporte de reflink XFS.

Debian, Ubuntu, SLES y openSUSE generalmente no usan XFS para el sistema de archivos raíz de forma predeterminada. Están expuestos sólo si un administrador elige XFS con reflink habilitado en el momento de la instalación.

Verifique el sistema de archivos raíz:

xfs_info / | grep reflink=

reflink=1 significa que se cumple la condición dos. Ejecute la misma comprobación en cualquier otro volumen XFS montado donde un archivo protegido y un directorio grabable por el atacante compartan el sistema de archivos.

El mapeo obsoleto

Un atacante clona un archivo de propiedad raíz en un archivo borrador con FICLONEque solo necesita acceso de lectura en la fuente, luego corre simultáneamente O_DIRECT escribe contra el clon. Los enlaces de referencia XFS utilizan copia en escritura, por lo que ambos archivos inicialmente hacen referencia a los mismos bloques de disco físico.

El kernel lee el mapeo de bifurcación de datos bajo el bloqueo de inodo y se lo entrega a xfs_reflink_fill_cow_hole()que realiza un ciclo de ese bloqueo para reservar espacio de transacción.

Un segundo escritor puede completar la operación de copia en escritura durante ese intervalo y reasignar el archivo clonado a un nuevo bloque. Cuando el primer escritor vuelve a adquirir el bloqueo, actualiza la bifurcación de copia en escritura pero continúa usando la antigua asignación de bifurcación de datos.

El parche ascendente describe la falla claramente: «las asignaciones quedan obsoletas tan pronto como volvemos a adquirir ILOCK».

Esa dirección obsoleta ahora apunta a un bloque que pertenece únicamente al archivo protegido original. XFS ve el bloque como no compartido y permite la escritura directa, por lo que los datos destinados al clon del atacante llegan al objetivo.

Es un error de verificación y uso durante un ciclo de bloqueo. La consulta de estado compartido en sí es correcta; lo que consulta es una dirección de bloque capturada antes de que se liberara el bloqueo.

The Hacker News descubrió que el parche afecta a dos ayudantes, xfs_reflink_fill_cow_hole() y xfs_reflink_fill_delalloc(). El segundo tiene el mismo patrón de ciclo de bloqueo y no aparece en el aviso de Qualys. En ambos, las instantáneas de corrección. ip->i_df.if_seq antes de que se caiga el bloqueo y vuelve a leer la bifurcación de datos con xfs_bmapi_read() si el contador se movía.

La E/S directa omite el caché de la página y no tiene enlace de revalidación, por lo que la escritura llega al disco. Debido a que omite por completo el inodo objetivo, los metadatos nunca cambian y los investigadores dijeron que sus pruebas no produjeron ninguna advertencia del núcleo ni entrada de registro.

En la máquina de pruebas, la carrera se ganaba normalmente en menos de diez segundos. La demostración publicada elimina la contraseña de root en un cuadro RHEL 10.2 predeterminado.

Qualys dijo que un modelo de IA encontró la falla. La compañía señaló Claude Mythos Preview, el modelo de frontera de acceso restringido de Anthropic, al núcleo y, según su asesoramiento técnico«le pidió que encontrara una vulnerabilidad similar a Dirty COW».

El modelo localizó la carrera, escribió un exploit de raíz funcional y redactó el aviso. Luego, los investigadores lo reprodujeron en una instalación estándar de Fedora Server 44, verificaron el razonamiento del modelo y coordinaron la divulgación en sentido ascendente.

No es el primer error de kernel antiguo que sufre el equipo este año. Qualys ha estado encontrando muchos de estos. Un día antes, reveló una falla de confinamiento instantáneo en Ubuntu Desktop, CVE-2026-8933donde dos razas permiten que un usuario local obtenga root en instalaciones predeterminadas. En mayo encontró un error de nueve años de antigüedad en las comprobaciones de seguimiento del núcleo.

Parchear, luego reiniciar

sombrero rojo ha emitido avisos de kernel con clasificación importante en las transmisiones RHEL 8, 9 y 10 afectadas. La errata comenzó a llegar el 14 de julio, ocho días antes de la divulgación coordinada: RHSA-2026:39179 y RHSA-2026:39180 para RHEL 8 y RHSA-2026:39494 para RHEL 10, con soporte extendido y flujos de SAP hasta el 17 de julio.

La cobertura es específica de cada transmisión, así que confirme que exista un aviso para su versión exacta. Cualquiera que aplicara esas erratas a tiempo estaba cubierto antes de que RefluXFS tuviera un nombre. Verifique las fechas de sus parches antes de asumir la exposición.

el vendedor rastreador de errores presenta la falla bajo el título «kernel: corrupción de datos XFS usando reflink». La entrada se importó automáticamente el 10 de julio e inicialmente describía el problema como una posible corrupción de datos al volver a vincular un archivo.

Ciberseguridad

A partir del 23 de julio, rastreador de Debian enumeró la solución en trixie-security como kernel 6.12.96-1 y en inestable como 7.1.4-1. El núcleo base de Trixie 6.12.94-1 y forky 7.1.3-1 todavía estaban marcados como vulnerables, al igual que los ratones de biblioteca y los diana, incluidas sus ramas de seguridad.

No existe una opción de montaje o sysctl que deshabilite los enlaces de referencia XFS después de que se haya creado un sistema de archivos, y Qualys dijo que no hay ninguna mitigación práctica o cambio de configuración temporal disponible. SELinux en modo Enforcing, seccomp, bloqueo del kernel y límites de contenedores no lograron detenerlo en las pruebas de la compañía. Las protecciones de memoria como KASLR y SMEP nunca se aplicaron: se trata de una escritura en la capa de bloque, no de una corrupción de la memoria.

Un límite aparente no lo es. La carrera solo se activa si el bloque del objetivo comienza sin compartir, por lo que no se puede acceder a un archivo que un administrador ya haya copiado mediante reflink. El aviso dice que un usuario sin privilegios puede restablecer esa condición ejecutando chshy que es poco probable que los binarios setuid-root hayan sido vinculados nuevamente en primer lugar.

Qualys no publicó ningún código de explotación independiente. El rastreador de Red Hat registró una prueba de concepto pública el 22 de julio, señalando el aviso publicado en la lista de seguridad de oss, que establece la carrera y los pasos de explotación en su totalidad. Ninguno de los proveedores que rastrearon la falla había informado de explotación en estado salvaje al momento de escribir este artículo.

The Hacker News se comunicó con Red Hat para comentar sobre su evaluación del impacto de la falla y con Qualys para obtener más detalles sobre el hallazgo, y actualizará esta historia con cualquier respuesta.

La instalación del paquete no reemplaza el kernel que ya se está ejecutando en la memoria. Aplique la actualización del proveedor, reinicie el sistema y verifique que esté ejecutando el kernel reparado.

La falla de configuración instantánea de Ubuntu podría dar a los usuarios locales acceso root en las instalaciones de escritorio predeterminadas

Investigadores de ciberseguridad han revelado detalles de una nueva vulnerabilidad de escalada de privilegios locales (LPE) en snap-confine que un usuario sin privilegios puede activar para obtener acceso raíz y obtener control completo de un entorno de destino.

La falla de alta gravedad, rastreada como CVE-2026-8933 (Puntuación CVSS: 7,8), afecta las instalaciones predeterminadas de Ubuntu Desktop 24.04, 25.10 y 26.04. La divulgación se produce cuando se han identificado 442 fallas de seguridad en Linux. publicitado durante los últimos tres días.

«El problema surge de un cambio de refuerzo de seguridad que inadvertidamente introdujo una condición de carrera durante la inicialización de la zona de pruebas», dijo Saeed Abbasi, jefe de la Unidad de Investigación de Amenazas (TRU) y director de producto de Qualys.

Snap-confine es un programa utilizado internamente por snapd para construir el entorno de ejecución de aplicaciones snap. Snapd es el servicio en segundo plano o demonio que administra paquetes instantáneos en sistemas Linux. Los snaps no son más que un formato de paquete de software ideado por Canonical que permite que una aplicación se ejecute de forma segura en un entorno aislado en la mayoría de las distribuciones de Linux.

«Snapd ejecuta un subproceso llamado snap-confine, que es responsable de crear el confinamiento necesario para el snap», según Canónico.

Aunque las versiones recientes de Ubuntu hacen uso del modelo de capacidades establecidas para imponer el principio de privilegio mínimo (PoLP) como una forma de minimizar la superficie de ataque, los cambios permiten ejecutar snap-confine con el UID efectivo del usuario que llama, al mismo tiempo que se conservan las capacidades cercanas a la raíz.

Ciberseguridad

«Durante la configuración de la zona de pruebas, el binario crea directorios y archivos temporales en /tmp que inicialmente son propiedad del usuario sin privilegios», explicó Qualys. «La propiedad se transfiere a la raíz poco después, pero permanece un período estrecho durante el cual la persona que llama conserva el control total».

El problema identificado por el proveedor de ciberseguridad es el resultado de dos condiciones de carrera simultáneas:

  • Un atacante monta un malware sistema de archivos FUSIBLE sobre el directorio temporal temporal inmediatamente después de la creación, omitiendo el aislamiento del espacio de nombres de montaje aplicado por snap-confine y manteniendo el directorio accesible fuera del entorno limitado.
  • El atacante crea un enlace simbólico (también conocido como enlace simbólico) que apunta a un archivo de destino arbitrario, redirigiendo efectivamente las operaciones de archivos a ubicaciones sensibles del sistema.

Al manipular los permisos de los archivos antes de que el sistema transfiera la propiedad, el atacante puede inyectar reglas maliciosas en los directorios del sistema y obtener la ejecución del código raíz, señaló Qualys.

«Cuando snap-confine intenta crear un archivo sandbox, la llamada open() sigue el enlace simbólico y escribe en el destino», dijo Abbasi. «Una segunda condición de carrera permite al atacante ampliar los permisos de archivos a 0666 antes de que snap-confine llame a fchown() para transferir la propiedad a la raíz».

«Para evitar el confinamiento de AppArmor, el exploit apunta a la ruta /run/udev/**, que permite el acceso de lectura y escritura. Al colocar un archivo .rules malicioso en /run/udev/rules.d/ y desencadenar un ciclo de montaje/desmontaje de FUSE, el atacante obliga a systemd-udevd a ejecutar comandos arbitrarios como root».

Para contrarrestar el riesgo que plantea CVE-2026-8933, las organizaciones deben aplicar las últimas actualizaciones de Snapd lo antes posible.

Ciberseguridad

«Un atacante todavía necesita acceso a nivel de usuario o ejecución de código, pero CVE-2026-8933 puede convertir ese punto de apoyo en control total del host», dijo Jason Soroko, miembro senior de Sectigo, en un comunicado. «Su presencia en las instalaciones predeterminadas de Ubuntu Desktop hace que las estaciones de trabajo de los empleados, los sistemas de desarrollo y los puntos finales administrativos formen parte del alcance de la respuesta».

«Ubuntu 24.04 es notable porque los sistemas actualizados pueden llevar la variante snap-confine afectada, lo que muestra por qué los administradores deben verificar la versión instalada de snapd en lugar de confiar en la antigüedad del lanzamiento o el estado del parche anterior. Con las correcciones disponibles, la implementación rápida y la confirmación deben tener prioridad».

Esta no es la primera vez que se descubren fallas de seguridad en el componente de confinamiento instantáneo. En febrero de 2022, Qualys detalló otra falla de escalada de privilegios locales denominada Oh Snap! Más Lemmings (CVE-2021-44731) de los que se podría abusar para obtener privilegios de root explotando una condición de carrera en setup_private_mount() de snap-confine.

Desde entonces, han salido a la luz varias otras vulnerabilidades, incluida CVE-2022-3328 (puntuación CVSS: 7,8) y CVE-2026-3888 (Puntuación CVSS: 7,8).

Los piratas informáticos aprovechan la falla del molino de viento para leer archivos de servidor arbitrarios sin autenticación – CYBERDEFENSA.MX

Una falla de seguridad de alta gravedad que afecta la plataforma de desarrollo de código abierto Molino ha sido objeto de explotación activa en la naturaleza, según VulnCheck.

La vulnerabilidad en cuestión es CVE-2026-29059 (Puntuación CVSS: 7,5), un caso de recorrido de ruta no autenticado que afecta el punto final «get_log_file» de Windmill («/api/w/{workspace}/jobs_u/get_log_file/{filename}»).

«El parámetro de nombre de archivo está concatenado en una ruta de archivo sin desinfección, lo que permite a un atacante leer archivos arbitrarios en el servidor usando secuencias ../», según un aviso. publicado por Windmill en marzo de 2026.

«El principal valor sensible expuesto por esta vulnerabilidad es la variable de entorno SUPERADMIN_SECRET, legible a través de /proc/1/environ. Cuando se establece, este secreto se puede utilizar como token de portador para autenticarse como superadministrador y ejecutar código arbitrario a través de la API de vista previa del trabajo».

Sin embargo, vale la pena señalar que SUPERADMIN_SECRET no está configurado de forma predeterminada y, para instancias independientes de Windmill sin SUPERADMIN_SECRET configurado, el impacto de la vulnerabilidad se limita a la lectura de archivos arbitrarios. Desde entonces, el problema se solucionó en Windmill 1.603.3, lanzado en enero de 2026, agregando comprobaciones de desinfección al parámetro de nombre de archivo para evitar el cruce de directorios.

Según VulnCheck, a cuyo investigador de seguridad Valentin Lobstein se le atribuye haber descubierto y reportado la falla, los esfuerzos de explotación se han dirigido contra el punto final «get_log_file» de Windmill para extraer información confidencial del archivo «/etc/passwd».

«Hemos observado exploits dirigidos tanto a los puntos finales directos de Windmill como a la ruta del proxy Nextcloud», Caitlin Condon, vicepresidenta de investigación de seguridad de VulnCheck, dicho en una publicación en LinkedIn.

La empresa de ciberseguridad dijo que identificó alrededor de 170 sistemas vulnerables expuestos en 24 países.

La divulgación se produce cuando la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) agregado cuatro fallas de seguridad en sus vulnerabilidades explotadas conocidas (KEV), incluidos dos errores de WordPress rastreados como wp2shell (CVE-2026-60137 y CVE-2026-63030), junto con un desbordamiento del búfer basado en pila en DD-WRT (CVE-2021-27137) y un problema de ejecución remota de código no autenticado en Langflow (CVE-2026-0770).

«wp2shell es uno de los eventos de seguridad de WordPress Core más importantes de los últimos años», Wordfence dicho. «La combinación de accesibilidad no autenticada, ningún requisito de complemento o tema, una gran superficie de ataque global, un camino hacia el acceso de administrador y la ejecución de código, así como la disponibilidad pública de exploits de prueba de concepto hacen que esta cadena de vulnerabilidad sea inusualmente grave».

Los datos de ataque capturados por la empresa de seguridad de WordPress muestran que los actores de amenazas están emitiendo solicitudes para explotar el problema de confusión de ruta de solicitud por lotes de la API REST y una inyección SQL no autenticada para lograr la ejecución del código.

En cuanto a CVE-2026-0770, Ryan Dewhurst de KEVIntel dijo a The Hacker News que detectó por primera vez intentos de explotación dirigidos a la falla contra sus sensores el 27 de junio de 2026, registrando 137 intentos de explotación de 46 direcciones IP únicas de atacantes asociadas con 17 países.

No menos de 75 intentos, que representan más de la mitad de la actividad, se originaron desde 20 direcciones IP de atacantes durante los últimos siete días. Las cargas útiles observadas incluyen comprobaciones de ejecución de comandos base, intentos de extraer el contenido de «/etc/passwd» o acceder a las credenciales de AWS, recopilación de variables de entorno, descargas de malware mediante wget o curl y ejecución de scripts de shell para instalar cargas útiles de segunda etapa.

«La actividad no se limita a comprobaciones de vulnerabilidad», dijo Dewhurst. «Si bien gran parte involucraba comandos como id, whoami y lectura /etc/passwd, también observamos cargas útiles que intentaban descargar malware y obtener variables de entorno, credenciales de AWS y metadatos de contenedores».

Se recomienda a las agencias del Poder Ejecutivo Civil Federal (FCEB) que remedien las fallas identificadas antes del 24 de julio de 2026.

La falla de Microsoft Azure DevOps MCP permite que los comentarios de relaciones públicas ocultos se apropien de los agentes de revisión de IA

Un solo comentario invisible en una solicitud de extracción de Azure DevOps puede poner al propio agente de codificación de IA del revisor en su contra, llevándolo a proyectos a los que el atacante no tiene derecho a acceder y filtrando silenciosamente lo que encuentra.

La falla está en el oficial de Microsoft. Servidor Azure DevOps MCPy funciona porque una de sus herramientas devuelve descripciones de solicitudes de extracción sin una barrera de inyección rápida que la empresa ya había aplicado a otras.

Empresa de seguridad ofensiva Seguridad múltiple detalló el error del diputado confundido esta semana. Microsoft envía el servidor para que los agentes de IA puedan leer y operar Azure DevOps para un usuario, a través de solicitudes de extracción, canalizaciones, wikis y elementos de trabajo, todo con los permisos propios del usuario. Ese es el problema: el contenido que escribieron otras personas puede convertirse en instrucciones sobre las que actúa el agente.

Las descripciones de Azure DevOps PR aceptan Markdown, que permite comentarios HTML. En la interfaz de usuario web, un comentario HTML () se muestra como nada, por lo que un revisor que se desplaza por la descripción ve un cambio normal. La API REST lo devuelve palabra por palabra y el servidor entrega ese texto directamente al agente.

Esa división entre lo que ve el humano y lo que recibe el modelo es el mecanismo de entrega: el atacante nunca habla con el agente, sino que coloca instrucciones en un contenido que sabe que leerá más tarde.

Cuando el revisor le pide a su agente que revise el PR, el texto oculto puede reescribir el objetivo del agente. El agente lleva las credenciales del revisor, por lo que puede actuar en proyectos a los que el atacante no tiene derecho a acceder.

Ciberseguridad

Manifold dice que el acceso alcanza el código fuente, los secretos y los elementos de trabajo, no solo la página wiki, su prueba de concepto exfiltrada. La firma considera que la escalada es un caso normal, ya que los revisores suelen ser de mayor rango que quien abrió la solicitud de extracción. El atacante no gana nada directamente; toman prestado el acceso del revisor a través de texto que el revisor nunca ve.

La ruta de la solicitud de extracción pasó por alto la barandilla

Lo que eleva esto por encima de una advertencia genérica de inyección rápida es que Microsoft ya envió una defensa para ello. Al leer la fuente del servidor, Manifold descubrió que utiliza foco, una técnica de La propia guía de Microsoft sobre inyección rápida indirecta: envuelve el contenido que no es de confianza en delimitadores para que el modelo pueda diferenciar los datos de las instrucciones que debe seguir.

La empresa lo añadió en PR #1062donde las herramientas de página wiki y registro de compilación pasan su salida a través de un asistente compartido, createExternalContentResponse. La herramienta que devuelve una solicitud de extracción, repo_get_pull_request_by_id, nunca la llama, por lo que devuelve la descripción sin formato, que es exactamente la superficie en la que escribe un atacante.

The Hacker News confirmó lo mismo camino todavía está descubierto en la fuente actual al 21 de julio.

En la prueba de concepto de Manifold, ejecutada en una compilación local de v2.7.0, un colaborador de un proyecto abre un PR de apariencia normal cuyo comentario oculto lleva la carga útil. Una vez que el agente comienza su revisión, el seguimiento de la herramienta ejecuta una cadena: activa una canalización en un proyecto diferente, lee una página wiki confidencial que el atacante no puede abrir y publica esa página como un comentario en el PR, donde el atacante la lee.

Un único comentario oculto impulsó toda la secuencia, y cada llamada que contenía era una que el agente podía realizar. El problema, escribieron los investigadores, era «la secuencia y la intención, impulsadas por un texto que un humano nunca vio». El equipo lo reprodujo tanto con Copilot CLI como con Claude Code, por lo que no está vinculado a un solo agente.

Sin embargo, la cadena tiene requisitos previos: texto de relaciones públicas escrito por el atacante, un flujo de trabajo que lo envía a un agente, un revisor cuyo acceso excede el del atacante y un agente autorizado para ejecutar herramientas sin preguntar.

Manifold confirmó que probó esa última parte como una postura de aprobación automática sin mensajes por herramienta, el punto de control que de otro modo permitiría a un revisor detectar una ejecución extraña entre proyectos antes de que se active. Un token amplio más esa postura es donde se concentra el riesgo.

La demostración supone que una persona inicia la revisión, pero Manifold señala hacia dónde se dirigen los equipos: revisión automatizada, clasificación y resúmenes generados por activadores, sin que ningún ser humano indique cada ejecución o lea cada resultado. En esa configuración, la descripción colocada se activa por sí sola y la fuga dura más tiempo antes de que alguien se dé cuenta.

El patrón no es nuevo. En mayo de 2025, Invariant Labs mostró el mismo tipo de ataque contra Servidor MCP de GitHubutilizando un problema público para obligar a un agente a leer un repositorio privado y filtrarlo a través de una solicitud de extracción; Desde entonces, la misma técnica ha llegado a los flujos de trabajo automatizados del agente GitHub.

Ese caso fue uno de los ejemplos que señaló Simon Willison al nombrar al trifecta letal: un agente con acceso a datos privados, exposición a contenido no confiable y una forma de enviar datos. Cualquier agente con los tres puede volverse contra su propietario con un solo fragmento de texto, y los más útiles tienen los tres.

Un portavoz de Microsoft agradeció a Manifold por informar del comportamiento bajo divulgación coordinada y lo llamó «una clase conocida de riesgo de IA» que informa el trabajo continuo de la compañía sobre sus salvaguardas. Microsoft no dijo si cambiaría el código o asignaría un CVE.

Ciberseguridad

Señaló que el ataque requiere que un atacante ya tenga acceso de escritura a un proyecto y un segundo usuario para invocar una herramienta de IA sobre el contenido, y recomendó a los clientes limitar el acceso al proyecto y «revisar los cambios propuestos antes de pedirle a una herramienta de IA que actúe en consecuencia». El problema es que la carga útil aquí es invisible en la interfaz que revisa un humano.

Hasta el 21 de julio, no hay ninguna versión solucionada y The Hacker News no encontró ningún CVE asignado a la falla en las bases de datos públicas. La última versión, v2.8.0enviado el 24 de junio. Ningún informe público sitúa la técnica en uso fuera de las propias pruebas de Manifold.

Manifold probó sólo el servidor local basado en PAT, pero le dijo a The Hacker News que la causa raíz está «en el código del servidor, no en el transporte». Según esa lógica, el alojamiento servidor MCP remoto También estaría expuesto, pero Manifold no lo probó y Microsoft no lo abordó.

El foco eleva el listón pero no cierra la inyección rápida por sí solo, por lo que las defensas son las habituales. Otorgue al agente tokens de privilegios mínimos y afínelo al proyecto que se está revisando. Cargue solo los dominios MCP que la tarea necesita; el servidor local los reduce con un indicador -d.

Mantenga las ejecuciones de canalizaciones, las lecturas de wiki y la publicación de comentarios fuera de un conjunto de herramientas de revisión de código que no los utiliza. Para verificar si la cadena ya se ejecutó, busque en los rastreos de herramientas del agente ejecuciones de canalizaciones entre proyectos, lecturas de wiki o comentarios que publicó durante una revisión, y escanee las descripciones de relaciones públicas abiertas en busca de comentarios HTML ocultos. Un revisor humano que no puede ver la carga útil no es un control.

La barandilla sólo funciona cuando alguien recuerda agregarla. Envuelve el contenido que no es de confianza en una ruta de respuesta a la vez, por lo que la defensa es tan fuerte como la ruta menos cubierta, y una envoltura faltante en una sola función es casi invisible desde el exterior. En una superficie de herramientas que sigue creciendo, brechas como ésta se abren más rápido de lo que nadie piensa al auditarlas.