Encontrado rápido, solucionado lento: la brecha que la cámara de compensación de IA debe cerrar

La orden ejecutiva centrada en la IA que el presidente Donald Trump firmó el mes pasado dio al Departamento del Tesoro, la Agencia de Seguridad Nacional y la Agencia de Seguridad de Infraestructura y Ciberseguridad (CISA) 30 días para establecer un nuevo «centro de compensación de ciberseguridad de IA». La fecha límite venció la semana pasada.

La cámara de compensación está destinada a coordinar el escaneo, el descubrimiento y la validación de vulnerabilidades de software en la infraestructura crítica y luego priorizar cómo se parchean y distribuyen esas vulnerabilidades.

Es el problema correcto a resolver. La pregunta ahora es si lo que se crea realmente lo solucionará.

El riesgo es que la urgencia produzca algo que parezca una cámara de compensación, pero que funcione como un comité: recopile información, convoque reuniones y luego se detenga cuando llegue la parte difícil.

Ir más allá del descubrimiento de errores es una misión crítica

Es contradictorio en un momento en el que el descubrimiento de vulnerabilidades asistido por IA avanza rápidamente, pero la parte difícil ya no es solo encontrar errores. Aquellos de nosotros que trabajamos en la intersección de la IA y la ciberseguridad sabemos dónde está el verdadero cuello de botella. HackerOne lo ha visto de primera mano como socio de lanzamiento en Parchear el planetala iniciativa de OpenAI para utilizar la IA para encontrar y corregir vulnerabilidades en software crítico de código abierto a escala de Internet. La lección que sustenta ese trabajo, e informada por más de una década de ejecución de programas de divulgación de vulnerabilidades, es consistente: las herramientas de inteligencia artificial pueden descubrir vulnerabilidades más rápido de lo que cualquiera puede actuar sobre ellas. Lo que queda atrás es todo lo que viene después del descubrimiento: decidir qué hallazgos son reales, evaluar la gravedad en contexto, escribir y probar una solución, y lograr que las personas responsables de mantener el código afectado acepten e implementen un parche.

Los revisores humanos experimentados con frecuencia no están de acuerdo con las calificaciones de gravedad asignadas por la IA, porque un modelo no puede ver el modelo de amenaza o el contexto operativo de un proyecto. Los proveedores de software, especialmente los muchos mantenedores voluntarios de código abierto de los que depende gran parte de la infraestructura digital actual, enfrentan una cola incesante: verificar la afirmación, evaluar la importancia, redactar el parche, coordinar la divulgación. La IA ha acelerado el volumen entrante sin acelerar aún igualmente la capacidad de nuestra gente y procesos para gestionarlo. Mejores herramientas de búsqueda de errores significan que encontrará más errores. Las mejoras que realmente importan son las que ayudan a los defensores a implementar parches y a implementarlos más rápido.

Esa lección debería estar en el centro de cómo se diseña la cámara de compensación.

Si la cámara de compensación se centra principalmente en la coordinación de escaneo, como enfatiza el texto de la orden ejecutiva, corre el riesgo de ampliar esa brecha en lugar de cerrarla. Un organismo que encuentra más vulnerabilidades pero no puede resolverlas no es una victoria en materia de seguridad. A escala nacional es un generador de backlog.

Sentar las bases para el éxito

La administración puede hacerlo bien, pero requiere construir la infraestructura correcta ahora, no superponerla más tarde.

La cámara de compensación necesita hacer más que escanear coordenadas. En realidad, es necesario clasificar los resultados. Su trabajo principal debería ser filtrar informes para identificar qué hallazgos son verdaderamente creíbles, explotables y con consecuencias para la infraestructura crítica. Utilizando estándares de validación compartidos y priorización basada en riesgos, se puede determinar qué justifica una respuesta nacional. De lo contrario, solo se está automatizando atrasos más grandes.

En segundo lugar, la cámara de compensación también necesita abordar algo más fundamental. Los defensores no tienen los recursos para responder a lo que se informa. Las vulnerabilidades en la infraestructura crítica a menudo residen en código de fuente abierta mantenido por pequeños equipos o individuos sin obligación formal de responder a las divulgaciones y con capacidad limitada para actuar rápidamente. La cámara de compensación debería trabajar con el Instituto Nacional de Estándares y Tecnología (NIST) para desarrollar pautas para los mantenedores de código abierto sobre la estructuración de repositorios y flujos de trabajo para acelerar la revisión e implementación de parches.

Estas pautas deben incluir cómo utilizar parches asistidos por IA y aclarar qué deben hacer los consumidores intermedios de código fuente abierto para ayudar a los mantenedores a abordar las vulnerabilidades. La política federal debería crear incentivos para que los usuarios intermedios compartan la responsabilidad de la remediación a través de financiación, apoyo de ingeniería, desarrollo de parches asistidos por IA y requisitos de adquisición que recompensen la participación en una respuesta coordinada a la vulnerabilidad.

En tercer lugar, la cámara de compensación debería tratar las listas de materiales de software (SBOM), los inventarios estructurados de los componentes que componen un producto de software, como infraestructura fundamental. Los SBOM son los que permiten rastrear dónde se encuentra un componente vulnerable a lo largo de la cadena de suministro. Sin ellos, los hallazgos validados no se corregirán lo suficientemente rápido a escala.

Por último, la cámara de compensación debería medir el éxito basándose en lo que se soluciona, no en lo que se descubre. Las agencias deben publicar datos sobre tasas de validación, tiempo de aplicación de parches, adopción de correcciones y clases recurrentes de vulnerabilidades. Estas métricas ayudan a los sistemas de inteligencia artificial, los proveedores de software y los formuladores de políticas a mejorar continuamente la forma en que se abordan las vulnerabilidades.

Lo más importante es que las agencias que defienden esta cámara de compensación deberían resistir la tentación de construir su modelo operativo desde cero. El sector privado y la comunidad de seguridad de código abierto tienen años de experiencia ejecutando exactamente el tipo de flujos de trabajo de admisión, clasificación y divulgación coordinada de vulnerabilidades que necesita la cámara de compensación. La orden ejecutiva exige sabiamente la colaboración voluntaria con la industria. Esa colaboración debe ser estructural, no consultiva, integrada en la forma en que opera la cámara de compensación desde el principio, no reforzada después de que la arquitectura ya esté establecida.

La cámara de compensación puede funcionar. Pero el desafío ya no es encontrar vulnerabilidades. Se trata de construir un sistema que pueda convertir los descubrimientos en acciones. Así es como se debe medir su éxito.

Ilona Cohen

Escrito por Ilona Cohen

Ilona Cohen es directora jurídica y directora de políticas de HackerOne, donde supervisa la función jurídica global de la empresa y lidera su trabajo de políticas públicas con gobiernos y reguladores. Anteriormente se desempeñó como abogada principal del presidente Barack Obama y consejera general de la Oficina de Administración y Presupuesto de la Casa Blanca, y fue directora jurídica y de cumplimiento de Aledade antes de unirse a HackerOne en 2022.

CISA agrega 4 fallas de Adobe, Joomla y Langflow activamente explotadas a KEV – CYBERDEFENSA.MX

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) el martes agregado cuatro fallos de seguridad a sus vulnerabilidades explotadas conocidas (KEV) catálogo, citando evidencia de explotación activa.

Las vulnerabilidades se enumeran a continuación:

  • CVE-2026-48282 (Puntuación CVSS: 10,0): una vulnerabilidad de recorrido de ruta en Adobe ColdFusion que podría provocar la ejecución de código arbitrario en el contexto del usuario actual.
  • CVE-2026-56290 (Puntuación CVSS: 10.0): una vulnerabilidad de control de acceso inadecuado en Joomlack Page Builder que podría permitir la ejecución remota de código mediante la carga de archivos arbitrarios no autenticados.
  • CVE-2026-55255 (Puntuación CVSS: 6.1): una omisión de autorización a través de una vulnerabilidad de clave controlada por el usuario en Langflow que podría permitir a un atacante autenticado ejecutar cualquier flujo que pertenezca a otro usuario especificando el ID del flujo de la víctima en la solicitud.
  • CVE-2026-48908 (Puntuación CVSS: 10.0): carga sin restricciones de un archivo con una vulnerabilidad de tipo peligroso en JoomShaper SP Page Builder que permite a usuarios no autenticados cargar archivos arbitrarios, lo que en última instancia resulta en la carga y ejecución de código PHP.

Vale la pena señalar que explotación de CVE-2026-48282 se observó pocas horas después de la divulgación pública, y Ryan Dewhurst, investigador de seguridad y fundador de KEVIntel, le dijo a The Hacker News que se registró un intento desde una dirección IP geolocalizada en la India («103.207.14[.]220»).

Ciberseguridad

CVE-2026-48908, por otro lado, se dice que ha sido explotado como día cero para cargar un archivo PHP mediante una solicitud HTTP POST al punto final «index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon», seguido de la aparición de una nueva cuenta de superusuario, según misSitios.guru. Se recomienda a los usuarios de SP Page Builder que actualicen a la versión 6.6.2 o posterior.

El servicio de administración de sitios Joomla y WordPress también registró esfuerzos de explotación dirigidos a CVE-2026-56290 a partir del 27 de junio de 2026, para entregar un shell web en sitios susceptibles. El problema se solucionó en la versión 3.6.0 de Page Builder CK.

«El primer shell web confirmado que detectamos se encontraba en /media/com_pagebuilderck/gfonts/bhup.php, un shell de carga con clave en $_POST[‘_upl’] campo», mySites.guru explicado.

«Debido a que la falla permite al atacante elegir la carpeta de destino, un archivo colocado podría estar en cualquier lugar, no solo en los directorios de carga obvios, así que busque archivos PHP perdidos en /media/com_pagebuilderck/ primero y luego más ampliamente en /images, /media, /templates y /administrator».

En cuanto a CVE-2026-55255, Sysdig reveló A finales del mes pasado observó a un operador solitario («45.207.216[.]55») armando la vulnerabilidad junto con CVE-2026-33017, una falla de ejecución remota de código no autenticado en Langflow, como parte de una campaña sostenida que duró entre el 22 y el 25 de junio de 2026.

«El 25 de junio de 2026, el operador (45.207.216[.]55) regresaron a una instancia de Langflow expuesta a Internet que habían sondeado por primera vez tres días antes y ejecutaron una sesión metódica y exhaustiva: reconocimiento de aplicación/autenticación → enumeración de flujo → el IDOR CVE-2026-55255 → un bucle sostenido del RCE CVE-2026-33017 con intentos de conexión salientes», dijo Michael Clark de Sysdig.

La actividad se considera oportunista y financieramente motivada. A la explotación de CVE-2026-33017 le sigue la implementación de cargas útiles diseñadas para buscar un descargador de segunda etapa responsable de entregar malware adicional. Esta cadena de ataques es consistente con los ataques de botnet y cryptojacking. Dicho esto, se desconoce la naturaleza exacta de la carga útil final.

Ciberseguridad

La empresa de seguridad en la nube ha descrito CVE-2026-55255 como un caso de referencia de objeto directo inseguro (IDOR) entre inquilinos, que el actor de amenazas aprovechó para robar claves de proveedor de modelo de lenguaje grande (LLM) y claves de AWS.

«Las plataformas de orquestación de IA son un tesoro de credenciales por derecho propio, y este operador claramente lo sabía», dijo Sysdig. «El RCE persiguió al anfitrión, mientras que el IDOR persiguió los flujos de otros inquilinos y sus claves».

El desarrollo lo convierte en la última falla de Langflow explotada por malos actores durante el año pasado después de CVE-2025-3248, CVE-2026-0770, CVE-2026-33017, CVE-2026-21445, CVE-2025-34291 y CVE-2026-5027.

La semana pasada, Sysdig también documentó el primer caso conocido de ransomware agente en el que un operador humano implementó un agente artificial y proporcionó la infraestructura necesaria para permitir que el agente manejara toda la operación de extorsión de principio a fin explotando la falla Langflow CVE-2025-3248. ha sido nombrado en clave JADEPUFFER.

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 10 de julio de 2026 para salvaguardar sus redes.

La falla de GhostLock de 15 años permite el escape de raíz y contenedor en la mayoría de las distribuciones de Linux – CYBERDEFENSA.MX

Los investigadores de Nebula Security han revelado GhostLock (CVE-2026-43499), una falla del kernel de Linux de hace 15 años que permite a cualquier usuario que haya iniciado sesión tomar el control total de raíz de una máquina que no ha sido parcheada. El código vulnerable se ha incluido de forma predeterminada en prácticamente todas las distribuciones principales desde 2011. La falla no necesita ningún permiso especial, ni configuraciones inusuales ni red.

España detiene a un presunto hacker vinculado a la campaña hacktivista rusa

Las autoridades arrestaron a un presunto miembro del Cyber ​​Army of Russia Reborn, un grupo hacktivista prorruso acusado de cometer múltiples ataques contra proveedores de infraestructura crítica en Estados Unidos y Europa.

la policia nacional de españa anunció el arresto el lunes, pero dijo que ocurrió en marzo. Las autoridades no nombraron al hombre que fue detenido en su casa de Palencia tras una investigación iniciada por una pista del FBI en agosto de 2025.

Agentes del FBI en la oficina local de Los Ángeles se coordinaron con funcionarios españoles para capturar al presunto cibercriminal, dijo la división cibernética de la agencia en un publicación en LinkedIn Lunes. El FBI dijo que el arresto fue parte de la Operación Riptide, una campaña global en curso dirigida a los ciberdelincuentes y la infraestructura y las redes financieras que utilizan para cometer fraude.

«Juntos continuaremos imponiendo costos a los ciberdelincuentes dondequiera que operen», dijo el FBI.

Los funcionarios españoles dijeron que el hombre arrestado brindó apoyo logístico a un hacker ucraniano vinculado al Ejército Cibernético de Rusia Renacido, también conocido como Z-Pentest, facilitando la fuga del ucraniano a Rusia a través de Polonia y Bielorrusia.

El detenido también “participó en acciones atribuidas al grupo hacktivista prorruso NoName057(16), cuyas operaciones fueron posteriormente reivindicadas en portales especializados relacionados con geopolítica, con el objetivo de difundir narrativas prorrusas y antioccidentales”, dijeron las autoridades españolas.

Los investigadores de la policía registraron la casa del sospechoso y confiscaron computadoras y dispositivos de almacenamiento de criptomonedas, y luego congelaron una billetera de criptomonedas que supuestamente usó para recibir pagos por sus presuntos delitos.

Las autoridades dijeron que la investigación de casi un año concluyó recientemente, pero no anunciaron cargos específicos, aparte de acusarlo de colaborar con una organización terrorista, glorificar el terrorismo y dañar computadoras.

Las autoridades llevan años persiguiendo al Ejército Cibernético de Rusia Renacida y a sus presuntos miembros. El grupo patrocinado por el estado ruso ha estado activo desde 2022, dijeron los funcionarios.

El Departamento del Tesoro sancionado el presunto líder y principal hacker del grupo hacktivista prorruso, Yuliya Vladimirovna Pankratova y Denis Olegovich Degtyarenko, en julio de 2024.

En diciembre de 2025, el Departamento de Justicia Victoria Eduardovna Dubranova, ciudadana ucraniana acusadaacusándola de participar en ataques contra infraestructuras críticas y otras víctimas en apoyo de los intereses geopolíticos de Rusia como parte del Cyber ​​Army of Russia Reborn y NoName057(16). Dubranova fue extraditada a Estados Unidos el año pasado y se declaró culpable en dos casos federales presentados en su contra.

El Departamento de Estado desde finales de 2025 ha estado ofreciendo posibles recompensas por hasta $2 millones para obtener información sobre personas asociadas con Cyber ​​Army of Russia Reborn y hasta $10 millones para obtener información sobre personas asociadas con NoName. NoName057(16), también conocido como NoName, fue establecido por el presidente ruso Vladimir Putin en octubre de 2018, según el Departamento de Justicia.

Múltiples agencias federales y socios internacionales emitieron un asesoramiento conjunto sobre ciberseguridad en diciembre de 2025 sobre las amenazas planteadas por grupos hacktivistas prorrusos, incluidos Cyber ​​Army of Russia Reborn y NoName.

Matt Kapko

Escrito por Matt Kapko

Matt Kapko es reportero de CyberScoop. Su ámbito incluye delitos cibernéticos, ransomware, defectos de software y (mala) gestión de vulnerabilidades. El californiano de toda la vida comenzó su carrera periodística en 2001 con paradas anteriores en Cybersecurity Dive, CIO, SDxCentral y RCR Wireless News. Matt tiene una licenciatura en periodismo e historia de la Universidad Estatal de Humboldt.

RedWing MaaS empaqueta el fraude bancario de Android como un servicio de alquiler de Telegram – CYBERDEFENSA.MX

Una nueva operación de malware para Android llamada Malvís se alquila en Telegram como un servicio de fraude bancario ya preparado. Permite que incluso delincuentes poco capacitados se apoderen del teléfono de la víctima, roben sus inicios de sesión bancarios y capturen los códigos de un solo uso que protegen sus cuentas.

Los zLabs de Zimperiumque descubrió la operación, dice que parece una nueva variante de Olvidouna herramienta de alquiler de malware de 300 dólares al mes documentada a principios de este año.

RedWing se vende como un producto completo, en niveles de suscripción con descuentos por referencias, guías y videos instructivos, por lo que el comprador no necesita habilidades para escribir malware. Un bot de Telegram crea para cada comprador una aplicación personalizada a pedido.

Los investigadores dicen que una cantidad sustancial de los droppers y cargas útiles resultantes actualmente evaden las herramientas de seguridad convencionales.

La infección comienza con un enlace de phishing que abre una página falsa de una tienda de aplicaciones. El creador de cuentagotas del kit puede imitar Google Play, Galaxy Store y AppGallery, o crear páginas totalmente personalizadas, con calificaciones, reseñas y recuentos de descargas falsos. Luego, la página convence al usuario para que instale la aplicación desde fuera de la tienda oficial y apruebe sus permisos.

Ciberseguridad

La aplicación presenta sus solicitudes de permiso una pantalla a la vez. Una página web de apariencia inofensiva se encuentra en segundo plano mientras las tarjetas emergentes solicitan permisos enmarcados como rutinarios: desactivar los límites de batería, configurar la aplicación como el administrador de mensajes de texto predeterminado y activar las notificaciones.

También solicita activar el servicio de Accesibilidad de Android, del que el malware abusa para leer la pantalla y controlar el teléfono.

Con esos permisos, RedWing tiene un amplio control del teléfono. Sus capacidades incluyen:

  • Pantallas de inicio de sesión falsas, llamadas superposiciones, que aparecen sobre aplicaciones bancarias y de criptomonedas reales para robar contraseñas.
  • Leer mensajes de texto entrantes para obtener contraseñas de un solo uso y usar Accesibilidad para eliminar códigos, números de tarjetas y PIN de la pantalla a medida que aparecen.
  • Cambia silenciosamente las llamadas entrantes de la víctima al atacante, utilizando un código de operador oculto (*21*) para activar el desvío de llamadas, lo que anula la verificación telefónica y las llamadas de verificación de fraude bancario.
  • Transmisión de pantalla en vivo y registrador de teclas, para que los operadores puedan ver y controlar el teléfono en tiempo real.
  • Encender la cámara y el micrófono, leer archivos, robar contactos y registros de llamadas y rastrear la ubicación.
  • Agrupar teléfonos infectados para inundar de tráfico un sitio web objetivo, un ataque de denegación de servicio.

Los compradores eligen sus propios objetivos y el malware los divide en dos. Las aplicaciones que observa a través de Accesibilidad están incorporadas en cada copia, lo que indica que se crea una aplicación nueva a pedido una vez que el comprador elige los objetivos. Los objetivos superpuestos, por el contrario, se pueden cambiar más tarde desde el panel de control sin tener que abrir una nueva aplicación.

Zimperium contó 82 instituciones objetivo en varios sectores, con un fuerte enfoque en las empresas financieras rusas, aunque esa lista puede cambiar en cualquier momento. La evidencia apunta al mercado ruso: una muestra utilizó una página falsa de RuStore de Rusia. Los expertos dicen que la operación parece estar vinculada a actores de amenazas rusos, pero no llegan a confirmarla.

RedWing encaja en un movimiento más amplio en los delitos de Android hacia el fraude en el dispositivo, donde los atacantes operan dentro de la propia sesión bancaria de la víctima en lugar de robar una contraseña para usarla en otro lugar.

Ciberseguridad

Los investigadores detectaron el año pasado un kit de alquiler casi idéntico en el mercado ruso, Fantasy Hub. Las mismas técnicas aparecen en Albiriox, dirigido a más de 400 aplicaciones financieras, y Klopatra, que utilizaba control remoto oculto y superposiciones falsas para vaciar cuentas mientras las víctimas dormían.

RedWing no necesita ningún exploit de Android. Sólo funciona cuando un usuario instala la aplicación desde fuera de una tienda oficial y aprueba las indicaciones, por lo que la primera línea de defensa es lo que sucede en el momento de la instalación. Para particulares:

  • Instale aplicaciones sólo desde tiendas oficiales y trate como sospechosa cualquier «actualización» que llegue mediante un enlace o mensaje de texto.
  • No active «instalar desde fuentes desconocidas» y no otorgue accesibilidad, controlador de mensajes de texto predeterminado o acceso de exención de batería a una aplicación sin una razón clara para necesitarla.
  • Esté atento a una aplicación que oculta su ícono después de instalarse, un truco común para permanecer fuera de la vista.

En los dispositivos administrados, se pueden aplicar las mismas opciones de forma centralizada: bloquear la descarga y marcar las aplicaciones que solicitan Accesibilidad o la función de SMS predeterminada.

Los investigadores también han publicado indicadores de compromiso para los equipos que quieren buscarlo. Debido a que el kit se puede cambiar y sus objetivos superpuestos se pueden intercambiar desde un panel, el mismo código puede seguir apareciendo con nuevos nombres, por lo que los nombres de las aplicaciones son una mala manera de rastrearlo. El comportamiento es la señal, no el nombre.

Demanda Deepfake CSAM contra xAI, Grok se expande

Se han agregado dos nuevas partes a una demanda colectiva contra X.ai por su herramienta Grok, incluidos adolescentes y niños que dicen que fue utilizada por familiares u otras personas que conocen para crear material de agresión sexual infantil (CSAM) no consensuado y falso.

La demanda, presentada originalmente en marzo por tres mujeres, fue modificado esta semana para incluir a dos demandantes adicionales, Jane Does 4 y 5, quienes dicen que Grok fue utilizado para crear contenido ilegal basado en sus fotos y videos reales.

Las cinco mujeres en la demanda son anónimas y la denuncia dice que la difusión del material las había dejado humilladas y avergonzadas.

Jane Doe 4, una mujer de Wyoming, dijo que su padrastro subió una foto de ella cuando tenía 11 años y estaba acostada en un sofá frente a su teléfono. Usando Grok, el padrastro creó más de 7.000 imágenes de ella relacionadas con CSAM. También compartió e intercambió las imágenes con otros en plataformas de redes sociales.

La demanda alega que el padrastro optó por Grok «porque la plataforma era menos restrictiva que otros modelos de IA y respondía a sus indicaciones para generar material sexualmente explícito utilizando una imagen que representaba a un menor prepúber».

También afirma que en febrero, xAI generó un aviso al Centro Nacional para Niños Desaparecidos y Explotados con respecto a las imágenes, pero la compañía solo presentó la imagen original y auténtica como prueba. Según la demanda, xAI no respondió cuando las autoridades solicitaron las miles de imágenes generadas por Grok basadas en la foto y la información de la dirección IP que habrían ayudado rápidamente a identificar a su padrastro como el perpetrador.

La demanda afirma que el padrastro se pegó un tiro dos días después de ser arrestado y acusado de delitos de explotación infantil. Su suicidio se sumó a la “crisis personal extrema” provocada por las imágenes creadas a través de Grok. Regularmente «lucha contra el autodesprecio y el disgusto», así como contra la «ansiedad extrema» ante la idea de que otras personas encontrarán las imágenes en línea y sufre de depresión, incluido sueño excesivo e ideas suicidas cuando está despierta.

Jane Doe 5 afirmó que un hombre adulto relacionado con uno de sus compañeros de clase usó Grok para convertir una fotografía de su graduación de octavo grado en material ilícito. Las imágenes también se intercambiaron y compartieron con otras personas en línea. Si bien el hombre fue arrestado y acusado, gran parte del contenido todavía está disponible en Internet. Como resultado, “siente una total falta de control sobre la difusión continua de los archivos”.

«Es imposible saber cuántos otros depredadores sexuales de niños pueden poseer ahora el CSAM de Jane Doe 5, ni cuán ampliamente se ha difundido su CSAM en línea a través de canales y aplicaciones de la red oscura», dice la denuncia.

La oficina de prensa de xAI no respondió a una solicitud de comentarios enviada por correo electrónico por parte de CyberScoop.

La demanda también agrega a Stability AI como demandado, alegando que la compañía lanzó Stable Diffusion 1.0 como un modelo de peso abierto a pesar de saber que estaba entrenado en CSAM y se negó a alterar o modificar sus barreras de seguridad en respuesta.

Según un Estudio de Stanford 2023el conjunto de datos subyacente utilizado para entrenar modelos de difusión estable se creó mediante el rastreo web no guiado de contenido de Internet. Eso significa que ingirió “una cantidad significativa de material explícito”, incluido CSAM. Stable Diffusion 1.0 tenía un clasificador destinado a bloquear la generación de tales imágenes, pero debido a esos datos de entrenamiento, los desarrolladores posteriores podrían explotar más fácilmente el modelo y crear versiones modificadas que eludan esas protecciones.

Si bien Stable Diffusion 2.0 introdujo barreras de seguridad más fuertes, la demanda afirma que Stability AI eliminó esas protecciones en respuesta a los usuarios «descontentos» de que las nuevas restricciones eran «mojigatas» e «impopulares». Esto, a su vez, ha alimentado un ecosistema de “aplicaciones de nudificación” con jailbreak basadas en los modelos de Stability AI.

«Stability AI sabía que sus modelos, una vez capaces de generar imágenes sexualmente explícitas, previsiblemente se utilizarían para generar CSAM a menos que se implementaran salvaguardias adecuadas a nivel de modelo», decía la denuncia.

Stability AI no respondió a una solicitud de comentarios de CyberScoop.

Derek B. Johnson

Escrito por Derek B. Johnson

Derek B. Johnson es reportero de CyberScoop, donde su área incluye la ciberseguridad, las elecciones y el gobierno federal. Antes de eso, ha brindado una cobertura galardonada de noticias sobre ciberseguridad en los sectores público y privado para varias publicaciones desde 2017. Derek tiene una licenciatura en periodismo impreso de la Universidad de Hofstra en Nueva York y una maestría en políticas públicas de la Universidad George Mason en Virginia.

La falla de un agente fraudulento podría haber permitido a los atacantes secuestrar los chatbots CX de Google Dialogflow – CYBERDEFENSA.MX

Un defecto crítico en Dialogflow CX de Google podría haber permitido que un atacante con derechos de edición en un agente habilitado para Code Block comprometiera a otros agentes habilitados para Code Block en el mismo proyecto de Google Cloud.

Desde allí, podían leer conversaciones en vivo, robar los datos compartidos por los usuarios y hacer que los bots enviaran mensajes escritos por los atacantes, incluidas solicitudes para volver a ingresar una contraseña.

Empresa de seguridad varonis Lo encontró y lo nombró Agente rebelde. La falla afectó solo a las organizaciones que crearon agentes con los Playbooks de Dialogflow y bloques de código personalizados, que permitieron a los desarrolladores agregar su propio Python. Y no fue un ataque remoto y no autenticado.

Para lograrlo, se necesitaba el permiso dialogflow.playbooks.update en uno de esos agentes, lo que limita al atacante realista a un interno malicioso o una cuenta de desarrollador comprometida, no a un extraño en Internet. Sin embargo, desde ese único punto de apoyo, el alcance se extendió a todos los agentes del proyecto.

Google lo ha solucionado, y tanto Varonis como Google dicen que no hay señales de que la falla haya sido utilizada alguna vez en un ataque real.

Un archivo grabable ejecutó los bloques de código de cada agente

Los bloques de código de Dialogflow permiten a los desarrolladores agregar Python personalizado al flujo de conversación de un chatbot para verificar la entrada, controlar el comportamiento e invocar herramientas definidas. Ese código se ejecuta en un entorno Cloud Run administrado por Google y cada agente que usa bloques de código en el mismo proyecto de Google Cloud comparte una instancia del mismo.

Google maneja ese entorno, el cliente no puede verlo ni controlarlo, y Varonis no encontró un aislamiento real entre los agentes dentro de él.

Ciberseguridad

Cuando un agente ejecuta un bloque de código, el código del desarrollador se agrega al código de configuración interno y se pasa a la función exec() de Python. Ese código de configuración define las variables y funciones que el bloque puede tocar. Las variables incluyen el historial de la conversación completa y el estado de los detalles de la sesión, como el ID de la sesión. Las funciones incluyen responder(), que hace que el bot responda con una cadena determinada.

Varonis encontró el archivo que realiza este ajuste, code_execution_env.py, en el entorno compartido con acceso de escritura.

Como ese archivo se podía escribir, un solo bloque de código podría reemplazarlo. Ese bloque descarga un code_execution_env.py modificado desde un servidor controlado por un atacante y sobrescribe el original dentro del contenedor en ejecución.

A partir de ese momento, la versión del atacante se ejecuta para cada ejecución de bloque de código en cada agente que comparte ese entorno. Se encuentra en el mismo alcance que el código legítimo, con el mismo acceso al historial, estado y respuesta().

Eso le permite leer cada conversación, enviarla silenciosamente al servidor del atacante y hacer que el bot publique mensajes escritos por el atacante. Un ejemplo es el phishing: el bot le pide al usuario que vuelva a verificar su inicio de sesión y el atacante recopila todo lo que escribe.

Para cubrir las pistas, el atacante restaura el bloque de código original en la consola de Dialogflow. Eso cambia sólo lo que muestra la consola; el archivo sobrescrito ya se está ejecutando en el contenedor y sigue ejecutándose debajo.

La caja de arena se filtró de dos maneras más

Varonis informó dos problemas relacionados y ninguno necesitaba sobrescribir el archivo. Primero, el entorno Code Block tenía acceso saliente a Internet sin restricciones. Utilizando la biblioteca urllib incorporada, los investigadores enviaron datos directamente a un servidor externo y pudieron recibir comandos.

Varonis dice que esto pasa por alto los controles de servicio de VPC, el perímetro de Google Cloud destinado a evitar que los datos abandonen los servicios protegidos. El entorno se encuentra fuera de ese perímetro y puede llegar a Internet abierto, lo que lo convierte en un canal tanto para el robo de datos como para el control remoto.

En segundo lugar, y menos grave, el entorno expuso el Servicio de Metadatos de Instancia (IMDS), un punto final normalmente interno que entrega credenciales de nube. Al consultarlo se devolvió un token para una cuenta de servicio administrada por Google.

Esa cuenta tenía pocos privilegios, por lo que el riesgo directo era limitado; El verdadero punto es que un entorno limitado de ejecución de código no debería poder llegar a IMDS en absoluto.

Casi nada llegó a los registros.

La sobrescritura se produjo dentro del entorno de Google, donde los clientes no tienen visibilidad y Cloud Logging no registró el cambio de archivo ni el código inyectado.

Eso hace que sea difícil, aunque no imposible, captar la situación por parte del cliente. Las acciones de configuración aún dejan rastros, en los que se basan las comprobaciones siguientes.

Ciberseguridad

Varonis reveló la falla a través del Programa de recompensa por vulnerabilidades de Google en noviembre de 2025. Google envió una solución inicial en abril de 2026 y la resolvió por completo en junio de 2026, aproximadamente siete meses desde el informe hasta la resolución. No se asignó ningún CVE.

Qué verificar si usaste bloques de código

Si ejecutó agentes de Dialogflow CX con Code Block Playbooks antes de la solución y desea confirmar que no fue el objetivo, comience con el acceso.

El permiso dialogflow.playbooks.update es el punto de entrada completo, así que audite qué roles y cuentas lo tienen.

Entonces:

  • Revise sus registros de auditoría DATA_WRITE para la API de Dialogflow en busca de actualizaciones inesperadas del manual y correlacione con usuarios, direcciones IP u tiempos de acceso inusuales.
  • Ejecute una consulta de Cloud Logging para solicitudes fallidas de usuarios, donde los mensajes de error pueden revelar excepciones generadas por bloques de código maliciosos.
  • En la consola de Dialogflow, abra Playbooks para cada agente y confirme que cada bloque de código sea uno que haya aprobado.

Un tipo diferente de falla de la IA

Muchas fallas de seguridad recientes de la IA han funcionado engañando al modelo.

El propio Reprompt y SearchLeak de Varonis convirtieron un solo clic en robo de datos en Copilot de Microsoft. ForcedLeak de Noma Security ocultó instrucciones en un formulario web de Salesforce para extraer datos de CRM.

Los investigadores de Microsoft demostraron una inyección rápida convirtiéndose en ejecución de código en el marco del kernel semántico. Rogue Agent no tocó el modelo en absoluto. Abusó de una característica normal del desarrollador y de un tiempo de ejecución invisible y compartido, al que se puede acceder con un permiso de edición normal.

En una configuración como esta, un permiso que parece un derecho de edición de contenido es en realidad un derecho de ejecución de código. Cualquiera que pueda agregar un bloque de código puede ejecutar Python arbitrario dentro de un entorno compartido que el cliente no puede inspeccionar.

Trate los permisos de edición del agente como los controles de tiempo de ejecución que son. Incluso cuando el proveedor dice que no es necesario arreglar nada, los clientes todavía no tienen forma de mirar dentro de ese tiempo de ejecución por sí mismos.

Las herramientas DEBULL abusan del flujo de código de dispositivo de Microsoft para apuntar a cuentas M365 – CYBERDEFENSA.MX

Se ha observado una campaña de phishing de código de dispositivo Microsoft 365 que aprovecha señuelos con temas de colaboración para tomar el control de las cuentas de las víctimas entre la última semana de junio de 2026 y principios de julio, según recomendaciones de ZeroBEC.

«La campaña no dependía de una página de contraseña falsa de Microsoft. Utilizó un señuelo malicioso de estilo colaborativo para empujar a los usuarios a la experiencia legítima de inicio de sesión del dispositivo Microsoft, mientras que un agente backend generaba y sondeaba tokens de código de dispositivo del Agente de Autenticación de Microsoft», dijo la compañía de seguridad de correo electrónico en un informe compartido con The Hacker News.

Se evalúa que la actividad comparte superposiciones «fuertes» con una campaña documentada por Microsoft en febrero de 2025 bajo el nombre de Storm-2372, incluido el uso de mensajes o señuelos estilo Teams para engañar a víctimas desprevenidas para que ingresen un código de dispositivo proporcionado por el atacante, junto con sus credenciales, lo que permite efectivamente al actor de amenazas recuperar el token y secuestrar su cuenta.

A pesar de estas similitudes, se evalúa que los actores de amenazas están empleando técnicas de estilo Storm-2372 a través de lo que se ha descrito como una capa de herramientas reutilizable llamada DEBULL.

El phishing de código de dispositivo se refiere a una técnica de robo de identidad en la que los atacantes explotan un mecanismo de autenticación OAuth 2.0 legítimo, específicamente el flujo de concesión de autorización de dispositivo, para evitar la autenticación multifactor (MFA) y obtener acceso persistente a la cuenta sin tener que robar las contraseñas de los usuarios.

A diferencia de los ataques de phishing tradicionales que requieren que los operadores configuren páginas de inicio de sesión falsas de adversario en el medio (AitM), el phishing de código de dispositivo se basa en manipular a un usuario para que complete un mensaje de autenticación real y confiable.

Ciberseguridad

Autenticación de código de dispositivo, por microsoftes un flujo OAuth legítimo diseñado para dispositivos con interfaces limitadas, como televisores inteligentes o impresoras, que no pueden admitir un inicio de sesión interactivo tradicional. En este escenario, al usuario se le presenta un código corto en el dispositivo desde el que intenta iniciar sesión y se le solicita que ingrese ese código en un navegador web en un dispositivo separado para completar la autenticación.

Los actores de amenazas tienen abusado esta separación para insertarse y iniciar el flujo de autenticación. Luego, comparten ese código con el objetivo a través de un señuelo de phishing. Así, cuando el usuario ingresa el código, autoriza la sesión del actor de la amenaza sin su conocimiento, otorgándole acceso a la cuenta.

«El phishing del código del dispositivo no se abre camino», Huntress notas. «Utiliza un flujo de autenticación legítimo para atravesar la puerta principal, sin necesidad de contraseña, sin pasar por MFA y con tokens de sesión entregados directamente al atacante».

Los ataques exitosos de phishing de código de dispositivo pueden facilitar la apropiación total de la cuenta, el robo de información valiosa, el fraude, el compromiso del correo electrónico empresarial (BEC), el movimiento lateral dentro de un entorno comprometido e incluso ataques disruptivos como el ransomware.

«En la mayoría de los ataques de phishing de código de dispositivo actuales, el código se genera dinámicamente cuando un usuario hace clic en el enlace de phishing inicial. Este cambio aparentemente pequeño permite al usuario ver el correo electrónico en cualquier momento para iniciar la cadena de ataque», Proofpoint dicho en un análisis publicado en mayo de 2026. «Estas nuevas implementaciones de las cadenas de ataque de código de dispositivo se pueden comprar a través de ofertas de phishing como servicio (PhaaS), como EvilTokens o Tycoon, o pueden ser creadas y propiedad del actor de amenazas que realiza las campañas».

También se sabe que estas campañas aprovechan el salto de toma de control de cuenta (ATO), una técnica en la que un atacante compromete una cuenta de correo electrónico inicial y luego abusa de ella para enviar enlaces de phishing a un conjunto más amplio de contactos en forma de botón, texto con hipervínculo, incrustado en un documento o código QR. Los enlaces, cuando los visita el destinatario, inician una secuencia de ataque que emplea el proceso de autorización de dispositivos de Microsoft.

ZeroBEC dijo que la campaña que observó implica el uso de pretextos de pago y carpetas compartidas en correos electrónicos de phishing para engañar a las víctimas para que hagan clic en una URL que las lleva a un sitio web de alquiler croata legítimo pero comprometido, que, a su vez, actúa como un orquestador de códigos de dispositivos utilizado para iniciar la cadena de desafío de códigos de dispositivos de Microsoft.

El flujo de trabajo se caracteriza por la presencia de marcadores de desarrollador en idioma turco, aunque las pistas no son suficientes para atribuir definitivamente la procedencia de la campaña. Un análisis más detallado de la infraestructura ha revelado que DEBULL es probablemente una plataforma de phishing como servicio (PhaaS) que utiliza GraphSpy o un flujo de trabajo derivado de GraphSpy para Microsoft 365 y Entra post-explotación.

«Los operadores pueden definir un nombre de página y un slug, editar HTML, CSS y JavaScript directamente y luego elegir cómo se publica el señuelo», dijo ZeroBEC. «Las plantillas integradas incluían una página de autenticación de código de dispositivo de Microsoft 365, una página de devolución de llamada de OAuth y una página de inicio moderna. La plantilla de Microsoft 365 es especialmente importante porque expone el bloque de construcción exacto utilizado por la campaña: una visualización del código de usuario, un comportamiento de copia de código y un vínculo para iniciar sesión en el dispositivo de Microsoft».

«La conclusión más útil es que el arte de identidad al estilo Storm-2372 ahora se está empaquetando en una infraestructura de corredor reutilizable. DEBULL proporciona la capa orientada a la campaña y al operador. GraphSpy o el código derivado de GraphSpy probablemente maneja la capa posterior a la autenticación. El atractivo se puede cambiar sin cambiar la pila de identidades del backend».

La divulgación se produce como lo dijo Cisco Talos. identificado un panel de operador PhaaS con todas las funciones llamado ARToken que comparte infraestructura, contratos API y patrones operativos con la plataforma de phishing de código de dispositivo EvilTokens y está disponible para los afiliados.

Ciberseguridad

«El panel ARToken expone más de 80 puntos finales API para phishing de códigos de dispositivos, persistencia de tokens de actualización primaria (PRT), acceso a correo electrónico, operaciones de compromiso de correo electrónico empresarial (BEC) y exfiltración de SharePoint, todo accesible para los operadores a través de un panel basado en React», dijo Talos.

EvilTokens, como DEBULL, permiten a los atacantes utilizar tokens recolectados como armas para filtrar correos electrónicos, archivos y otros datos confidenciales de cuentas de Microsoft comprometidas, realizar reconocimientos a través de Microsoft Graph API y establecer acceso persistente. Además, incorpora Funciones impulsadas por inteligencia artificial (IA) para automatizar y escalar los flujos de trabajo de BEC, como examinar miles de correos electrónicos recopilados, identificar hilos de correo electrónico relacionados con finanzas y redactar borradores de correos electrónicos de BEC.

ARToken funciona como un conjunto de herramientas completo posterior al compromiso que permite a los operadores aprovechar el token de acceso capturado recuperado luego de una autenticación exitosa del código del dispositivo para mantener el acceso, realizar operaciones de correo electrónico, acceder a OneDrive y SharePoint, y explorar las sesiones de Microsoft 365 de las víctimas fuera del panel utilizando una herramienta dedicada conocida como ARTBrowser.

«Estas características indican que la plataforma es más madura que un simple kit de phishing de código de dispositivo: es un entorno de operaciones BEC completo», dijo el investigador de Talos, Michael Kelley.

El aumento de los ataques de phishing de códigos de dispositivos también ha llevado a otros kits PhaaS como Tycoon 2FA a adoptar la técnica para secuestrar cuentas de Microsoft 365 en sus rebote después de una operación policial, lo que indica un cambio más amplio dentro del panorama de amenazas.

«Los operadores de Tycoon 2FA han reutilizado su kit PhaaS existente como marco de entrega para el phishing de concesión de código de dispositivo OAuth», eSentire anotado en mayo de 2026. «El ataque comienza cuando una víctima hace clic en una URL de seguimiento de clics de Trustifi en un correo electrónico atractivo y culmina cuando la víctima, sin saberlo, otorga tokens OAuth a un dispositivo controlado por el atacante a través del flujo legítimo de inicio de sesión del dispositivo de Microsoft en microsoft.com/devicelogin».

Un problema público de GitHub podría engañar a los flujos de trabajo agentes de GitHub para que filtren datos de repositorios privados

Un asunto público puede engañar Flujos de trabajo agentes de GitHub en filtrar el contenido de los repositorios privados de una organización, según han demostrado investigadores de Noma Security.

El atacante sólo necesita abrir un problema de apariencia normal en un repositorio público, sin credenciales robadas y sin acceso a la organización. Si esa organización le ha dado al agente acceso de lectura a todos sus repositorios, incluidos los privados, el problema puede llevarlo a incluir contenidos privados en un comentario público.

Noma llama a la técnica GitPerdido. El objetivo es Flujos de trabajo agentes de GitHubuna característica ahora en versión preliminar pública que GitHub lanzó en febrero. En lugar de escribir scripts de automatización, escribe instrucciones para un agente de IA en inglés sencillo en un archivo Markdown. El agente lee problemas y solicitudes de extracción, ejecuta herramientas y responde por sí solo.

Puede funcionar con GitHub Copilot, Claude de Anthropic, Google Gemini u OpenAI Codex. Los flujos de trabajo son de solo lectura de forma predeterminada, pero una organización puede entregarle un token con acceso de lectura en todos sus repositorios para darle contexto entre repositorios, incluidos los privados.

Esa concesión es la configuración que GitLost vuelve en su contra.

Cómo funciona el truco

La debilidad es bien conocida: inyección inmediata indirecta. Un agente de IA no puede distinguir de manera confiable entre las instrucciones de su propietario y las instrucciones ocultas dentro del contenido que lee. Entonces, si un atacante escribe esas instrucciones en un problema, el agente puede simplemente seguirlas.

En Noma’s prueba de conceptoel problema malicioso se disfrazó de una solicitud de rutina de un vicepresidente de ventas después de una reunión con un cliente. El flujo de trabajo al que llegó estaba configurado para activarse cuando se asigna un problema, leerlo y responder con un comentario. También tenía acceso de lectura a otros repositorios de la organización.

Ciberseguridad

Una vez que una automatización de rutina asignó el problema, el agente extrajo el archivo README de un repositorio privado y lo pegó en un comentario público sobre el problema.

GitHub construyó barreras de seguridad para detener exactamente esto. en su propio documentaciónla compañía advierte que «los agentes de IA pueden ser manipulados mediante inyección rápida, contenido de repositorio malicioso o herramientas comprometidas», y el producto se envía con sandboxing, tokens de solo lectura de forma predeterminada, limpieza de entradas y un paso de detección de amenazas que escanea la salida propuesta de un agente antes de publicarla.

Noma informó que en su prueba, un cambio de una palabra fue suficiente para pasar desapercibido. Anteponer la instrucción maliciosa con «Además» llevó al modelo a tratarlo como una tarea de seguimiento, no como algo que rechazar, y la barandilla lo dejó pasar.

¿Por qué este es diferente?

Lo que distingue a GitLost es lo que el atacante puede controlar. «Los ejemplos anteriores de inyección rápida tenían que ver en gran medida con la manipulación de lo que decía un agente», Sasi Levi, líder de investigación de seguridad de Seguridad Nomadijo a The Hacker News. «GitLost trata de manipular lo que hace un agente con sus permisos».

El agente aquí, dijo, no es una ventana de chat sino un actor acreditado que se encuentra dentro de la infraestructura adyacente a CI/CD de una organización, con acceso de lectura que abarca repositorios que el atacante no puede ver. No toca ningún servidor, no necesita credenciales robadas y no requiere acceso de escritura a nada privado. El atacante sólo tiene que abrir un tema público.

La configuración se ajusta a lo que el desarrollador Simon Willison llamó el «trifecta letal»y Levi usa el mismo término: un agente que puede acceder a datos privados, recibe contenido externo que no es de confianza y tiene una forma de enviar datos. Combine los tres y tendrá una ruta de fuga.

Este no es el tipo de error que soluciona un parche; Como lo plantea Levi, es una consecuencia estructural de otorgar a los agentes de IA credenciales permanentes mientras les hacen leer texto accesible al atacante.

¿Por qué esto sigue sucediendo?

GitLost es el último de una serie del mismo tipo de ataque, y THN ha informado de varios en los últimos meses. Una falla en Claude Code GitHub Action de Anthropic permitió que un solo problema malicioso empujara al agente a filtrar secretos y tomar acceso de escritura a un repositorio.

RoguePilot de Orca Security utilizó un mensaje oculto en un problema de GitHub para hacer que Copilot filtrara el token privilegiado de un repositorio. La versión del problema del agente GitHub se remonta al menos a mayo de 2025, cuando Invariant Labs presentado que un problema público podría empujar a un agente conectado al servidor MCP de GitHub a leer un repositorio privado y filtrarlo a través de una solicitud de extracción; los investigadores lo llamaron arquitectónico, sin ningún parche del lado del servidor para cerrarlo.

Ciberseguridad

Un estudio entre proveedores llamado Comentar y controlar luego engañó a los agentes de Claude Code, Gemini CLI y GitHub Copilot para que filtraran sus propias claves API a través de textos de problemas y solicitudes de extracción, eludiendo las defensas de tiempo de ejecución agregadas de GitHub en el camino.

Que hacer ahora

Noma reveló GitLost a GitHub y publicó sus hallazgos con el conocimiento de la empresa. La exposición se limita a organizaciones que han habilitado la vista previa y han conectado a un agente para leer información pública que no es de confianza mientras mantienen acceso de lectura a repositorios privados y pueden publicar en público.

Lo que un atacante podría obtener depende de lo que el token del agente pueda ver, desde código fuente propietario hasta claves internas, documentos de diseño o secretos de CI/CD. Como dice Levi, el alcance es lo que más importa: un token de agente con alcance en el repositorio único que clasifica es «mucho menos peligroso que uno con acceso de lectura amplio para toda la organización» por conveniencia.

En la práctica, ese acceso entre repositorios proviene de un token de acceso personal que la organización configura, por lo que el token se aplica al repositorio que el flujo de trabajo clasifica en lugar de a toda la organización. Las escrituras fluyen solo a través de salidas declaradas seguras, por lo tanto, limite lo que un flujo de trabajo público puede publicar, porque el comentario que produce es el canal de exfiltración. Restrinja el contenido de los autores sobre el cual actuará el agente y controle sus resultados tras la revisión humana.

El paso de detección de amenazas de GitHub escanea la salida de un agente antes de publicarlo, pero la omisión de una palabra de Noma es un recordatorio de que un filtro es un respaldo, no un límite.

GitHub, al igual que los otros proveedores, construyó barreras de seguridad exactamente para esta clase de ataque, y un cambio de una palabra las evitó. Los investigadores y los propios proveedores siguen archivando el resultado bajo «limitación arquitectónica», y el punto de Levi es por qué se mantiene la etiqueta: en el lenguaje natural, no hay una línea clara entre los datos y las instrucciones como ocurre en SQL, por lo que la solución se basa en la arquitectura en lugar de filtrar la inyección, en el aislamiento, las credenciales de alcance y la revisión por etapas.

Hasta que exista ese límite, cualquier agente que lea datos privados, reciba información que no sea de confianza y pueda publicar en público está a un paso inteligentemente redactado de una filtración.

Una falla en la IA del escritor podría permitir que las vistas previas de los agentes filtren tokens de sesión entre los inquilinos

Investigadores de ciberseguridad han revelado detalles de una vulnerabilidad de aislamiento de sesión crítica ahora parcheada en Escritoruna plataforma empresarial de inteligencia artificial (IA) generativa, que podría resultar en un compromiso entre inquilinos.

La vulnerabilidad de un clic ha recibido el nombre en clave Escribir por el equipo de investigación de seguridad de arena.

«Un extraño podría pasar de no tener acceso a hacerse cargo de cualquier organización de Writer AI dentro de empresas líderes en la industria, con nada más que un vínculo», dijo la empresa de ciberseguridad. dicho en un informe compartido con The Hacker News.

Dicho de otra manera, se podría abusar de la deficiencia para hacerse cargo de la cuenta de escritor de una víctima y usarla para acceder a chats privados, documentos y otros datos confidenciales relacionados con agentes, configuraciones, modelos privados, conectores y credenciales de modelos de lenguaje grande (LLM).

Peor aún, se podría abusar de él para tomar el control administrativo dependiendo del papel de la víctima. Un aspecto importante del fallo es que el atacante y la víctima no tienen por qué pertenecer a la misma organización.

Ciberseguridad

Un atacante puede crear un agente en su propia cuenta de Writer y compartir un enlace de vista previa. Eso es todo lo que se necesita para activar la vulnerabilidad, esencialmente haciendo posible secuestrar la cuenta de una víctima que hace clic en el enlace y inicia sesión con su propia sesión.

«Un atacante puede abusar de la zona de pruebas administrada por la IA de Writer para recopilar sesiones que pertenecen a compañías completamente separadas y actuar dentro de cada una de ellas como un usuario real, sin ningún punto de apoyo previo en ninguna parte», dijo Sand Security.

WriteOut también socava el modelo de responsabilidad compartida, ya que rompe las protecciones de aislamiento de los inquilinos al aprovechar la ventaja de Writer. función de vista previa en vivo que permite a los usuarios obtener una vista previa de la aplicación a través de Writer Framework.

Toda la cadena de ataque se desarrolla de la siguiente manera:

  • Un atacante crea un agente con una vista previa en vivo y comparte su enlace de vista previa pública.
  • Cuando un usuario de Writer que ha iniciado sesión abre ese enlace, su navegador adjunta su cookie de sesión de Writer a la solicitud.
  • El proxy de vista previa envía esa cookie al servidor del atacante. salvadera.
  • El código contenido dentro del entorno limitado controlado por el atacante lee el token de sesión reenviado y se filtra.
  • él.
  • El atacante reproduce el token y obtiene el control de la cuenta de escritor de la víctima.

Debido a que un atacante puede indicarle a su agente malicioso prediseñado que ejecute código dentro de la zona de pruebas administrada y controlada, esto hace posible leer la memoria del proceso de la zona de pruebas, recuperar el token de sesión exfiltrado de la víctima y transmitirlo a un servidor que mantienen.

Ciberseguridad

Luego de una divulgación responsable, Writer resolvió el problema impidiendo que la cookie de sesión del usuario se reenvíe por completo a las vistas previas de la zona de pruebas y moviéndolas a un origen aislado.

«El escritor no fue descuidado, había barreras de seguridad. El filtrado del lado de entrada intentó impedir que los usuarios leyeran variables de entorno o enviaran código obviamente malicioso», dijo Sand Security. «El problema es lo que observaron esas comprobaciones: las instrucciones, no el comportamiento en tiempo de ejecución».

«Eludir la barrera de seguridad fue bastante sencillo: en lugar de pegar la carga útil en línea, simplemente le dijimos al agente que buscara y ejecutara un script remoto. La barrera de seguridad vio una solicitud benigna de ‘descargar y ejecutar’, y la lógica de explotación real nunca apareció en el mensaje».