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

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

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

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

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

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

Ciberseguridad

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

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

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

El 30% de las principales webs de viajes no tiene una protección clave contra el ciberfraude – CYBERDEFENSA.MX

Tres de cada diez webs de viajes en España no utilizan el nivel más alto de una protección del correo electrónico diseñada para impedir la suplantación de dominios, según un análisis realizado en 2026 sobre una veintena de los mayores sitios online del sector. 

El 95% ha adoptado DMARC, pero no siempre con la máxima protección

El sistema analizado es DMARC, un protocolo de autenticación del correo electrónico creado para combatir el uso fraudulento de dominios.

Su función es comprobar la identidad del remitente antes de que el mensaje llegue al destinatario.

DMARC puede configurarse mediante tres políticas progresivas: monitorización, cuarentena y rechazo. Esta última es la más estricta porque permite bloquear los correos que no superan las comprobaciones de autenticación y evita que alcancen la bandeja de entrada.

Los datos muestran una elevada implantación inicial en el sector turístico español. El 95% de las principales webs de viajes analizadas ha publicado un registro básico DMARC.

Sin embargo, únicamente el 70% utiliza la política de rechazo. Esto significa que el 30% restante todavía no aplica el nivel más fuerte estudiado para impedir que mensajes fraudulentos que suplantan su marca lleguen a los usuarios.

Los correos sobre las vacaciones son un objetivo atractivo

El turismo reúne unas condiciones especialmente interesantes para los ciberdelincuentes. Reservar unas vacaciones puede representar uno de los desembolsos más importantes del año para una familia y genera una gran cantidad de comunicaciones digitales.

«Reservar unas vacaciones es una de las mayores compras que muchas personas realizan cada año y, a menudo, viene acompañada de un aluvión de correos electrónicos sobre vuelos, hoteles, itinerarios y ofertas especiales», explican desde la empresa de ciberseguridad Proofpoint.

En medio de esa acumulación de mensajes, un correo falso puede resultar más difícil de identificar.

Una supuesta modificación de un vuelo, un problema con el hotel o una petición urgente relacionada con el pago pueden conseguir que el usuario actúe sin realizar las comprobaciones habituales.

Esta situación ofrece «una oportunidad muy atractiva para los ciberdelincuentes que buscan suplantar a marcas de confianza para engañar a la gente», especialmente cuando el objetivo es obtener información personal o conseguir una transferencia.

Un mensaje urgente puede esconder una página falsa

Uno de los principales riesgos aparece con los correos inesperados que solicitan una acción inmediata.

Una confirmación pendiente, un cambio de última hora o una incidencia con la reserva pueden utilizarse como gancho. El enlace incluido en el mensaje puede conducir a una página de inicio de sesión falsa diseñada para copiar la apariencia de una empresa conocida. Si el turista introduce su usuario y contraseña, las credenciales quedan en manos de los atacantes.

Por ello, ante un correo sospechoso, es preferible no pulsar directamente sobre los enlaces.

El usuario puede escribir la dirección de la web oficial en el navegador y acceder a su cuenta para comprobar si realmente existe una incidencia.

La misma precaución debe aplicarse a las solicitudes de pago inesperadas, especialmente cuando incorporan presión para actuar rápidamente.

Tres medidas para proteger las reservas de verano

La primera recomendación es realizar las reservas mediante páginas oficiales o agentes acreditados. Antes de facilitar información personal o bancaria, conviene comprobar la empresa, revisar opiniones y buscar posibles quejas de otros clientes.

La segunda medida consiste en desconfiar de mensajes inesperados sobre cambios, confirmaciones o problemas que exijan una respuesta urgente. Entrar directamente en la página oficial permite verificar la información sin utilizar el enlace recibido.

Por último, las cuentas de las plataformas de viajes deben protegerse con contraseñas seguras y diferentes para cada servicio. Siempre que esté disponible, activar la autenticación multifactor añade una segunda barrera incluso si la contraseña ha sido comprometida.

Tres de cada diez webs de viajes en España no utilizan el nivel más alto de una protección del correo electrónico diseñada para impedir la suplantación de dominios, según un análisis realizado en 2026 sobre una veintena de los mayores sitios online del sector. 

El problema cobra especial relevancia en esta época, en pleno verano, cuando los turistas reciben numerosos mensajes sobre vuelos, hoteles y reservas que los ciberdelincuentes pueden imitar para intentar robar datos personales, credenciales o conseguir pagos fraudulentos.

El 95% ha adoptado DMARC, pero no siempre con la máxima protección

El sistema analizado es DMARC, un protocolo de autenticación del correo electrónico creado para combatir el uso fraudulento de dominios.

Su función es comprobar la identidad del remitente antes de que el mensaje llegue al destinatario.

DMARC puede configurarse mediante tres políticas progresivas: monitorización, cuarentena y rechazo. Esta última es la más estricta porque permite bloquear los correos que no superan las comprobaciones de autenticación y evita que alcancen la bandeja de entrada.

Los datos muestran una elevada implantación inicial en el sector turístico español. El 95% de las principales webs de viajes analizadas ha publicado un registro básico DMARC.

Sin embargo, únicamente el 70% utiliza la política de rechazo. Esto significa que el 30% restante todavía no aplica el nivel más fuerte estudiado para impedir que mensajes fraudulentos que suplantan su marca lleguen a los usuarios.

Los correos sobre las vacaciones son un objetivo atractivo

El turismo reúne unas condiciones especialmente interesantes para los ciberdelincuentes. Reservar unas vacaciones puede representar uno de los desembolsos más importantes del año para una familia y genera una gran cantidad de comunicaciones digitales.

«Reservar unas vacaciones es una de las mayores compras que muchas personas realizan cada año y, a menudo, viene acompañada de un aluvión de correos electrónicos sobre vuelos, hoteles, itinerarios y ofertas especiales», explican desde la empresa de ciberseguridad Proofpoint.

En medio de esa acumulación de mensajes, un correo falso puede resultar más difícil de identificar.

Una supuesta modificación de un vuelo, un problema con el hotel o una petición urgente relacionada con el pago pueden conseguir que el usuario actúe sin realizar las comprobaciones habituales.

Esta situación ofrece «una oportunidad muy atractiva para los ciberdelincuentes que buscan suplantar a marcas de confianza para engañar a la gente», especialmente cuando el objetivo es obtener información personal o conseguir una transferencia.

La falla de AWS Kiro permitió que una página web envenenada reescribiera su configuración y código de ejecución – CYBERDEFENSA.MX

El texto oculto en una página web fue suficiente para hacer kiroel IDE de codificación agente de AWS, reescribe su propio archivo de configuración y ejecuta el código de un atacante en la máquina de un desarrollador, sin que ningún paso de aprobación pueda detenerlo.

Intezer, en una investigación con Kodem Security, descubrió que una solicitud tan común como pedirle a Kiro que resuma una página podría terminar en la ejecución remota de código. AWS solucionó el problema y no se le asignó ningún CVE.

El modelo de seguridad de Kiro se basa en que un humano haga clic en «permitir». El agente puede ejecutar comandos de shell, recuperar URL y editar archivos, y el diseño supone que un desarrollador revisa cualquier cosa riesgosa antes de que suceda. Ese paso de aprobación es el límite de seguridad, y la falla permitió que un atacante lo pasara sin que al desarrollador se le ofreciera ninguna opción.

El punto débil fue el archivo que le dice a Kiro qué herramientas externas cargar. Kiro lee su lista de servidores Model Context Protocol y el comando exacto utilizado para iniciar cada uno, desde ~/.kiro/settings/mcp.json.

Cuando ese archivo cambia, Kiro lo recarga y ejecuta lo que describe, en el host, con los privilegios del desarrollador. En el momento de la investigación, Kiro podía escribir en mcp.json por sí solo con su herramienta fsWrite, sin necesidad de aprobación, y recargarlo automáticamente.

Ciberseguridad

Cualquiera que pudiera influir en el contenido de ese archivo podría registrar un servidor cuyo comando de inicio fuera código arbitrario, y se ejecutaría en el momento en que Kiro recargara.

Introducir el texto en el contexto de Kiro es la parte fácil. El agente extrae contenido externo cada vez que un desarrollador le pide que busque una URL, lea documentación o busque en la web. Intezer prueba de concepto plantó sus instrucciones en texto blanco de un píxel (color:#fff;font-size:1px) en una página de documentación API que de otro modo sería normal.

El desarrollador ve una referencia de API limpia. Kiro lee el bloque oculto como una tarea de configuración, escribe el servidor malicioso en mcp.json y lo recarga. En cuestión de segundos, el servidor fraudulento se inicia y el código del atacante se ejecuta.

En la demostración de Intezer, la carga útil solo llamaba a casa con el nombre de host, el nombre de usuario y la plataforma de la máquina cada diez segundos, lo suficiente para demostrar la ejecución. La misma primitiva podría ejecutar cualquier comando disponible para el desarrollador, suficiente para robar credenciales y código fuente, plantar persistencia o acceder a cualquier sistema interno al que pueda acceder.

Los investigadores mantuvieron su devolución de llamada apuntando a localhost para que ningún usuario real de Kiro quedara expuesto, y notaron que el ataque no es perfectamente confiable: el modelo no es determinista y puede resumir la página e ignorar el bloque oculto. En sus pruebas, funcionó en uno o dos intentos. Un éxito es todo lo que se necesita.

En algunos casos, Kiro mostró una ventana emergente que decía que la configuración de MCP había cambiado y solicitaba aprobación. No hizo ninguna diferencia. La configuración se recargaba independientemente de en qué hiciera clic el desarrollador, por lo que la advertencia no ofrecía ninguna protección real. La única acción que el desarrollador aprobó fue buscar una URL.

Kiro había estado aquí antes.

Un agente capaz de escribir el archivo que gobierna lo que se permite ejecutar ha aparecido anteriormente en Kiro. El día del lanzamiento de Kiro en julio de 2025, Johann Rehberger de Abraza el rojo mostró el mismo movimiento de escritura a ejecución de mcp.json: una inyección rápida colocó un código personalizado en un archivo de configuración de MCP y lo ejecutó en el momento en que se guardó el archivo.

También marcó una segunda ruta, escribiendo en .vscode/settings.json para incluir en la lista de comandos de shell permitidos. La respuesta de AWS, Kiro 0.1.42, agregó un mensaje de aprobación para esas escrituras, pero sólo en modo supervisado. El modo de piloto automático predeterminado seguía escribiendo el archivo por sí solo, y ese es el modo. Se utiliza la cadena 2026 de Intezer. Entonces tampoco se emitió ningún CVE.

Otros encontraron versiones vecinas de la misma clase. Cymulate informó que Kiro ejecutaba automáticamente el código escrito en .vscode/tasks.json cuando se abría una carpeta. AWS lo asignó CVE-2026-10591 (8.8 bajo CVSS 3.1, 8.6 bajo CVSS 4.0) y lo solucionó en la serie 0.11.

La cadena mcp.json de Intezer todavía estaba activa en las versiones 0.9.2 (macOS) y 0.10.16 (Ubuntu) cuando la compañía lo informó en febrero de 2026, y se confirmó que estaba parcheada en la v0.11.130.

La respuesta de AWS fue dejar de confiar en el juicio del modelo sobre estos archivos y trasladar el cheque a la plataforma. Kiro ahora marca mcp.json, .vscode/tasks.json, el directorio .git y otros archivos confidenciales como caminos protegidoscada uno de los cuales requiere aprobación explícita antes de escribir.

Su propia documentación lo señala directamente: «El modo supervisado es un flujo de trabajo de revisión de código, no un control de seguridad». La versión 1.0 que siguió se apoya más en el mismo principio, con un modelo de permisos basado en capacidades que solicita consentimiento sobre cualquier cosa que un desarrollador aún no haya permitido.

Esa combinación cierra la ruta que tomó Intezer: Intezer confirmó que el ataque falló en 0.11.130 y, a diferencia de la solución de 2025, la verificación de rutas protegidas se mantiene tanto en piloto automático como en modo supervisado.

Ciberseguridad

Intezer informó la falla a través de HackerOne el 11 de febrero de 2026, y el 3 de abril AWS dijo que la solución se había enviado en su última versión, aunque nunca nombró la versión; Los investigadores lo confirmaron ellos mismos en v0.11.130.

No se ha asignado ningún CVE: The Hacker News no encontró ninguno para el hallazgo en la base de datos nacional de vulnerabilidades al 21 de julio de 2026, y AWS no publicó una lista completa de las compilaciones afectadas. Intezer no informó ninguna explotación en estado salvaje y sus pruebas cubrieron Kiro IDE; no estableció si las compilaciones web o CLI de Kiro separadas compartían la falla.

Las compilaciones actuales están en la línea 1.0.x, con 1.0.165 listada como la última al 21 de julio de 2026, y cualquier persona con una versión anterior debe actualizar desde Kiro. pagina de descargas.

Hacker News se comunicó con AWS para confirmar las versiones de Kiro afectadas y por qué no se asignó ningún CVE, y actualizará esta historia con cualquier respuesta.

Durante aproximadamente un año, tres esfuerzos de investigación separados encontraron la misma forma de error en Kiro: un agente editando silenciosamente los archivos que deciden qué se le permite ejecutar. Kiro no está solo: en diciembre de 2025, los investigadores catalogaron más de 30 fallas en las herramientas de codificación de IA, entre ellas Cursor y Copilot, todas las cuales convirtieron funciones legítimas del editor en rutas de inyección rápida para la ejecución de código o el robo de datos.

Todas las correcciones actuales apuntan a la misma lección: el control que funciona se encuentra en la plataforma, se aplica en todos los modos y fuera de cualquier cosa que se le pueda pedir al modelo que cambie.

A medida que una mayor parte del flujo de trabajo de desarrollo pasa a agentes que leen la web abierta, un humano en el bucle solo funciona como control si se le muestra el paso que importa, y la plataforma mantiene la línea incluso después de que se ha convencido completamente al modelo para que la cruce.

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.

SharePoint crítico RCE CVE-2026-50522 bajo explotación activa después de una PoC pública – CYBERDEFENSA.MX

Una tercera falla de SharePoint Server parcheada por Microsoft como parte de su actualización del martes de parches para julio de 2026 ha sido objeto de explotación activa, según torre de vigilancia.

La vulnerabilidad en cuestión es CVE-2026-50522 (Puntuación CVSS: 9,8), una deserialización crítica de datos que no son de confianza en Microsoft Office SharePoint que podría permitir que un atacante no autorizado ejecute código a través de una red. Microsoft le dio crédito al investigador de DEVCORE «splitline» por descubrir e informar la falla.

«En un ataque basado en red, un atacante autenticado como al menos un propietario del sitio podría escribir código arbitrario para inyectar y ejecutar código de forma remota en el servidor SharePoint», dijo Redmond en un aviso publicado la semana pasada.

Ciberseguridad

«El vector de ataque es Red (AV:N) porque esta vulnerabilidad se puede explotar de forma remota y desde Internet. La complejidad del ataque es Baja (AC:L) porque un atacante no requiere un conocimiento previo significativo del sistema y puede lograr un éxito repetible con la carga útil contra el componente vulnerable».

El gigante tecnológico también etiquetó a CVE-2026-50522 con una evaluación de explotabilidad de «Explotación más probable».

En una publicación compartida en LinkedIn, watchTowr dijo que detectó una explotación activa de la deficiencia en implementaciones locales de Microsoft SharePoint luego del lanzamiento de un exploit público de prueba de concepto (PoC), que permite a los atacantes robar claves de máquina para mantener el acceso persistente.

«Los atacantes están extrayendo las claves de las máquinas de SharePoint mediante una única solicitud», afirmó el proveedor de seguridad. «La aplicación de parches no es suficiente; los defensores deben rotar las credenciales de cualquier activo que pueda haber estado expuesto».

Cyber ​​desactivado también ha revelado que los actores de amenazas probablemente estén explotando CVE-2026-50522 para entregar una carga útil de deserialización de .NET a un punto final de inicio de sesión de SharePoint. «Las solicitudes capturadas no contienen material de autenticación y coinciden con el perfil no autenticado de 50522», dijo.

CVE-2026-50522 es la tercera vulnerabilidad en SharePoint Server después de CVE-2026-56164 (puntuación CVSS: 5,3) y CVE-2026-58644 (puntuación CVSS: 9,8) que presencia esfuerzos de explotación activa, y las dos últimas se utilizaron como armas de día cero antes de que se solucionaran en julio de 2026.

Ciberseguridad

Desde entonces, la Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha advertido que los actores de amenazas están explotando múltiples vulnerabilidades de SharePoint Server, incluidas CVE-2026-32201, CVE-2026-45659, CVE-2026-56164 y CVE-2026-58644, para obtener acceso no autorizado a instancias locales.

«Estas vulnerabilidades afectan a todas las versiones locales compatibles de SharePoint Server (Subscription Edition, 2019 y 2016) e implican el establecimiento de ejecución remota de código (RCE) y actividades posteriores a la explotación, como el robo de claves de máquina de Internet Information Services (IIS) y la realización de técnicas de deserialización, para ganar persistencia e implementar malware», dijo la agencia.

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

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

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

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

Ciberseguridad

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

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

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

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

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

Ciberseguridad

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

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

El día N se está convirtiendo en la hora N. Parchar más rápido no te salvará. – CYBERDEFENSA.MX

Cada parche es una confesión.

En el momento en que un proveedor envía una solución de seguridad, la diferencia entre el código antiguo y el nuevo le dice a cualquiera que esté mirando exactamente qué se rompió y dónde. Convierta esa diferencia en un exploit que funcione y podrá atacar todos los sistemas que aún no se han actualizado. Esta es una explotación del día N, y siempre ha sido una carrera: los proveedores parchean, el tiempo se pone en marcha y los defensores intentan desplegarse antes de que un atacante termine de aplicar ingeniería inversa a la solución.

Durante los últimos treinta y tantos años, los defensores normalmente ganaban esa carrera.

La ingeniería inversa de un parche para convertirlo en un exploit confiable era un trabajo lento y especializado que generalmente requería semanas de esfuerzo de nivel experto. Históricamente, la brecha entre un parche y un exploit público funcional abarcaba semanas, a menudo meses.

El manual tradicional suponía que tenías al menos unas cuantas semanas. Ya no lo haces. Ni siquiera cerca.

La ingeniería inversa de un parche solía llevar semanas. Mythos lo hace en una hora.

El equipo rojo de Anthropic mesurado exactamente eso.

Con nada más que la diferencia pública y dos compilaciones, Claude Mythos Preview convirtió 18 parches de Firefox en 8 exploits de ejecución de código funcionales por sí solo. Su primer exploit llegó menos de una hora después de que Mozilla enviara el parche. Aún faltaban 18 días para la versión de Firefox que incluía esa solución.

Los resultados de Windows son aún más difíciles: no hay código fuente, solo archivos binarios eliminados y salida del descompilador. Aun así, de 21 errores del kernel, creó fallas de prueba de concepto para 18 (el más rápido en 31 minutos) y encadenó 8 de ellos hasta el SISTEMA, a un costo de aproximadamente $2,000 cada uno.

Figura 1. Tiempo para reproducir PoC para 21 CVE del kernel de Windows por antrópico

Se pone peor: una de esas cadenas de SISTEMA era para un error que Microsoft había etiquetado como «Explotación poco probable», y esas calificaciones están calibradas para investigadores humanos. Claramente, esa calibración ya no se cumple.

Los modelos públicos de Claude, con sus salvaguardas activadas, también crearon exploits, solo que menos, por lo que no se trata de una capacidad bloqueada detrás de un único modelo cerrado.

Los defensores pueden sentirse un poco reconfortados al saber que convertir un exploit en una intrusión total aún requiere más trabajo, entrega, focalización y evasión. Pero el paso que solía ganarles semanas a los defensores (convertir un parche en un exploit funcional) es exactamente aquel cuyo cronograma se ha derrumbado por completo.

Como lo expresó el propio equipo de Anthropic: «La hora N se acerca más a la realidad en la que operamos ahora».

Lo siento, no puedes salir de esto con parches.

Aquí está la asimetría que rompe el viejo manual: el parche destinado a protegerte es el mismo artefacto que arma al atacante. Oh chico.

Envíe la solución y entregará a los atacantes una hoja de ruta para solucionar el error, y todos los que no hayan actualizado se convertirán en un objetivo. Los investigadores ahora llaman a este punto de inflexión el «vulnpocalipsis», el momento en que un modelo puede convertir una revelación en un arma más rápido de lo que los defensores pueden implementar la solución.

Es por eso que un exploit de 1 día no se parece en nada a lo de hace dos años.

La respuesta instintiva de parchear más rápido es una propuesta perdida. Los números respaldan esto:

  • DBIR 2026 de Verizon sitúa el tiempo medio para reparar una falla conocida explotada en 43 días, frente a los 32 del año anterior, y sólo el 26 por ciento se parcheó por completo. Incluso los que tienen mejor desempeño cierran sólo entre el 30 y el 40 por ciento de las vulnerabilidades conocidas explotadas en la primera semana.
  • El Reloj de Día Cero sitúa el tiempo medio de explotación para 2026 en menos de 24 horas, frente a aproximadamente 53 días en 2024.

Los parches esperan pruebas de regresión, ventanas de cambio y compromisos de tiempo de actividad; Reducir la producción para superar un exploit es simplemente una interrupción diferente. Y con aproximadamente 135 nuevos CVE por día (actualmente un aumento de alrededor del 40 por ciento año tras año), no sorprende que sus equipos nunca puedan eliminar el trabajo atrasado. Las violaciones actuales ocurren cada vez más en esa brecha.

Entonces la pregunta ya no es «¿qué es vulnerable?» Un trabajo atrasado en el que todo tiene una puntuación de 9,8 no prioriza nada. La pregunta que cabe plantearse es: «¿Qué exposiciones puede realmente explotar un atacante aquí? ¿Detendrían nuestros controles el intento y podemos probarlo?».

La validación no te hace parchear más rápido. Hace que la velocidad del parche importe menos.

Obtenga el plan de acción posterior a los Mitos: cinco movimientos, una prueba de aprobación para cada uno y un plan de inicio de cinco días. Empiece a cerrar la brecha ahora. Descargar ahora.

Valide la explotabilidad, no la asuma

Demostrar esto requiere tres métodos, porque ninguno de ellos llega a todo el entorno.

Uno: lanzar un exploit real donde puedas hacerlo de forma segura.

Una cadena de explotación en vivo contra un activo accesible es la prueba más sólida que existe, y es lo que hacen las pruebas de penetración autónomas. Pero un exploit vivo sólo puede detonar cuando sea seguro hacerlo. eso descarta sistemas críticos para el negocio, redes restringidasy segmentos con espacios de aire, que generalmente son los activos que más importan. Descarta todos los CVE que no tengan un exploit público y seguro. Y el primer día, hay un retraso antes de que exista algún exploit. Si lo sumamos, la porción comprobable de forma segura de su exposición total es apenas entre el 10 y el 15 por ciento de su entorno.

No importa cuántas herramientas de pentest tengas, todas acaban chocando contra el mismo muro. El otro 85 a 90 por ciento, las joyas de la corona que no puedes tocar y las amenazas que nadie ha convertido en un arma todavía, es donde realmente reside la decisión.

Dos: para ese 85 a 90 por ciento, compruébelo contra sus controles en lugar de realizar un exploit.

Esto no es leer una configuración y asumir; se trata de ejecutar los comportamientos reales del atacante contra su pila en vivo y observar lo que sucede. Piense en un cohete que no puede lanzar, único en su tipo, tripulado por humanos o quizás aún en desarrollo. Lo demuestras en tierra de todas las formas posibles antes del primer vuelo de prueba, probando cada componente en condiciones reales; si una pieza requerida falla, no volará, y usted lo sabe sin el gasto, la exposición y el peligro de un lanzamiento real.

Un exploit es esencialmente la misma idea: una cadena de técnicas que se ejecutan en secuencia.

Figura 3. Encadenamiento de TTP mediante validación de exposición a Picus

Descomponga un CVE en esa cadena y valide cada enlace con sus controles reales, política de EDR, segmentación, lista de permitidos y firewall.

Rompe un vínculo requerido y sabrás que la exposición no es explotable aquí, con evidencia, incluso sobre los activos que nunca podrás tocar y contra las amenazas que nadie ha convertido en un arma todavía.

Tres: demuestra que tus controles realmente funcionan.

Ejecute continuamente las técnicas de ataque más recientes contra su pila de prevención y detección en vivo, para saber qué se bloquea, qué se escapa silenciosamente y dónde se ha desviado un control, antes de que un atacante lo descubra por usted.

Al ejecutarse juntos, estos dejan de ser tres procesos separados y se convierten en un bucle continuo: validar, decidir, arreglar, revalidar. Ese es el cambio que describe la validación de exposición adversaria de Gartner, y es lo que convierte un hallazgo crítico en una decisión defendible: parchear, mitigar, monitorear o aceptar, en lugar de una suposición basada en una puntuación de gravedad.

Donde encaja Picus

Encontrar la exposición nunca fue la parte difícil. Demostrar que la decisión correcta sí lo es, y ese es el ciclo que Picus ejecuta continuamente, por lo que la respuesta nunca queda obsoleta.

  • Dónde es seguro activar un exploit en vivo, Prueba de penetración autónoma de Picus le ofrece la prueba más sólida que existe al ejecutar la cadena real contra activos accesibles.
  • Para todo lo que no puede tocar de forma segura, los sistemas restringidos, aislados y críticos para el negocio, además de los CVE sin vulnerabilidades aún, Validación de exposición a Picus demuestra la explotabilidad a través del encadenamiento TTP, sin necesidad de detonación, con una respuesta el primer día de divulgación.
  • Y Simulación de ataque y violación de Picus sigue comparando su pila de seguridad en vivo con las técnicas más nuevas. Cuando un control falla, devuelve la firma o regla exacta para cerrar la brecha y luego vuelve a validar que realmente se ha cerrado.

Tres métodos, un bucle. Todo impulsado a la velocidad de la máquina por Enjambre de Picusun equipo de agentes de IA que trabaja dentro de las barreras que tú establezcas, con una cadena de custodia rastreable, sin puntuaciones opacas ni rutas de ataque alucinadas.

Los siguientes son resultados reales para los clientes, al cerrar brechas reales en lugar de comprar más herramientas:

  • 92% menos violaciones de SLA en hallazgos altos y críticos
  • 89% menos MTTR
  • 2 veces la eficacia del control en tres meses

Ese es el caso de negocio: mantener las operaciones en funcionamiento y gastar el presupuesto en lo que cambie el resultado, en lugar de parchear todo y no proteger nada, y prender fuego a sus equipos en el proceso. La pregunta de la junta pasó de «¿estamos parcheados?» a «¿estamos seguros en este momento? ¿Puedes demostrarlo?»

Descubra qué podría realmente explotar un atacante en su entorno antes de que llegue la próxima ola de parches. Solicite su demostración gratuita aquí.

Nota: Este artículo fue escrito por Sıla Özeren HacıoğluIngeniero de Investigación de Seguridad en Picus Security.

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

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

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

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

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

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

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

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

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

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

La explotación de WordPress wp2shell crece a medida que la explotación pública impulsa el escaneo masivo – CYBERDEFENSA.MX

Los atacantes han comenzado a explotar dos vulnerabilidades críticas en WordPress que, cuando se combinan, permiten la ejecución remota de código (RCE) no autenticado y el compromiso total de los sitios web vulnerables.

Las dos fallas de seguridad, rastreadas como CVE-2026-63030 y CVE-2026-60137, tienen nombres en código wp2shell.

«En las primeras horas de la mañana del sábado (UTC), la explotación exitosa ya estaba en marcha, inicialmente utilizando código de explotación público para filtrar credenciales hash, con ejecución remota de código una vez que se hicieron públicos detalles adicionales», dijo Jake Knott, investigador principal de seguridad de watchTowr, a The Hacker News en un comunicado.

«Desde nuestro punto de vista sobre una base global de clientes, estamos viendo el impacto generalizado de esta vulnerabilidad en organizaciones de todos los tamaños y verticales».

Datos de telemetría capturados por KEVIntel muestra que 13 direcciones IP únicas de Suiza, Alemania, el Reino Unido, Indonesia, Lituania, los Países Bajos y Singapur se han vinculado a la explotación de CVE-2026-63030.

La cadena de explotación, descubierto por Searchlight Cyber ​​usando OpenAI GPT 5.6 Sol en más de 10 horas, esencialmente permite a atacantes no autenticados obtener la ejecución remota de código en instalaciones predeterminadas de WordPress en cualquier versión de WordPress lanzada desde diciembre de 2025. Los detalles técnicos se han retenido debido a la gravedad del problema.

Ciberseguridad

«El ataque no tiene condiciones previas y puede ser explotado por un usuario anónimo en una instalación estándar de WordPress sin complementos», dijo Searchlight Cyber.

Según Cloudflare, CVE-2026-63030 permite ejecución remota de código (RCE) no autenticada solo cuando la caché de objetos persistentes no está en uso. Si bien la vulnerabilidad de inyección SQL (CVE-2026-60137) está presente a partir de la versión 6.8, la RCE afecta a las versiones a partir de la 6.9.

«Este exploit utiliza una cadena de vulnerabilidad de dos partes para lograr una inyección SQL no autenticada en una instalación estándar de WordPress con una única solicitud HTTP», explicó Ben Marr, ingeniero de seguridad de Intruder. «CVE-2026-60137 es el punto de entrada: un error de confusión de ruta en el punto final por lotes de la API REST que omite la autenticación, lo que permite a un atacante invocar controladores internos sin ninguna verificación de permiso».

«Esta falla surge de la desinfección inadecuada del parámetro ‘author__not_in’ dentro de ‘WP_Query’ cuando un complemento o tema le pasa datos que no son de confianza. Esta vulnerabilidad permite que una entrada diseñada altere una consulta de base de datos, lo que podría conducir a un acceso no autorizado o manipulación de datos».

Los datos de Wiz, propiedad de Google, sugieren que el 60% de las organizaciones que utilizan WordPress inicialmente tenían al menos una instancia vulnerable en el momento en que se publicaron estos CVE, y el 25% estaban exponiendo un servidor vulnerable a Internet. Desde entonces, las cifras han disminuido a medida que las organizaciones continúan aplicando las correcciones.

La filial de seguridad en la nube ha observado las siguientes actividades posteriores a la explotación tras el abuso de las dos fallas:

  • Subiendo un complemento malicioso
  • Enumerar usuarios y recopilar nombres de usuario y direcciones de correo electrónico de administradores
  • Realizar ataques de inclusión de archivos locales (LFI) para atacar las credenciales de la base de datos y las claves de autenticación para la exfiltración.
  • Acceder al panel de administración y autenticarse exitosamente
  • Carga de un shell web PHP básico que facilita la ejecución remota de código

«También hemos observado una actividad de escaneo de gran volumen sin posterior explotación, lo que sugiere campañas oportunistas de escaneo masivo que buscan identificar objetivos vulnerables junto con una actividad de escaneo de seguridad legítima», afirman los investigadores de Wiz, Shahar Dorfman y Gili Tikochinski. dicho. «Aún tenemos que identificar el movimiento lateral o la filtración de datos, pero continuamos monitoreando e investigando».

Ciberseguridad

También se observa como parte de la actividad un shell web de 150 KB disfrazado de un complemento de seguridad legítimo de WordPress llamado CMSmap. Actúa como una «plataforma de ataque con todas las funciones» que admite gestión de archivos, acceso a bases de datos, escaneo de puertos, inyección de código por lotes y múltiples módulos de escalada de privilegios, incluida la explotación de MySQL UDF.

WatchTowr también dijo que los atacantes han comenzado a invadir Internet de manera indiscriminada luego de la publicación de un exploit público, y sus honeypots registraron «decenas de miles de intentos de explotación».

Se dice que se crearon más de 100 cuentas de administrador de puerta trasera después de la explotación, lo que permitió a los atacantes implementar complementos falsos de WordPress para obtener la ejecución de código o descargar herramientas secundarias para comprometer aún más el sistema. En al menos un caso, se ha observado que un actor de amenazas intenta repetidamente instalar Overlord RAT, un troyano de acceso remoto basado en Golang.

Se recomienda a los defensores que inspeccionen sus instancias de WordPress en busca de nuevas cuentas de administrador, complementos maliciosos u otros archivos sospechosos, independientemente de si han sido parcheados, para erradicar completamente la amenaza.

El nuevo ransomware ENCFORGE apunta a archivos de modelos de IA en el ataque Langflow RCE – CYBERDEFENSA.MX

Los investigadores de Sysdig han vinculado un segundo ataque en el mismo servidor Langflow con JADEPUFFER, el operador impulsado por agentes de inteligencia artificial que documentó por primera vez a principios de este mes.

Ahora se ha visto al mismo operador desplegando APLICARun nuevo ransomware Go compilado diseñado para cifrar pesos de modelos, índices de vectores, conjuntos de datos de entrenamiento y otros archivos de infraestructura de IA en todo el sistema de archivos del host.

El punto de entrada no cambió. Versiones de Langflow anteriores a 1.3.0 exponer el /api/v1/validate/code punto final sin autenticación, lo que permite que cualquier atacante remoto ejecute Python arbitrario en el servidor. el defecto, CVE-2025-3248tiene una puntuación CVSS de 9,8 y ha estado en las vulnerabilidades explotadas conocidas de CISA. catalogar desde el 5 de mayo de 2025.

Como informó The Hacker News a principios de este mes, la operación anterior utilizó código Python desechable y MySQL. AES_ENCRYPT() función para cifrar y destruir datos en Nacos (el servidor de configuración de Alibaba) y bases de datos de producción.

el nuevo Carga útil ENCFORGE reemplaza esos scripts improvisados ​​con herramientas compiladas dirigidas a las tiendas de modelos, bases de datos vectoriales y canales de capacitación que la primera campaña barrió en busca de credenciales.

La carga útil de ENCFORGE

Los investigadores recuperaron el binario del servidor de comando y control del atacante, donde estaba oculto como /.lockd; una solicitud directa a /lockd devuelve 404 y el punto inicial lo mantiene fuera de una lista de directorio simple. El archivo es un ELF Go 1.22.12 estático empaquetado en UPX 5.20.

Las plataformas de inteligencia de amenazas no arrojaron detecciones ni en el hash empaquetado ni desempaquetado en el momento del análisis de Sysdig. El nombre interno del proyecto es encfile; El texto de error del binario hace referencia a una herramienta keygen complementaria llamada keyforge. Ambas cadenas sobreviven a la recompilación del mismo código base y sirven como anclajes de detección estables.

Ciberseguridad

Su lista de extensiones predeterminada cubre puntos de control de PyTorch y TensorFlow, Hugging Face SafeTensors, formato de intercambio ONNX, GGUF (el estándar actual para LLM implementados localmente) y su predecesor GGML, índices vectoriales FAISS, conjuntos de datos de entrenamiento Parquet y Arrow, matrices NumPy y registros TensorFlow.

Un --include flag permite al operador agregar globs de archivos adicionales; el texto de ayuda incorporado utiliza adaptadores de ajuste fino LoRA y pesos GGML heredados como ejemplos. La lista completa incluye aproximadamente 180 extensiones. Esos ejemplos apuntan directamente a entornos de IA; un casillero de archivos genérico tendría pocas razones para nombrar adaptadores LoRA o pesos GGML heredados. Los investigadores interpretaron la elección como un objetivo deliberado, no como una cobertura incidental.

ENCFORGE utiliza AES-256-CTR para datos de archivos, con la clave simétrica por ejecución incluida en una clave pública RSA-2048 integrada compilada en esta compilación. En lugar de cifrar archivos completos, cifra regiones seleccionadas, la misma optimización de velocidad que utilizan los casilleros LockBit y BlackCat.

Cada archivo procesado se renombra con un .locked extensión. El binario elimina los procesos que mantienen los archivos abiertos antes de cifrarlos, maneja los reinicios sin volver a cifrar los archivos completados y arroja notas de rescate como README, HOW_TO_DECRYPTy README_DECRYPTy se elimina después de ejecutarse.

El binario ENCFORGE recuperado no tiene capacidad de exfiltración. No lleva código de red, cliente de almacenamiento en la nube ni mecanismo de preparación, y los investigadores no encontraron evidencia de filtración de datos, un sitio de filtración o un portal de pago Tor durante la sesión que observó. Su única ventaja son los datos cifrados.

El contacto de extorsión incluido en las notas de rescate es e78393397@proton.mela misma dirección de Proton Mail utilizada en la campaña anterior. Sysdig describe esto como el vínculo de atribución más fuerte entre las dos operaciones.

Los investigadores revelaron una sesión observada, no nombraron la organización y no proporcionaron ningún recuento de víctimas ni evidencia de otro despliegue de ENCFORGE.

De Langflow al anfitrión

Después de confirmar la ejecución del código, JADEPUFFER barrió el contenedor en busca de credenciales y encontró el socket Docker en /var/run/docker.sock. Su primer intento de extraer ENCFORGE del servidor de comando y control de GCP falló. En lugar de detenerse, se adaptó.

Durante cinco minutos y 24 segundos, el operador creó y revisó seis scripts de Python a través del mismo canal Langflow RCE hasta que tuvo una ruta funcional hacia el host. El primer script se creó línea por línea, manteniendo inerte cualquier solicitud para la inspección basada en firmas.

A partir del segundo, el operador codificó cada script completo en base64 y lo decodificó dentro de un exec() llamada, evitando búsquedas a nivel de shell de comandos como base64 -d. La versión final utilizó la API de Docker para activar un contenedor privilegiado con el espacio de nombres PID del host y el sistema de archivos raíz montado, ubicó el proceso de destino y copió ENCFORGE a través de /proc//rootluego lo ejecutó en el host a través de nsenter.

En todas las iteraciones, los contenedores se crearon con Privileged: true, PidMode: host, NetworkMode: hosty el sistema de archivos raíz de lectura y escritura montado en enlace. Esa es la raíz del host.

Antes de la ejecución en vivo, el operador lanzó --try-run para escanear el sistema de archivos, luego --lock para el pase de cifrado en vivo. El script final verificó el estado del proceso, leyó el registro de bloqueo y contó los archivos que terminaban en .locked.

Los investigadores no publicaron el recuento resultante; la evidencia revelada establece un intento de cifrado en vivo, no cuántos archivos de modelo o conjunto de datos se cifraron con éxito.

Sysdig evaluó la --task-id gcp_h1 marcar como evidencia que el operador estaba rastreando este host como un objetivo de GCP dentro de una campaña más amplia; una prueba de ejecución anterior en la sesión utilizó el ID de tarea gcp_test. El informe no reveló víctimas adicionales ni sitios de despliegue.

Los investigadores documentaron la campaña anterior de JADEPUFFER corrigiendo un inicio de sesión fallido en Nacos en 31 segundos. El mismo patrón se mantuvo aquí frente a un problema más difícil: el operador construyó una ruptura de host a través del socket Docker expuesto cuando su ruta de entrega preferida estaba bloqueada.

Parche Langflow y luego proteja los modelos

Los investigadores estiman que reconstruir un modelo de producción de IA una vez cifrado podría costar entre 75 000 y 500 000 dólares por modelo en tiempo de ingeniería y computación de GPU en la nube.

Los entornos de producción a menudo ejecutan múltiples variantes especializadas en almacenamiento compartido, por lo que una sola ejecución de ENCFORGE podría cifrar múltiples variantes almacenadas en el mismo sistema de archivos accesible. Si los datos de capacitación se encuentran en el mismo host, la organización debe reconstruirlos antes de que pueda comenzar cualquier reentrenamiento.

Binario SHA-256: empaquetado 8cb0c223b018cecef1d990ec81c67b826eb3c30d54f06193cf69969e9a8baea2; desempaquetado ea7822eac6cecef7746c606b862b4d3034856caf754c4cf69533662637905328.

Ciberseguridad

Sysdig ha publicado las direcciones fuente y C2, la huella digital de la clave RSA-2048 integrada y una regla YARA en su informe completo.

  • Actualice Langflow a 1.9.1 o una versión compatible actual. Versión 1.3.0 cerrada CVE-2025-3248el vector de entrada para esta campaña, pero desde entonces CISA ha agregado dos vulnerabilidades Langflow más a su catálogo KEV: CVE-2026-33017una falla de RCE no autenticada corregida en 1.9.0, agregada a KEV el 25 de marzo de 2026; y CVE-2026-55255una omisión de autorización entre usuarios corregida en 1.9.1, agregada el 7 de julio de 2026.
  • Rote las claves del proveedor de IA, las credenciales de la nube, los secretos de la base de datos y cualquier otro token accesible al proceso de Langflow. La aplicación de parches no revoca las credenciales ya recopiladas a través de una instancia vulnerable.
  • Eliminar /var/run/docker.sock desde cualquier contenedor que no lo requiera. Cuando el acceso al socket sea inevitable, alcancelo a través de un proxy de configuración limitada; una implementación estándar de Langflow generalmente no necesita crear contenedores, y el acceso sin restricciones al socket Docker debe tratarse como una configuración incorrecta.
  • Alerta sobre procesos de aplicaciones que llaman a las API de creación de contenedores de Docker, contenedores lanzados con Privileged: true o PidMode: hostmontajes de enlace host-raíz y nsenter ejecución desde el interior de un contenedor.
  • Mantenga los pesos de los modelos, los índices vectoriales y los conjuntos de datos de entrenamiento en instantáneas inmutables o fuera de línea. Supervise esos directorios para detectar .locked creación de archivos.

Hacker News se puso en contacto con el equipo de investigación de amenazas de Sysdig para obtener más detalles sobre el alcance de la campaña de la flota y la confianza en la atribución; Sysdig no había respondido mediante publicación.

Los artefactos del modelo ahora pertenecen al mismo nivel de recuperación que el código fuente y las bases de datos de producción. Una organización que puede reconstruir la aplicación pero no puede restaurar sus pesos, índices o estado de entrenamiento no tiene una ruta de regreso limpia.