Las credenciales estáticas y explotadas activamente de Cisco FMC Zero-Day podrían exponer datos confidenciales – CYBERDEFENSA.MX

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) el miércoles agregado una falla de seguridad recientemente revelada que afecta el software Cisco Secure Firewall Management Center (FMC) a sus vulnerabilidades explotadas conocidas (KEV) catálogo, tras informes de explotación de día cero.

La vulnerabilidad, asignada CVE-2026-20316 (Puntuación CVSS: 5,3), podría permitir que un atacante remoto no autenticado inicie sesión en un dispositivo afectado utilizando una cuenta con pocos privilegios para acceder a datos confidenciales dentro de sistemas susceptibles.

«Esta vulnerabilidad se debe a la presencia de credenciales de usuario estáticas para una cuenta con pocos privilegios», Cisco dicho en una alerta publicada el miércoles. «Un atacante podría aprovechar esta vulnerabilidad utilizando la cuenta para iniciar sesión en un sistema afectado».

Ciberseguridad

«Un exploit exitoso podría permitir al atacante iniciar sesión en el sistema afectado y acceder a datos confidenciales como usuario con pocos privilegios».

Cisco señaló que la superficie de ataque asociada con la vulnerabilidad se reduce si la interfaz de administración del FMC no tiene acceso público a Internet. La compañía de equipos de red también dijo que le está asignando una Clasificación de Impacto de Seguridad (SIR) de Alto en lugar de Medio debido al hecho de que se puede encadenar con otras vulnerabilidades del software Cisco Secure FMC para elevar los privilegios.

Al investigador de seguridad Jimi Sebree de Horizon3.ai se le atribuye el mérito de descubrir e informar la falla. Cisco también reconoció que fue explotado activamente a principios de este mes, aunque no reveló cuándo comenzaron los ataques, quién está detrás de ellos o cómo se explota la vulnerabilidad en estos esfuerzos.

El problema se ha solucionado en las siguientes versiones de revisión del software Cisco Secure FMC:

  • 7.0 – Cisco_Firepower_Mgmt_Center_Hotfix_GB-7.0.9.1-3.sh.REL.tar
  • 7.2 – Cisco_Secure_FW_Mgmt_Center_Hotfix_HL-7.2.11.1-4.sh.REL.tar
  • 7.4 – Cisco_Secure_FW_Mgmt_Center_Hotfix_HG-7.4.7.1-3.sh.REL.tar
  • 7.6 – Cisco_Secure_FW_Mgmt_Center_Hotfix_CY-7.6.5.1-2.sh.REL.tar
  • 7.7 – Cisco_Secure_FW_Mgmt_Center_Hotfix_AM-7.7.12.1-2.sh.REL.tar
  • 10.0 – Cisco_Secure_FW_Mgmt_Center_Hotfix_P-10.0.1.1-2.sh.REL.tar

Como indicadores de compromiso (IoC), Cisco insta a los clientes a utilizar el comando CLI «cat /var/log/messages | grep licenses» en modo experto. Si el resultado del comando incluye «/var/tmp/license.tmp», existe la posibilidad de que la vulnerabilidad haya sido explotada en el dispositivo Cisco Secure FMC.

root@firepower:/home/admin# cat /var/log/messages | grep license
Jul 23 16:16:33 firepower sudo:      www : PWD=/ ; USER=root ; COMMAND=/usr/local/sf/bin/package_info.pl /var/tmp/license.tmp --lsm
Ciberseguridad

En conjunto, Cisco ha actualizó su aviso para CVE-2026-20079 (puntaje CVSS: 10.0), una falla crítica de omisión de autenticación que afecta al software Cisco Secure FMC, para incluir una segunda ID de error («CSCwt95974»), los mismos indicadores de compromiso y correcciones urgentes.

Sin embargo, la compañía dijo que no tiene conocimiento de una explotación maliciosa de esta vulnerabilidad. Dado que CVE-2026-20079 permite la ejecución de archivos de script ejecutables arbitrarios para obtener acceso de root, la inclusión del mismo indicador /var/tmp/license.tmp indica que los actores de amenazas podrían posiblemente encadenar los dos fallos para la ejecución del código.

A la luz de la explotación activa, se recomienda a las agencias del Poder Ejecutivo Civil Federal (FCEB) que apliquen las correcciones antes del 1 de agosto de 2026.

Los agentes de inteligencia artificial de Android de código abierto podrían permitir que el texto de la pantalla invisible ejecute código en las PC host

Una aplicación de Android que puede dibujar sobre otras ventanas y escribir en un almacenamiento compartido puede enviar instrucciones al agente de inteligencia artificial que maneja ese teléfono, en un texto que ningún ojo humano verá jamás. Dos pasos más y la misma aplicación ejecutará comandos en la PC que controla al agente.

Los investigadores demostraron esa cadena, además de otros seis ataques, contra cinco marcos de agentes móviles de código abierto: AppAgent, AppAgentX, Mobile-Agent-v3, Open-AutoGLM y MobA. Todos cayeron al menos a seis de los siete.

El papel subió en arXiv el 1 de julio y fue revisado el 14 de julio. Los autores están en la Universidad Simon Fraser, la Universidad China de Hong Kong, la Universidad de Shandong y el Laboratorio Xingtu de la empresa de seguridad china QAX.

Nada aquí tiene un CVE, y el primer autor Zidong Zhang dijo Las noticias de los piratas informáticos el equipo no tiene evidencia de que las técnicas se hayan utilizado fuera de un entorno controlado. Hacker News revisó los cinco marcos y encontró las rutas de captura de pantalla, la llamada de shell y el respaldo de transmisión que el periódico describe todavía en sus ramas principales a partir del 17 de julio.

Zhang dijo que el equipo envió un correo electrónico privado a los mantenedores afectados antes de publicar la preimpresión y «no ha recibido respuesta hasta la fecha».

La escalada es la parte menos exótica. AppAgent’s controlador ejecuta subprocess.run(adb_command, shell=True) y crea entradas de texto colocando la salida del modelo directamente en el texto de entrada del shell adb {input_str}. La lista del periódico muestra que la función no tiene ningún tipo de desinfección.

El código en vivo funciona marginalmente mejor y no es suficiente: elimina espacios y comillas simples antes de interpolar, y deja el resto de los metacaracteres del shell en paz. No;, no &, no >. Entonces, una cadena que el modelo lee en una pantalla y escribe diligentemente es dividida por el shell del host, y la mitad posterior se ejecuta en el cuadro de Windows del operador.

Una carga útil diseñada para iniciar calc.exe hizo exactamente eso en 20 de 20 pruebas contra AppAgent, AppAgentX, Mobile-Agent-v3 y MobA. Una ejecución separada de un extremo a otro contra AppAgent utilizó test;pwd>rce_success y escribió el directorio de trabajo del host en un archivo.

Ciberseguridad

Poner esa cuerda delante del modelo es una carrera de archivos. Abrir-AutoGLM ejecuta screencap -p /sdcard/tmp.png y luego un adb pull por separado. Agente-móvil-v3 escribe en un /sdcard/screenshot.png fijo y duerme medio segundo entre los dos. AppAgentX escribe en /sdcard/ con nombres de archivo con marca de tiempo que llevan un contador de pasos incremental, un patrón que un atacante puede observar. AppAgent enviado configuración.yaml todavía tiene como valor predeterminado su directorio de captura de pantalla /sdcard.

Los investigadores calcularon esa brecha entre los marcos entre 50 y 500 ms, con un promedio de alrededor de 210 ms en 100 ejecuciones. Un servicio en segundo plano que sondea cada 5 a 10 ms tiene espacio para bloquear un archivo, volver a pintar el PNG y soltarlo antes de que el agente lo recopile. La manipulación aterrizó 19/20 a 20/20 contra cuatro de los cinco.

Para ampliar aún más la ventana, le mostraron al agente una superposición invisible que decía que se estaba ejecutando una sincronización de red y le pedían que esperara tres segundos. La modelo lo creyó.

Los seis modelos de visión que los investigadores probaron leyeron texto con una opacidad del 2% en al menos 18 de 20 ensayos de laboratorio. El documento sitúa ese nivel por debajo de la detección humana típica bajo una visión normal. GPT-4o, Claude Opus 4.5, Gemini 3 Pro y GLM-4V obtuvieron 20 sobre 20. Los números no aumentan a medida que el texto se vuelve más visible, porque comienzan en el techo.

AutoGLM-Phone, un modelo 9B que se ejecuta en el propio dispositivo, fue el más débil de los seis con 18 de 20. La visión humana aplica un umbral. La captura de pantalla no.

La asimetría también tiene una versión de hardware. Los teléfonos redondean sus esquinas y hacen agujeros para las cámaras, pero el búfer de cuadros permanece rectangular, por lo que los píxeles representados en esas regiones se ubican debajo del bisel y aparecen en cada captura de pantalla. En un Pixel 4, eso deja alrededor de 78 píxeles de ancho oculto en una esquina, suficiente para un comando corto, y los cinco agentes leen cargas útiles.

Un tercer truco evita por completo el sigilo: un servicio de accesibilidad coloca una actividad de inicio de sesión falsa sobre la aplicación real y permite que el agente escriba las credenciales del usuario en ella. Una persona podría dudar ante una solicitud de contraseña inesperada. Ninguno de los cinco lo hizo en 100 ensayos.

Nadie autenticó el teclado.

Los agentes no tienen un canal autorizado para acceder a un teléfono, por lo que reutilizan los de depuración, y de ahí sale el ataque más barato del conjunto. Open-AutoGLM codifica en base64 el texto que escribe y lo dispara en ADB_INPUT_B64, una transmisión implícita recogida por Teclado BADuna herramienta de automatización de pruebas creada para aceptar texto de cualquier cosa que lo transmita.

Ese es su propósito documentado, y aún se mantiene, con una Prelanzamiento de abril lleva una solución de Android 16. ADB Keyboard hace lo que promete su README. Los agentes son los que convirtieron un arnés de prueba en una tubería de entrada de producción.

Mobile-Agent-v3 mantiene una lista de permitidos estrecha: las letras, los dígitos y la puntuación común van a través del texto de entrada del shell adb, y todo lo demás, es decir, cualquier carácter que no sea ASCII, sale un carácter a la vez a través de ADB_INPUT_TEXT. Moba es más contundente. Su type_text prueba toda la cadena con text.isascii(), por lo que un emoji o una letra acentuada en cualquier parte de un mensaje envía el mensaje completo a través de la transmisión en una sola toma.

Cualquier aplicación que registre la misma acción recibe la misma carga útil y no necesita permiso para hacerlo, por lo que nada advierte al usuario. Cuando un atacante tiene accesibilidad, TYPE_VIEW_TEXT_CHANGED entrega el mismo texto en texto plano, incluidos los campos de contraseña, en los cinco.

Las condiciones previas son reales. Esto requiere una aplicación ya instalada, un agente en mitad de la tarea y la depuración USB o inalámbrica habilitada. El software afectado son herramientas de desarrollo de código abierto, no el asistente integrado en un teléfono estándar.

Los agentes propios, incluidos Bixby de Samsung y XiaoAi de Xiaomi, estaban fuera de alcance, al igual que iOS. Zhang hizo una advertencia: varios de los ataques necesitan permisos mínimos de Android, y uno no necesita ninguno en absoluto, lo que, según él, reduce la barrera para un atacante motivado.

Una variante tampoco necesita ninguna aplicación maliciosa. Debido a que una carga útil puede viajar en los canales de crominancia de una imagen en lugar de su brillo, un atacante que nunca toque el dispositivo podría enterrar una en una imagen y dejar que el propio agente de la víctima la capture desde una aplicación de mensajería. Los investigadores lo llaman una extensión en lugar de un resultado medido. También es la única versión sin paso de instalación.

Correcciones, y una que no existe.

Dos de los cinco ya muestran cómo es el derecho. MobA transmite capturas de pantalla a través de salida ejecutiva y nunca tiene un archivo del lado del dispositivo para ejecutar. Open-AutoGLM pasa argumentos como listas en lugar de concatenar cadenas, y es el único de los cinco inmune a la inyección de comandos del host.

Ningún proyecto acierta en ambos. Ninguna de las correcciones siguientes requiere tocar el modelo:

  • Soltar shell=Verdadero. Pase listas argv, para que los metacaracteres permanezcan literales.
  • Transmita capturas de pantalla en lugar de escribir y luego extraer. Sin archivo del lado del dispositivo, sin ventana TOCTOU.
  • Coloque un permiso a nivel de firma en la transmisión de entrada o utilice intenciones explícitas.
  • Diferencia la actividad en primer plano antes y después de cada acción y mantén una lista de paquetes permitidos por tarea.
  • Ejecute la mejora del contraste en las capturas de pantalla antes de que el modelo las vea. Parcial, no es una solución.

La defensa obvia es un mensaje de confirmación sobre acciones sensibles, y Open-AutoGLM incluye uno. Se activa cuando el modelo decide que una acción es sensible. Los ataques de percepción reescriben ese juicio, razón por la cual el artículo califica el aviso como insuficiente contra la inyección subliminal, la suplantación de la interfaz de usuario y la manipulación de capturas de pantalla.

Ciberseguridad

Contra la difusión y el rastreo de accesibilidad, no hace nada en absoluto, porque no hay ninguna acción para confirmarlo. El texto ya desapareció. En cuanto a la inyección de esquinas y recortes, los investigadores son contundentes: «no existe una solución basada en software sencilla y eficaz». Enmascarar esquinas es una solución para un problema de hardware.

No hay donde reportarlo

El silencio tiene una estructura detrás. Zhang dijo que el equipo recurrió a un correo electrónico privado porque los proyectos no tienen un canal dedicado para informar vulnerabilidades y The Hacker News no encontró ninguna política de seguridad publicada en ninguno de los cinco repositorios.

El documento agrega que Tencent y Alibaba fueron los primeros en contactarse, y que los proyectos de código abierto de grado de investigación se encuentran fuera del alcance habitual del Centro de Respuesta de Seguridad.

Compare eso con el de Microsoft Informe de mayo sobre el kernel semánticosu marco de agente, donde el mismo patrón de salida del modelo que llega a un shell produjo CVE-2026-25592, CVE-2026-26030 y una versión parcheada. La versión de una sola línea de Microsoft se transfiere aquí sin modificaciones: «su LLM no es un límite de seguridad».

La mitad superpuesta no es un terreno nuevo. Wu et al. impulsó la inyección rápida a través de ventanas superpuestas contra AppAgent y Mobile-Agent en mayo de 2025, y Ding et al. seguido en octubre con indicaciones que aparecen solo mientras un agente está mirando.

La sección de trabajo relacionado de este artículo no cita ninguno de los dos y omite por completo la literatura sobre seguridad de agentes móviles. Lo que agrega es el otro extremo de la cadena: fuera de la pantalla, a través del archivo, hasta el host.

Lo que deja la parte incómoda. Open-AutoGLM tiene más de 25.000 estrellas de GitHub y su LÉAME Lo guía para habilitar la depuración USB, cargar el teclado y entregarle sus entradas. Siga los documentos exactamente y habrá creado todas las condiciones previas que necesitan los ataques medidos, excepto la aplicación maliciosa en sí. La guía de configuración es el resto del modelo de amenazas.

Las fallas de RabbitMQ podrían filtrar secretos de OAuth y exponer metadatos de colas entre inquilinos – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de dos fallas relacionadas con el control de acceso que afectan el servicio de intermediación de mensajes RabbitMQ y que podrían permitir a los atacantes filtrar secretos del cliente OAuth, exponer la infraestructura de mensajería empresarial a riesgos de adquisición y eludir los límites de los inquilinos.

El equipo de seguridad de Miggo, que descubierto e informó las fallas, dijo que uno «filtra el secreto OAuth confidencial del corredor a un atacante no autenticado en una sola solicitud, un camino directo hacia la toma total del control del corredor en las configuraciones que usan ese secreto». La segunda vulnerabilidad permite que cualquier usuario que haya iniciado sesión lea silenciosamente los datos de otros inquilinos.

Se dice que ambas deficiencias han estado presentes en el código base desde principios de 2024, lo que afecta las líneas de lanzamiento de RabbitMQ desde 3.13.0 y posteriores. Se solucionaron en las versiones 4.3.0, 4.2.6, 4.1.11, 4.0.20 y 3.13.15. No hay evidencia de explotación activa de ninguna de las vulnerabilidades antes de la divulgación pública.

Ciberseguridad

A continuación se muestra una breve descripción de los dos defectos:

  • CVE-2026-57219 (Puntuación CVSS: 8,7): un punto final API HTTP obsoleto («GET /api/auth») que revela el secreto del cliente en instalaciones de RabbitMQ que tenían OAuth 2 configurado para usar la clave de configuración management.oauth_client_secret, lo que permite a un atacante intercambiarlo por un token de administrador y obtener control total de cada mensaje, cola, usuario y configuración del agente.
  • CVE-2026-57221 (Puntuación CVSS: 5,3): falta una autorización que permite a cualquier usuario autenticado que pueda conectarse a un host virtual enumerar todas las colas e intercambiar nombres en ese host virtual y leer el recuento de mensajes de la cola y el recuento de consumidores, independientemente de sus permisos reales.

«La verificación de autorización del punto final estaba codificada para permitir siempre la solicitud, a diferencia de cualquier otro punto final de gestión sensible», dijo Miggo sobre CVE-2026-57219. «El riesgo es mayor cuando el puerto de administración es accesible a través de una red que no es de confianza: configuraciones de nube o de múltiples inquilinos, o una interfaz de usuario de administración expuesta accidentalmente a Internet».

Además de aplicar parches a las últimas versiones, se recomienda rotar el secreto del cliente OAuth si se puede acceder a la interfaz de administración a través de Internet, limitar el acceso al puerto 15672 para evitar que se pueda acceder a la interfaz de administración a través de la red, separar los inquilinos por host virtual e implementar reglas de firewall para bloquear el acceso al punto final vulnerable en instancias sin parches.

La divulgación se produce cuando los mantenedores de RabbitMQ abordaron dos fallas de gravedad crítica que podrían resultar en un Omisión de autenticación de cliente TLS (Puntuación CVSS: 9,1) y permitir que un atacante en una posición de adversario en el medio (AitM) Forjar respuestas del conjunto de claves web JSON (JWKS) y hacer que el corredor acepte JWT arbitrarios (puntuación CVSS: 9,2).

11 antiguas cuñas UEFI de Linux firmadas por Microsoft podrían permitir a los atacantes evitar el arranque seguro – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han descubierto 11 aplicaciones antiguas de Interfaz de firmware extensible unificada (UEFI) firmadas por Microsoft de las que se podría abusar para evitar el arranque seguro en la mayoría de los sistemas que utilizan el estándar de firmware moderno.

«Un atacante que explote una de estas aplicaciones vulnerables puede ejecutar código que no es de confianza durante el arranque del sistema, permitiendo la implementación de bootkits UEFI maliciosos u otro malware», dijo el investigador de ESET Martin Smolár. dicho en un informe publicado hoy.

Los cargadores de arranque UEFI exponen cualquier máquina basada en UEFI que confíe en Microsoft «Corporación Microsoft UEFI CA 2011«Certificado de autoridad certificadora (CA) UEFI de terceros, independientemente del sistema operativo instalado. El certificado se utiliza para firmar componentes de arranque de terceros destinados a ejecutarse bajo arranque seguro. Expiró el 27 de junio de 2026 y ha sido reemplazado por Microsoft UEFI CA 2023 y Microsoft Option ROM UEFI CA 2023.

El shim es un gestor de arranque UEFI liviano y de código abierto que actúa como intermediario entre el firmware de la placa base de una computadora y el sistema operativo Linux. Su objetivo principal es permitir que las distribuciones de Linux se inicien cuando el arranque seguro está habilitado. Vale la pena señalar que el shim en sí está firmado con una clave en la que confía el firmware, principalmente una firma de Microsoft, ya que sus certificados vienen preinstalados en dispositivos basados ​​en UEFI.

Ciberseguridad

La secuencia procede de la siguiente manera: el firmware UEFI carga el shim y valida su firma con la CA de Microsoft almacenada en el firmware. Luego, el shim valida el cargador de arranque de segunda etapa (en la mayoría de los casos, GRUB 2) con su propio certificado de proveedor integrado. GRUB 2 finalmente valida el kernel utilizando el mismo certificado de proveedor.

La compañía eslovaca de ciberseguridad dijo que los shims, obsoletos pero confiables, pueden explotarse para ejecutar código arbitrario cuando se inicia el sistema, lo que permite a los delincuentes implementar kits de arranque UEFI como Bootkitty, HybridPetya o BlackLotus incluso cuando las protecciones de arranque seguro están habilitadas.

Desde entonces, Microsoft ha revocado los gestores de arranque UEFI del proyecto shim de código abierto, principalmente de la versión 0.9 y anteriores, como parte de su Actualización del martes de parches de junio de 2026 tras la divulgación responsable a principios de febrero. La lista de los cargadores de arranque afectados se encuentra a continuación:

  • Spyrus WTGCreator del cargador de cuñas UEFI (0.7 o inferior)
  • RedHat RedHat Enterprise Linux (7.2) desde el cargador de cuñas UEFI (0.9)
  • RedHat CentOS (7.2) del cargador de cuñas UEFI (0.9)
  • Software Baramundi baramundi Management Suite (hasta 2024R1) desde UEFI shim loader (0.8)
  • WhiteCanyon/Blancco WipeDrive (8.0.0 a 8.1.3) del cargador de cuñas UEFI (0.7)
  • Junta de Examen de Matriculación de Finlandia Abitti 1 (1.0) del cargador de cuñas UEFI (0.8)
  • NTC IT ROSA, LLC ROSA Linux (R10, R9) del cargador de cuñas UEFI (0.9)
  • Oracle America, Inc. OracleLinux (7.2) del cargador de cuñas UEFI (0.9)
  • PC-Doctor, Inc. Centro de servicio PC Doctor (15, 16) del cargador de cuñas UEFI (0.9)
  • OpenSuse OpenSuse UEFI Cargador de cuñas (0.9)
  • OpenSuse OpenSuse Shim (2.1) del cargador UEFI Shim (0.9)

Una consecuencia de esta laguna jurídica es que un atacante podría aprovechar estos cargadores de arranque shim susceptibles para eludir los mecanismos de seguridad más nuevos haciendo uso de la técnica de ataque «traiga su propio controlador vulnerable» (BYOVD) para ejecutar código arbitrario durante la fase de arranque inicial, incluso antes de que se inicialice el sistema operativo.

Los sistemas Linux también vienen con una característica de seguridad llamada lista de permitidos de clave de propietario de máquina (MOK) que permite a los usuarios autorizar la carga de controladores no firmados mientras UEFI Secure Boot está activo. Aunque se introdujo una lista de denegados MOK en la versión 0.9 de shim como una forma de revocar certificados de firma antiguos asociados con un binario UEFI vulnerable y volver a firmar versiones parcheadas.

En este contexto, un atacante podría reemplazar el shim actualizado de la víctima con un shim UEFI más antiguo firmado por Microsoft y evitar la aplicación de la lista de denegados MOK aprovechando el hecho de que la lista de permitidos todavía confía en el certificado antiguo. Esto, a su vez, podría permitir que el shim de un atacante cargue binarios vulnerables sin restricciones y obtenga la ejecución de código arbitrario.

Eso no es todo. El ataque también subvierte el Secure Boot Advanced Targeting (SBAT), que está diseñado para revocar componentes de arranque vulnerables en lugar de mantener una enorme lista de bloqueo de hashes criptográficos individuales correspondientes a cada archivo. Dicho de otra manera, el mecanismo se utiliza para actualizar la generación mínima aceptable cada vez que se descubre una vulnerabilidad en un componente de la cadena de arranque. Si un intento de arranque utiliza una versión anterior y vulnerable, el sistema lo bloquea y arroja un error.

El Centro de Coordinación CERT (CERT/CC), en un aviso emitido el mes pasado, dijo que los cargadores de arranque específicos del proveedor no se han actualizado para abordar las vulnerabilidades en el proyecto ascendente después de que se conocieron públicamente y se solucionaron.

«Como resultado, los cargadores de arranque vulnerables permanecieron firmados y confiables para los sistemas de arranque seguro porque no habían sido revocados a través de la lista de revocación DBX firmada por Microsoft», dijo. anotado. «Esto creó una exposición a largo plazo en la cadena de suministro en la que los componentes de arranque obsoletos y vulnerables aún podían ejecutarse en sistemas completamente parcheados».

Ciberseguridad

El resultado es que un atacante con privilegios administrativos o la capacidad de modificar el proceso de arranque podría abusar de uno de los cargadores de arranque vulnerables mencionados anteriormente para eludir las protecciones de arranque seguro y ejecutar código arbitrario antes de que se cargue el sistema operativo, allanando el camino para una persistencia arraigada que puede sobrevivir a los reinicios del sistema operativo y, en algunos casos, a su reinstalación.

Debido a que todo esto ocurre antes de que se inicialicen el sistema operativo y los productos de seguridad, el código malicioso ejecutado a través de los cargadores de arranque también puede eludir la detección mediante controles de seguridad integrados y soluciones de detección y respuesta de endpoints (EDR).

Los problemas se rastrean bajo los identificadores CVE. CVE-2026-8863 y CVE-2026-10797, este último haciendo referencia a un problema de larga data en una corrección que permitía omitir el mecanismo de revocación basado en certificados modificando el encabezado de firma del gestor de arranque de la segunda etapa.

ESET ha advertido que la caducidad del certificado «Microsoft Corporation UEFI CA 2011» no influye en el proceso de verificación de Secure Boot siempre que los gestores de arranque firmados con el certificado caducado no sean revocados explícitamente mediante hash.

«Lo que hace que estas viejas correcciones sean peligrosas no es una vulnerabilidad novedosa, es que no se necesita ninguna vulnerabilidad nueva para evitar el arranque seguro UEFI», dijo ESET. «Un atacante no necesita primitivos de explotación complicados: solo una copia de un binario shim antiguo, aún confiable, pero no revocado y una comprensión básica de cómo funcionan los shims UEFI. Eso es suficiente para eludir una característica de seguridad tan esencial como UEFI Secure Boot».

Seis nuevas fallas de U-Boot podrían permitir que imágenes maliciosas bloqueen dispositivos o ejecuten código en el arranque – CYBERDEFENSA.MX

Investigadores de la firma de seguridad de firmware Binarly han encontrado seis nuevas fallas en U-Boot, el pequeño programa que inicia hardware tan variado como enrutadores domésticos, cámaras inteligentes y chips de administración dentro de servidores de centros de datos.

Cuatro de los errores pueden bloquear un dispositivo. Los otros dos podrían permitir que un atacante que introduzca una imagen maliciosa delante del gestor de arranque ejecute su propio código, antes de que el dispositivo haya confirmado que el software es genuino.

Esa última parte es el punto. Un gestor de arranque se ejecuta antes que el sistema operativo, por lo que una falla aquí puede socavar todo lo que se carga después. Los seis errores se detectan mientras U-Boot todavía está leyendo una imagen que no es de confianza, antes de verificar la firma.

Lo que encontró Binarly

U-Boot puede agrupar un kernel, un árbol de dispositivos, un disco ram y otros componentes de arranque en un solo paquete, un FIT (árbol de imágenes planas), y verifica la firma digital de ese paquete antes de ceder el control.

Binarly buscó puntos débiles en ese cheque y encontró seis. La mayor parte del código vulnerable ha estado en U-Boot desde v2013.07, Binariamente diceen más de 50 versiones estables, y también se encuentra en los firmwares de muchos proveedores integrados sobre U-Boot.

Los errores se rastrean como avisos de Binarly. BRLY-2026-037 a BRLY-2026-042. Aún no se han asignado identificadores CVE. Se dividen en dos grupos: dos que pueden ejecutar código y cuatro que sólo fallan.

Ciberseguridad

Los dos son BRLY-2026-037 y BRLY-2026-038, y ambos rastrean hasta un valor no verificado. U-Boot llama a fdt_get_name, una búsqueda en la biblioteca de análisis del árbol de dispositivos que toma prestada, y en una imagen con formato incorrecto, esa búsqueda devuelve un puntero nulo y una longitud negativa. U-Boot usa ambos sin verificar ninguno.

Un error sigue al puntero nulo en una copia de memoria que, en dispositivos donde está asignada la dirección cero, se convierte en un desbordamiento del búfer de pila. El otro introduce la longitud negativa en la aritmética de punteros que retrocede hasta que sobrescribe una dirección de retorno guardada. En el diseño de memoria correcto, cualquiera de los dos puede controlar manualmente la codificación proporcionada por el atacante.

Los otros cuatro sólo bloquean el gestor de arranque. BRLY-2026-039 y BRLY-2026-041 leen más allá del final de la imagen confiando en un tamaño o desplazamiento que controla el atacante. BRLY-2026-040 elimina la referencia a un puntero nulo que un formato de imagen anterior devuelve sin marcar. BRLY-2026-042 agota la pila, activada por una imagen profundamente anidada que impulsa un paso de validación temprano para llamarse a sí mismo hasta que se agote.

Binarly publicó una imagen de prueba de concepto y pasos de reproducción para cada defecto y los demostró frente a compilaciones estándar de U-Boot. No se ha informado de explotación en ataques reales.

De los seis, los dos errores de corrupción de memoria son los que se deben priorizar: una falla puede dejar un dispositivo fuera de línea, pero la ejecución del código en el arranque podría subvertir toda su cadena de confianza.

que mal se pone

En el peor de los casos, recuperar un dispositivo que no arranca significa acceder físicamente y actualizar su chip de memoria con una imagen limpia. La ejecución del código es peor. El código que se ejecuta tan temprano se encuentra debajo del sistema operativo, donde las herramientas de seguridad comunes pueden no verlo.

El problema para un atacante es la entrega: estos errores solo aparecen una vez que una imagen maliciosa llega a la ruta de inicio, que generalmente requiere acceso físico o un punto de apoyo privilegiado. Ese punto de apoyo no siempre es local.

En En trabajos anteriores sobre los controladores de administración del servidor de Supermicro, el mismo investigador de Binarly demostró que un atacante con acceso remoto a la interfaz de administración podría abusar del propio proceso de actualización del dispositivo para mostrar una imagen maliciosa, sin tocar el hardware.

que hacer

Aún no existe una versión estable con la solución, por lo que los proveedores y mantenedores de productos basados ​​en U-Boot no deberían esperar: extraiga las correcciones ascendentes ahora, siguiendo los enlaces de confirmación en cada aviso de Binarly, y realice un seguimiento por ID de aviso, ya que no existen CVE.

U-Boot fusionó los seis parches en junio, pero la versión de julio (v2026.07) ya se había congelado en abril, por lo que se envió sin ellos; la próxima versión, v2026.10, no saldrá hasta octubre.

Ciberseguridad

Todos los demás ejecutan un dispositivo que otra persona construyó con U-Boot. Para ellos, la solución debe llegar como una actualización de firmware del proveedor del producto. Eso es lo que hay que tener en cuenta.

Esta verificación exacta ha fallado antes. La misma lógica de firma fue atacada meses antes por CVE-2026-33243que U-Boot parchó en abril; El gestor de arranque barebox relacionado, que utiliza las mismas herramientas de imagen, también se vio afectado.

En ese error, una propiedad destinada solo a enumerar lo que cubre la firma no estaba firmada, por lo que una imagen manipulada podría intercambiarse en partes que nunca fueron verificadas. El asistente detrás de los dos peores errores aquí, fdt_get_name, proviene de libfdt, la biblioteca de árbol de dispositivos aplanados que U-Boot comparte con el kernel de Linux, barebox y otros. El mismo error de devolución no comprobada puede surgir en cualquier lugar donde se utilice el código.

LogoFAIL, que THN cubrió en 2023, era un conjunto de errores de análisis de imágenes en el firmware de la PC que permitían que el código del atacante se ejecutara durante el arranque, antes de que Secure Boot pudiera verificar algo, en casi todas las principales marcas de PC. La firma recibe toda la atención; los insectos siguen aterrizando en las tuberías que corren delante de él.

Y como demostró BootHole en 2020, cuando una falla del gestor de arranque rompió el arranque seguro en todo el ecosistema, escribir el parche es la parte fácil. La parte lenta es introducirlo en millones de dispositivos que ejecutan la copia de U-Boot de otra persona.

Las fallas en los enlaces simbólicos de GhostApproval podrían permitir que los repositorios maliciosos ejecuten código en agentes de codificación de IA

Investigadores de Fenómeno descubrió que una falla en seis populares asistentes de codificación de IA permite que un proyecto de código trampa tome silenciosamente el control de la computadora de un desarrollador. El asistente pide permiso para editar un archivo que parece inofensivo, pero la escritura llega a uno sensible.

Las herramientas afectadas son Amazon Q Developer, Claude Code de Anthropic, Augment, Cursor, Google Antigravity y Windsurf. Wiz llama al patrón Aprobación fantasma y lo publicó el 8 de julio.

Tres de los seis han enviado correcciones, dos no, y Anthropic niega que se trate de un error. Las más expuestas son las herramientas que cambian archivos antes de que puedas intervenir.

Cómo funciona el ataque

El ataque abusa de una antigua característica de Unix llamada enlace simbólicoo enlace simbólicoque los asistentes no logran comprobar. Un enlace simbólico apunta silenciosamente a otro archivo en otra parte del disco, por lo que escribir en él en realidad escribe en el destino.

Wiz creó un repositorio malicioso con un enlace simbólico llamado project_settings.json que realmente apunta al archivo de inicio de sesión SSH de la víctima, ~/.ssh/authorized_keys. El archivo README del repositorio le dice al asistente que agregue «una línea» a project_settings.json, y esa línea es la clave SSH del atacante vestida como una configuración inofensiva.

Pídale al agente que «configure el espacio de trabajo» o «siga el archivo README» y escribirá la clave directamente a través del enlace simbólico en el archivo de inicio de sesión. A partir de ahí, si la máquina ejecuta un servicio SSH al que el atacante pueda acceder, podrá iniciar sesión sin contraseña.

Una segunda versión del truco escribe en el archivo de inicio de su shell, ~/.zshrc, que el shell ejecuta la próxima vez que abre una terminal, por lo que no se necesita SSH. No hay señales de que nada de esto haya sido utilizado en ataques reales; Wiz lo presenta como investigación.

El cuadro de aprobación muestra algo incorrecto

Los trucos de enlaces simbólicos tienen décadas de antigüedad. El enlace simbólico es sólo la entrega; el verdadero fracaso es el cuadro de aprobación. En GhostApproval, se encuentra ese cuadro.

Al probar Claude Code, Wiz descubrió que el agente ya había detectado el objetivo real en su propio razonamiento, y señaló que project_settings.json era, en sus palabras, «en realidad un archivo de configuración zsh». Sin embargo, el cuadro mostrado al desarrollador solo mencionaba el archivo inofensivo.

Ciberseguridad

Hace clic en Aceptar, creyendo que está editando un archivo de configuración local, y la escritura llega a su archivo de inicio de shell o a sus claves SSH. Wiz llama a esto un bypass de consentimiento informado: el humano todavía está en el bucle, pero el bucle les muestra algo incorrecto.

Algunas herramientas son peores: saltan la puerta por completo, por lo que nunca hay un momento para intervenir. Windsurf escribe el archivo en el disco antes de que aparezcan los botones Aceptar y Rechazar, por lo que el mensaje es solo un botón deshacer y la clave ya está en su lugar.

Augment no muestra ningún diálogo y Wiz lo demostró en silencio, leyendo un archivo de credencial de AWS que se encontraba fuera del proyecto. Sin embargo, las herramientas que todavía muestran un mensaje no son más seguras; el mensaje simplemente nombra el archivo incorrecto.

¿Qué herramientas se ven afectadas?

Wiz informó del problema a los seis proveedores. Aquí es donde se encuentra cada uno al momento de la publicación:

Herramienta Estado que hacer
Desarrollador de Amazon Q Corregido en el servidor de idiomas 1.69.0 (CVE-2026-12958) Actualizar. Se instala automáticamente para la mayoría de los usuarios y al volver a cargar el IDE se activa.
Cursor Fijado en v3.0 (CVE-2026-50549) Actualización desde el administrador de extensiones.
Antigravedad de Google Fijo (CVE pendiente) Actualizar a la versión actual.
Aumentar Admitido; aún no hay solución No apuntes a repositorios en los que no confíes.
windsurf Admitido; aún no hay solución No apuntes a repositorios en los que no confíes.
Código Claude antrópico Cuestionado; Las versiones actuales advierten. Actualice y lea la advertencia del enlace simbólico antes de aceptar.

Anthropic rechazó la clasificación y le dijo a Wiz que el escenario se encuentra «fuera de nuestro modelo de amenaza»: el desarrollador eligió confiar en la carpeta al iniciar la sesión y luego aprobó la edición, por lo que la decisión fue suya.

También dijo que la advertencia de enlace simbólico de Claude Code se envió a principios de febrero, antes del informe privado de Wiz, como un refuerzo de rutina en lugar de una solución, y que un «sin comentarios» anterior era una respuesta automática.

De los seis proveedores, Anthropic es el único que dice que esto no es un error; Se enviaron tres correcciones y dos están trabajando en ellas. Sin embargo, la pregunta que plantea su postura es real, y no solo Anthropic debe responder: ¿hasta dónde debe llegar un agente de codificación para proteger a un desarrollador que ya ha confiado en un repositorio malicioso?

Más allá de los parches, algunos hábitos reducen el riesgo, independientemente de la herramienta que utilice. Ejecute el agente con acceso limitado a archivos o dentro de un entorno limitado o contenedor. Revise el archivo README de un repositorio y los archivos de configuración ocultos antes de permitir que un agente lo «configure».

Y después de trabajar en un repositorio desconocido, verifique los archivos a los que se dirige el ataque, que se encuentran fuera del proyecto y, por lo tanto, no aparecerán en el estado de git: su archivo de inicio de shell, sus claves SSH y la propia configuración de su herramienta de inteligencia artificial. Verificar sus marcas de tiempo, por ejemplo, con ls -la ~/.zshrc ~/.ssh/authorized_keys, muestra si algo cambió mientras el agente se estaba ejecutando.

Ciberseguridad

El consejo de Wiz para los fabricantes de herramientas es breve: resuelva el enlace simbólico y muestre el destino real antes de preguntar, marque cualquier escritura que termine fuera de la carpeta del proyecto y nunca toque el disco hasta que el usuario lo haya aprobado.

Un defecto compartido, no el desliz de un proveedor

En mayo, Adversa AI publicó SymJackel mismo patrón de enlace simbólico y aprobación contra seis agentes de codificación, incluidos Claude Code, Cursor, GitHub Copilot y Grok Build.

Dos equipos independientes descubrieron que esto apunta a una debilidad de diseño compartida, no a un desliz de un proveedor: estos agentes siguen un enlace simbólico utilizando operaciones de archivos ordinarias, luego solicitan aprobación según la ruta que se les entregó, no la ruta en la que llega la escritura.

El solapamiento llega incluso al CVE. El propio aviso de Cursor por su error de enlace simbólico acredita tanto a Wiz como a Cato AI Labs, cuyo trabajo anterior The Hacker News cubrió como DuneSlide.

Los archivos en los que confía un asistente de IA ya no son solo código. Para estos agentes, sirven también como instrucciones que el agente sigue y caminos que sigue, y dan forma a lo que muestra el cuadro de aprobación. El boletín de AWS también cubre una falla separada de Amazon Q, CVE-2026-12957, donde un repositorio envenenado podría cargar automáticamente un archivo de configuración y ejecutar comandos para robar las claves de AWS de un desarrollador una vez que se confiaba en el espacio de trabajo.

La técnica exacta de GhostApproval todavía está bajo investigación, pero el patrón más amplio ya está apareciendo en la naturaleza: repositorios que contienen archivos que dirigen a los agentes de IA a comportamientos inseguros.

Como informó THN ​​en junio, el gusano Miasma colocó archivos de configuración de agentes de IA en un repositorio de Microsoft Azure para que su carga útil se ejecutara en el momento en que un desarrollador abriera el proyecto en Claude Code, Cursor o Gemini. En respuesta, GitHub deshabilitó los 73 repositorios de Microsoft afectados.

«Human in the loop» sólo te protege si el loop dice la verdad. A medida que estos asistentes obtienen más libertad para leer y escribir archivos por su cuenta, un cuadro de aprobación que nombra el destino incorrecto no es una protección sino una responsabilidad, y tratar un repositorio engañoso como un problema puramente del usuario pone el peso en la persona que tiene menos capacidad para ver el intercambio.

Defectos críticos del cursor podrían permitir que la inyección rápida escape del sandbox y ejecute comandos – CYBERDEFENSA.MX

Dos fallas en Cursor, un editor de código de IA, podrían permitir que un único mensaje de apariencia ordinaria salga del entorno de pruebas de seguridad del editor y ejecute cualquier comando en la computadora de un desarrollador. No hay ningún clic del que enamorarse ni ningún cuadro de aprobación que ignorar.

Cato AI Labs encontró la pareja y les puso nombre tobogán de dunas. Se les rastrea como CVE-2026-50548 y CVE-2026-50549, ambos con una calificación de 9,8 sobre 10 (o 9,3 según la escala CVSS 4.0 más nueva).

La solución ya está disponible. Ambos errores se corrigen en Cursor 3.0, lanzado el 2 de abril, y todas las versiones anteriores a la 3.0 se ven afectadas. El creador de Cursor dice que más de la mitad de las empresas Fortune 500 usan la herramienta, así que si la ejecutas, actualízala ahora.

Para qué servía el arenero y cómo se rompió

A partir de la línea 2.x, Cursor ejecuta los comandos de terminal que su agente de IA emite dentro de una caja de arena de forma predeterminada: una caja cerrada que limita lo que esos comandos pueden tocar, por lo que una instrucción perdida no puede arruinar la máquina.

DuneSlide se trata de salir de esa caja. La forma de entrar es la inyección inmediata. El atacante nunca escribe en su cursor. Colocan instrucciones dentro de algo que su agente lee en su nombre, como un servicio conectado a través del Protocolo de contexto modelo (MCP) o una página devuelta por una búsqueda web.

Ciberseguridad

Usted hace una pregunta normal, las instrucciones ocultas aparecen durante el proceso y, como no necesita clic ni aprobación de su parte, el ataque es de «clic cero».

Ambas fallas usan el mismo truco: hacer que el agente escriba un archivo que no se le debe permitir escribir y luego usar esa escritura para desactivar la zona de pruebas.

  • CVE-2026-50548 Abusa de un entorno. El sandbox permite escrituras en la carpeta de trabajo de un comando, y esa carpeta es un parámetro opcional, directorio_de_trabajo, en la herramienta run_terminal_cmd de Cursor. Cuando el agente lo configura en una ruta no predeterminada, Cursor agrega esa ruta a la lista de escritura permitida sin lugar a dudas. Las instrucciones inyectadas apuntan a un archivo del sistema en lugar del proyecto. Sobrescriba el asistente de sandbox (en macOS, /Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox) y los comandos posteriores se ejecutarán sin ningún sandbox. Los archivos de inicio como ~/.zshrc también funcionan como objetivos.
  • CVE-2026-50549 abusa del control de seguridad. Antes de escribir, Cursor resuelve accesos directos (enlaces simbólicos) para confirmar que el destino real se encuentra dentro de su proyecto. El error es la alternativa: cuando esa verificación falla, porque el objetivo no existe o el atacante elimina el acceso de lectura de una carpeta en la ruta, Cursor se da por vencido y confía en la ruta del acceso directo dentro del proyecto. Un atacante crea un acceso directo que apunta fuera del proyecto, fuerza que la verificación falle y Cursor escribe directamente en el mismo asistente de sandbox. Mismo escape, diferente puerta.

Una vez que se neutraliza la zona de pruebas, el siguiente comando se ejecuta como usted. Eso significa control de la máquina del desarrollador, además de cualquier espacio de trabajo en la nube o SaaS en el que el editor haya iniciado sesión. Todo se deriva de un mensaje aparentemente inofensivo.

No hay señales de que esto haya sido utilizado en ataques reales. Cato lo presenta como una investigación, no como una campaña activa, y el registro público de vulnerabilidad no muestra ninguna explotación conocida en el momento de su publicación.

Cato informó ambos problemas el 19 de febrero. Según el relato de Cato, Cursor los rechazó cuatro días después, diciendo que su modelo de amenaza no cubría el uso indebido de los servidores MCP, ni siquiera los estándar como el espacio de trabajo oficial de Linear.

Catón se intensificó el 26 de febrero; Cursor reabrió los informes, los clasificó y envió ambas correcciones en 3.0. Los ID CVE se asignaron el 5 de junio.

Ciberseguridad

Cursor publicó el suyo consultivo para el error del enlace simbólico, y su registro NVD está en vivo.

No es el primero, y probablemente tampoco el último.

DuneSlide es el último de una serie de errores de cursor que comienzan con un mensaje envenenado y terminan con la ejecución de código, cada uno de los cuales supera una barrera de seguridad diferente. The Hacker News cubrió las rondas anteriores:

  • CurXecute (CVE-2025-54135, agosto de 2025) provenía del mismo equipo y entonces operaba como Aim Security. Un mensaje de Slack colocado reescribió la configuración ~/.cursor/mcp.json de Cursor y ejecutó comandos incluso después de que el usuario rechazó la edición. Corregido en 1.3.
  • MCPoison (CVE-2025-54136), de Check Point Research, permite a un atacante obtener una configuración de MCP aprobada una vez y luego intercambiar silenciosamente comandos maliciosos sin un segundo mensaje.
  • CVE-2026-26268 (febrero de 2026) escondió un gancho de Git con trampa explosiva en un repositorio que se activó en el momento en que el agente ejecutó un comando de Git. Parcheado en 2.5.

La zona de pruebas en la línea 2.x fue la respuesta de Cursor a esa ola anterior. DuneSlide se trata de escapar de la respuesta.

Cato dice que está revelando fallas similares en otros agentes de codificación y argumenta que el problema es estructural y no una serie de hechos puntuales.

Eso deja una pregunta abierta para cualquiera que envíe un agente que lea la web abierta: si tratar cada entrada como hostil se convierte en la opción predeterminada o sigue siendo una lucha parche por parche.

Los investigadores detallan las fallas de DifyTap en Dify que podrían exponer los chats de IA entre los inquilinos – CYBERDEFENSA.MX

Investigadores de ciberseguridad han revelado detalles de cuatro vulnerabilidades en Dificaruna plataforma de flujo de trabajo agente de código abierto con más de 146.000 estrellas de GitHubque podría permitir a los atacantes leer sigilosamente conversiones de inteligencia artificial (IA) de las aplicaciones de otros clientes sin requerir autenticación.

Las vulnerabilidades han recibido un nombre en código colectivo. DifyTap por Seguridad Zafran.

«Dos eran de gravedad crítica, dos no requerían autenticación y tres tenían un impacto entre inquilinos en el servicio de nube multiinquilino de Dify, permitiendo que los datos de un cliente quedaran expuestos a otro», investigadores Ido Shani y Gal Zaban. dicho.

Los defectos de seguridad podrían haber permitido a los atacantes leer chats privados de IA de las aplicaciones de otros clientes, creando un canal de exfiltración encubierto para cada mensaje y respuesta modelo.

Ciberseguridad

También hicieron posible atravesar la API interna de Plugin Daemon de Dify desde solicitudes no autenticadas y activar llamadas API internas entre inquilinos, así como obtener una vista previa de los documentos cargados por otros inquilinos y filtrar archivos entre usuarios dentro de un inquilino adjuntando el identificador único del archivo de otro usuario.

Por otra parte, Zafran dijo que también descubrió que la pila de análisis de archivos de Dify dependía de una versión de PDFium, una biblioteca C++ de código abierto para renderizado de PDF, que era vulnerable a CVE-2024-5846 (Puntuación CVSS: 8,8), un error de uso después de la liberación que data de hace dos años y que podría permitir a un atacante remoto explotar potencialmente la corrupción del montón a través de un archivo PDF manipulado.

Las vulnerabilidades restantes se enumeran a continuación:

  • CVE-2026-41947 (Puntuación CVSS: 9,1): una vulnerabilidad de omisión de autorización que permite a los usuarios del editor autenticados establecer y habilitar configuraciones de seguimiento para cualquier aplicación, independientemente de la propiedad del inquilino.
  • CVE-2026-41948 (Puntuación CVSS: 9,4): una vulnerabilidad de recorrido de ruta que permite a los usuarios autenticados manipular las solicitudes enviadas a la API REST interna del Plugin Daemon explotando una desinfección insuficiente de la ruta URL y accediendo a puntos finales privados internos.
  • CVE-2026-41949 (Puntuación CVSS: 7,5/5,9): una vulnerabilidad de omisión de autorización en el punto final de vista previa de archivos («/console/api/files/{file_id}/preview») que permite a cualquier usuario autenticado leer hasta 3000 caracteres de cualquier documento cargado en todos los inquilinos y espacios de trabajo utilizando solo el UUID del archivo.
  • CVE-2026-41950 (Puntuación CVSS: 6,5): una vulnerabilidad de omisión de autorización que permite a los usuarios autenticados leer el contenido completo de los archivos cargados por otros usuarios dentro del mismo inquilino al proporcionar un UUID de archivo arbitrario en la matriz de archivos de una solicitud de mensajes de chat.

Las comprobaciones de propiedad de los inquilinos que faltan se pueden aprovechar para redirigir todos los mensajes y respuestas de las aplicaciones de las víctimas a un proveedor de seguimiento LLM controlado por el atacante. Vale la pena señalar que cualquiera puede registrarse libremente para obtener una cuenta Dify.

Ciberseguridad

«En consecuencia, un atacante puede configurar su propio seguimiento para cualquier aplicación a la que pueda acceder como cliente, lo que incluye todas las aplicaciones de acceso público», explicaron los investigadores. «Esto permite a un atacante crear un canal de exfiltración persistente para todos los mensajes y respuestas enviados en la aplicación».

Tras una divulgación responsable, todas las vulnerabilidades excepto CVE-2026-41948 se han abordado en versión 1.14.2que se envió el mes pasado. Se espera que una solución para la falla pendiente esté disponible en la próxima versión de Dify.

«DifyTap demuestra dónde reside el desafío en la visibilidad de las vulnerabilidades, particularmente en las imágenes de contenedores, donde las diferencias entre implementaciones pueden crear brechas de visibilidad que los escáneres tradicionales no pueden detectar», la compañía dicho.

El nuevo modo de bloqueo de ChatGPT limita las herramientas que podrían permitir la filtración de datos – CYBERDEFENSA.MX

OpenAI ha comenzado a implementar un nuevo Modo de bloqueo a ChatGPT para cuentas personales elegibles para reducir el riesgo de filtración de datos que surge de ataques de inyección rápida.

La función está diseñada principalmente para personas y organizaciones que manejan datos confidenciales y requieren garantías de protección más estrictas. El modo de bloqueo está disponible para los usuarios que han iniciado sesión en los planes Free, Go, Plus y Pro, y ChatGPT Business de autoservicio.

«El modo de bloqueo es una configuración de seguridad avanzada opcional que limita muchas herramientas y capacidades de los productos OpenAI que pueden conectarse a la web o a servicios externos», OpenAI dicho.

«Está diseñado para reducir el riesgo de filtración de datos debido a ataques de inyección rápida al limitar las solicitudes de red salientes, a expensas de deshabilitar o limitar algunas funciones útiles».

Las salvaguardas tienen como objetivo fortalecer la superficie de ataque contra inyecciones rápidas, lo que sigue siendo un problema «fronterizo» que afecta a todos los modelos de lenguajes grandes (LLM).

Específicamente, se basan en el sandboxing y los controles existentes para combatir Mecanismos de exfiltración de datos basados ​​en URL para limitar las solicitudes de red salientes que potencialmente podrían transmitir datos confidenciales a la infraestructura controlada por el atacante.

Ciberseguridad

La idea no es impedir que se produzcan inyecciones inmediatas. Tampoco cambia la forma en que funcionan la memoria o la carga de archivos, ni la capacidad de compartir una conversación. Más bien, el objetivo es eliminar posibles vías a través de las cuales se podrían extraer los datos. Con ese fin, el modo de bloqueo desactiva las siguientes funciones:

  • Navegación web en vivo, que se limita a acceder únicamente al contenido almacenado en caché
  • Soporte de imágenes, para mostrar imágenes en respuestas regulares o recuperar imágenes de la web
  • Investigación profunda
  • Modo agente
  • Red Canvas, que impide que los usuarios aprueben Lienzo-código generado para acceder a la red
  • Descargas de archivos, que bloquean la descarga de archivos para el análisis de datos.

Al señalar que la función no está «destinada a todos», OpenAI también señaló que tanto el modo de bloqueo como el modo de desarrollador no se pueden usar al mismo tiempo, y agregó que activar uno deshabilita el otro.

«El modo de bloqueo está diseñado para reducir sustancialmente el riesgo de una rápida filtración de datos basada en inyección en ChatGPT y productos OpenAI compatibles, pero no garantiza que la filtración de datos no pueda ocurrir», dijo la compañía. «El riesgo puede persistir a través de aplicaciones habilitadas, combinaciones imprevistas de capacidades o técnicas recientemente descubiertas».

«El modo de bloqueo tampoco previene todos los demás efectos de los ataques de inyección rápida. Por ejemplo, una instrucción maliciosa oculta en un archivo cargado aún podría afectar el comportamiento de ChatGPT y provocar una respuesta incorrecta».

El desarrollo se produce cuando OpenAI también lo ha hecho. lanzado una nueva función de administración de cuentas que permite a los usuarios revisar las sesiones activas de ChatGPT y cerrar sesión en sesiones individuales o en todas si se detectan signos de actividad no autorizada en la cuenta. Las sesiones enumeradas incluyen información sobre el dispositivo, la aplicación utilizada, la ubicación aproximada, la fecha y hora de inicio de sesión, si el dispositivo es confiable y si es la sesión actual.

WhatsApp y las notificaciones de Slack podrían secuestrar Google Gemini en Android – CYBERDEFENSA.MX

Una sola notificación envenenada de WhatsApp, Slack, SMS, Signal, Instagram o Messenger podría haber secuestrado el asistente de voz de Google Gemini en Android y haberlo obligado a abrir las ventanas conectadas de una víctima, falsificar un mensaje de su jefe, empujar el teléfono a una llamada de Zoom o envenenar silenciosamente su memoria a largo plazo.

No se requiere ninguna aplicación maliciosa en el teléfono. El asistente sólo tenía que tratar una notificación hostil como un contexto útil.

La investigación, publicado de Or Yair de SafeBreach, sigue el trabajo anterior del equipo «La invitación es todo lo que necesitas», que realizó trucos similares a través de invitaciones maliciosas de Google Calendar. Después de eso, Google Géminis endurecido contra la inyección inmediata indirecta.

Yair encontró una manera de sortear las nuevas defensas. Desde entonces, Google lo parchó, SafeBreach no enumera ningún CVE para el problema y no hay evidencia de que la técnica se haya utilizado alguna vez en la naturaleza.

En Android, Géminis Característica de utilidades Puede leer y responder a sus notificaciones, incluidas las de aplicaciones como WhatsApp. No está disponible en iOS ni en la web, lo que mantiene este vector solo para Android. Yair descubrió que el agente que lee esas notificaciones trata su texto como instrucciones sobre las que puede actuar. Entonces, cualquier cosa que pueda enviar una notificación a un teléfono puede entregar una carga útil, una superficie de ataque que Yair llamó «efectivamente infinito«.

Ciberseguridad

Como mínimo, eso permite a un atacante reescribir lo que dice Gemini, incluso falsificar un mensaje de un contacto designado. Dicho en voz alta mientras conduce y no mira la pantalla, «su gerente le pidió que cargue los documentos en esta carpeta de Drive» es difícil de adivinar. La versión ciega es peor: la carga útil se activa después de que Gemini haya cargado notificaciones reales, por lo que puede tomar el primer nombre real del remitente en la cola y fijarle el mensaje falso.

Falsificar resultados es una cosa. Activar herramientas reales, como abrir una ventana o iniciar una aplicación, es para lo que se crearon las mitigaciones posteriores a la «Invitación» de Google. Yair leyó, a partir de pruebas de caja negra: cuando un «Sí» autoriza una acción sensible, una verificación pesa tanto la respuesta del usuario como el último resultado de Gemini para decidir si ese «Sí» tiene sentido. Inyecte una instrucción retrasada de la nada, y Géminis se negó, cada vez.

Entonces el bypass, que Yair nombró Alineación de contexto falsagenera dos ilusiones a la vez: una autorización aparentemente legítima para el control de seguridad, un intercambio inofensivo para el ser humano.

  • Ofuscado. Gemini hace la pregunta de autorización real en un idioma que la víctima no habla, digamos chino («¿Quieres abrir la ventana?»), luego sigue en inglés con algo inofensivo como «¿Eso es todo lo que necesitas?» El usuario ignora la frase extranjera como un error, dice «Sí» y el servidor vincula ese «Sí» con la pregunta china.
  • Apagado. La conversión de texto a voz de Gemini omite los hipervínculos ocultos detrás del texto en el que se puede hacer clic. Entonces, la pregunta maliciosa queda oculta en un enlace que el asistente nunca lee en voz alta. Géminis dice: «Lo siento, tuve un error, ¿estás ahí?» mientras la pantalla muestra silenciosamente «¿Quieres abrir la ventana?» El conductor dice «Sí», el cheque ve el texto en pantalla y las ventanas se abren.

Combine los dos, un mensaje de autorización en chino escondido dentro de un enlace silenciado, y obtendrá una carga útil que suena como un intercambio normal en inglés mientras se borran los controles más recientes de Google.

Ciberseguridad

Más allá de la autorización, los impactos coincidieron con la investigación anterior y luego fueron más allá:

  • Control inteligente del hogar a través de Google Home: ventanas, calderas y luces conectadas.
  • Seguimiento y descargas. Abrir URL para geolocalizar a una víctima por IP o enviar descargas de archivos.
  • Cruzando a otras aplicaciones. En la demostración, Yair configuró un dominio que parecía seguro para redirigir a un enlace de la aplicación Zoom, y Gemini lo siguió sin preguntar, lo que obligó al teléfono a unirse a una reunión y transmitir video. Según su cuenta, funcionó porque Gemini confió en el dominio después de haber entregado contenido limpio y luego siguió la redirección posterior. SafeBreach destaca que su propio dominio nunca fue redirigido a Zoom; la redirección se ejecutó en un servidor local en el dispositivo de prueba.
  • Envenenamiento de la memoria, que la técnica del calendario anterior nunca logró. La alineación de contexto falsa simula el consentimiento, por lo que Gemini guardó persistentemente un hecho elegido por el atacante. En la demostración, almacenó el nombre de la víctima como «Danny». Debido a que esa memoria está a nivel de cuenta, el hecho envenenado no está atrapado en el teléfono; sigue a la víctima donde quiera que use Gemini en esa cuenta.
  • Persistencia a través de acciones programadas, como una tarea recurrente para leer los mensajes recientes de la víctima todos los días a las 8 p.m.

SafeBreach informó los hallazgos al Programa de recompensas por vulnerabilidades de Google el 17 de agosto de 2025. Google lo trató como una alta prioridad y confirmó el 14 de noviembre de 2025 que las mejoras en el clasificador de contenido mitigaron las inyecciones de notificaciones y la omisión de invocación retrasada de herramientas.

Debido a que la solución está en el lado del servidor, no hay que buscar ninguna actualización de la aplicación. El único control que tienen los usuarios es si Gemini lee las notificaciones: desconecte la aplicación Utilidades en la configuración de Aplicaciones conectadas de Gemini o desactive el permiso «Lectura, respuesta y control de notificaciones» de la aplicación Google en Android.