Un hacker de habla rusa utiliza la CLI de Google Gemini para controlar la botnet de ocho PC de una clínica dental – CYBERDEFENSA.MX

Un actor de amenazas solitario de habla rusa conocido como «bandacampro» subcontrató una parte de sus operaciones a la inteligencia artificial (IA) Gemini CLI de código abierto de Google y se apoderó de una botnet en vivo.

Los hallazgos provienen de un análisis de 200 registros de sesiones de Gemini CLI entre el 19 de marzo y el 21 de abril de 2026, que encontró que el actor de amenazas utilizaba IA, entre otras cosas, para descifrar contraseñas, configurar un proxy residencial, comprometer a los comerciantes de WordPress y planificar un esquema de fraude telefónico con criptomonedas dirigido a personas mayores en los EE. UU. y Canadá.

«Los registros documentaron cómo el actor de la amenaza utilizó un agente de inteligencia artificial para migrar un servidor de comando y control (C&C) y controlar una botnet de pequeña escala, entre otras actividades de piratería», dijeron los investigadores de Trend Micro Joseph C Chen, Philippe Lin, Lucas Silva, Vladimir Kropotov y Fyodor Yarochkin. dicho.

«Toda la operación de C&C cabe en tres archivos de texto sin formato que suman aproximadamente 5 KB, lo que la hace altamente replicable y efectivamente desechable. También se observó que la IA proponía proactivamente (sin preguntar) mejoras 59 veces sin que se lo pidieran».

Específicamente, se dice que el actor de amenazas abusó de la CLI de Google Gemini para implementar y operar una infraestructura C&C para controlar ocho computadoras en una clínica dental y acceder a su base de datos OpenDental. Además de escribir fragmentos de código, la IA sirvió como «agente de piratería principal, consultor e interfaz» para toda la operación.

Ciberseguridad

Esto incluyó configurar el servidor, implementarlo en un nuevo servidor privado virtual (VPS), configurar la infraestructura, configurar túneles de Cloudflare, administrar los bots y depurar problemas de conectividad.

Detalles de «bandcampro» Surgió por primera vez a finales de mayo de 2026 en relación con una campaña denominada Cebo patriota que utilizó técnicas de operación de información (IO) asistida por IA para ejecutar un canal de Telegram, dirigido a audiencias estadounidenses políticamente comprometidas para el fraude de criptomonedas y el robo de credenciales asistido por IA.

Trend Micro ha descrito al actor de amenazas como un hablante de ruso que utilizó Google Gemini para «suplantar a un patriota veterano estadounidense y evitar frases en ruso», mientras engañaba al agente de IA para que eludiera sus barreras asumiendo el papel de un «pentester autorizado».

Se dice que el actor de amenazas ejecutó indicaciones para estudiar la antigua infraestructura de C&C donde las máquinas víctimas se conectaban mediante túneles de Cloudflare y la migraron a una nueva arquitectura en seis minutos. La arquitectura implica que las víctimas envíen solicitudes salientes a un servidor C&C a través de HTTPS para extraer y ejecutar comandos de PowerShell organizados por el actor de amenazas en el servidor.

«La migración encontró errores de inmediato, pero el agente de IA los resolvió: cuando el servidor de distribución de carga útil devolvió un error ‘502 Bad Gateway’, la IA diagnosticó el problema y agregó automáticamente el encabezado necesario para resolverlo», dijo Trend Micro.

«Como Cloudflare aún bloqueaba las solicitudes, la IA identificó que el encabezado User-Agent era necesario para omitir el WAF y, por lo tanto, lo agregó al encabezado de la solicitud. El actor no realizó ninguna depuración y la migración se realizó en solo seis minutos».

Una vez que se completó la migración, el agente de IA llevó a cabo una depuración adicional para corregir con éxito los errores que dejaron a todas las máquinas víctimas desconectadas de la infraestructura de C&C. Además, se ha descubierto que el actor de amenazas aprovecha el agente de IA para realizar tareas de gestión de botnets enviando instrucciones en lenguaje natural en ruso, lo que luego permitió a la herramienta de IA realizar las siguientes tareas:

  • Informar qué máquinas están activas
  • Enviar un comando de enumeración de archivos al bot
  • Enviar comandos de reconocimiento a la máquina de la recepción.
  • Genere un comando de PowerShell de una línea para infectar una máquina

Lo que es particularmente preocupante acerca de esta configuración asistida por IA es que toda la operación de C&C se puede transferir fácilmente a un servidor nuevo a través de tres archivos de rebajas que le indican al agente que desactive sus protecciones de seguridad, contienen la descripción de la arquitectura e incluyen pasos para construirla desde cero, lo que hace que las eliminaciones sean mucho menos efectivas que antes.

«Facilitado por la IA, la infraestructura se vuelve desechable y los operadores reemplazables», afirmó Trend Micro. «Aunque las eliminaciones siguen siendo eficientes, su impacto es mucho menor. Si se quema un servidor, el actor podría simplemente descomprimir el paquete en un nuevo VPS, y la IA configura y restaura todo en unos minutos».

Los hallazgos muestran que la tecnología no sólo puede recortar los recursos necesarios para ejecutar operaciones a gran escala, sino que también permite a los malos actores con poco o ningún conocimiento técnico establecer tales esquemas con un mínimo esfuerzo o distribuirlos en foros clandestinos en forma de archivos de habilidades maliciosos, allanando efectivamente el camino para nuevos servicios de malware impulsados ​​por IA que van más allá de los modelos convencionales «como servicio».

Este manual también tiene el efecto secundario de complicar los esfuerzos de atribución, ya que no existe un servicio centralizado que buscar y un agente de IA puede regenerar o modificar fácilmente cualquier componente a voluntad para eludir huellas dactilares específicas.

Ciberseguridad

En un momento dado, se dice que «bandcampro» impulsó a la IA a construir una «bomba de agente» autopropagadora que escanearía la red e ingresaría en tantas máquinas como fuera posible, una solicitud que el agente rechazó, afirmando que estaba «cruzando la línea». Al mismo tiempo, ofrecía sugerencias útiles para superar las limitaciones manualmente.

También se ha descubierto que el actor de la amenaza depende del agente de IA para otras tareas, a saber:

  • Desciframiento de contraseñas, que utilizaba el agente como motor de mutación de credenciales para predecir posibles contraseñas basándose en una lista de entrada obtenida de Antipúblicoque mantiene una base de datos de credenciales filtradas y aprovechó esas conjeturas como herramienta de fuerza bruta para los paneles de administración de WordPress, obteniendo acceso con éxito en unos pocos casos.
  • Explotación de credenciales, que analizó los volcados de 1Password para encontrar vías de explotación. La tarea, sin embargo, terminó en fracaso, aunque sólo fuera porque el la ventana de contexto duró demasiadoy perdió la noción de lo que se suponía que debía hacer.
  • Planificación del fraude con criptomonedas, que implicó discutir la viabilidad de establecer un esquema falso por teléfono dirigido a las personas mayores en los EE. UU. y Canadá.

«A lo largo de todo el mes de registros, el actor contribuyó con el 11% del texto producido y la IA con el 89%, doce veces el recuento de palabras del actor», concluyó Trend Micro. «El actor proporcionó dirección estratégica y funcionó como gerente de producto, mientras que la IA era todo su equipo de ingeniería, manejando el 80% del diseño arquitectónico, el 100% de la codificación y la ejecución de comandos del sistema, y ​​el 90% del diagnóstico y depuración de problemas».

«El modelo de archivo de habilidades portátil significa que esta metodología probablemente se difundirá. El archivo de habilidades es texto sin formato, es poco probable que los escáneres de malware tradicionales lo detecten por sí solo, se puede compartir en foros y modificar en segundos. Convierte a cualquier agente codificador de IA capaz en un operador C&C, si puede persuadir con éxito los mecanismos de seguridad integrados en los agentes de IA».

La pulverización de contraseñas de la CLI de Azure llega a al menos 78 cuentas de Microsoft en más de 81 millones de intentos – CYBERDEFENSA.MX

Los investigadores de ciberseguridad han advertido sobre un «ataque masivo, continuo y automatizado de pulverización de contraseñas» dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, comprometiendo docenas de cuentas en el proceso.

La actividad, por Cazadorase origina en un rango de direcciones IPv6 (2a0a:d683::/32) controlado por el proveedor de infraestructura de Internet LSHIY LLC (AS32167).

«Entre el 12 y el 26 de junio, el actor de amenazas detrás de esto realizó más de 81 millones de intentos de inicio de sesión y comprometió con éxito al menos 78 cuentas de Microsoft en 64 organizaciones», dijo la compañía en un comunicado. «El objetivo de estos ataques parece basarse enteramente en la prevalencia de contraseñas en listas combinadas de contraseñas comprometidas, y no es específico del tipo de negocio o industria».

Lo que hace que el ataque de pulverización de contraseñas sea digno de mención no es solo la escala, sino también el hecho de que muchas de las organizaciones comprometidas tenían habilitadas políticas de acceso condicional. Específicamente, se descubrió que la campaña aprovecha un flujo OAuth obsoleto llamado Credenciales de contraseña del propietario de recursos (ROPC) para eludir las protecciones de la Política de acceso condicional (CAP).

ROPC es un tipo de concesión de OAuth 2.0 heredado en el que un usuario proporciona directamente su nombre de usuario y contraseña a una aplicación cliente, que luego envía estas credenciales a un servidor de autorización para intercambiarlas por un token de acceso. Quedó obsoleto en OAuth 2.1.

Ciberseguridad

En su documentación, Microsoft recomienda a los clientes que no utilicen ROPC, argumentando que es incompatible con la autenticación multifactor (MFA).

«En la mayoría de los escenarios, hay alternativas más seguras disponibles y recomendadas», afirma el gigante tecnológico. dice. «Este flujo requiere un grado muy alto de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Sólo debe utilizar este flujo cuando no sean viables flujos más seguros».

Se dice que los ataques de pulverización de credenciales y tokens dieron como resultado un puñado de inicios de sesión exitosos por día entre el 12 y el 21 de junio de 2026, con un promedio de dos a cuatro cuentas comprometidas diariamente, con la excepción del 19 de junio, cuando 12 cuentas de usuario (también conocidas como identidades) fueron comprometidas. La cadencia constante cambió el 22 de junio, con 30 identidades en 23 empresas afectadas.

En total, 78 cuentas de usuarios se vieron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de la actividad de pulverización de contraseñas provino de LSHIY LLC. Algunas de las direcciones IP se resuelven en EE. UU., mientras que otras se resuelven en China.

«Estos ataques son parte de una gran ola de ataques de pulverización de credenciales en algunos ASN diferentes», dijo Huntress, y agregó que ha sido testigo de un aumento de más de 155 veces en el volumen de ataques de pulverización de credenciales en toda su base de clientes. «Los ataques aumentaron en particular desde finales de mayo hasta principios de junio, con un valor medio actual de alrededor de 1.964 ataques fallidos por mes por inquilino protegido por Huntress».

La actividad parece utilizar específicamente como arma antiguas combinaciones de nombre de usuario y contraseña que fueron violadas previamente pero que nunca se rotaron. El uso del vector ROPC significó que los atacantes pudieron apuntar a empresas que habían implementado MFA, pero no se aplicó ni se configuró para tener en cuenta los inicios de sesión ROPC de la CLI de Azure.

Esto incluyó escenarios en los que no se activó MFA:

  • Aplicar MFA solo para aplicaciones específicas, a diferencia de «Todas las aplicaciones en la nube», por lo que no se cubren los inicios de sesión de la CLI de Azure utilizados por los actores de amenazas.
  • Aplicar MFA solo para grupos de usuarios específicos, como administradores
  • Aplicar MFA solo cuando las solicitudes se originan en ubicaciones que no son de confianza
Ciberseguridad

«Vale la pena señalar que ocho empresas afectadas por la campaña no tenían ninguna política de MFA», dijo Huntress. «Si bien los actores de amenazas en esta campaña pudieron ingresar a pesar de que se configuró MFA, la conclusión no debería ser que MFA no funcione en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas adecuadamente para abordar el flujo de autorización utilizado en estos incidentes».

Para contrarrestar esta línea de ataque, se recomienda a las organizaciones exigir MFA para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente al habilitar CAP, restringir la aplicación CLI de Azure para usuarios que no sean administradores y priorizar la respuesta según la validez de las credenciales.

«Este ataque revela grietas en los CAP que no se han configurado adecuadamente», concluyeron los investigadores de Huntress. «Todavía existen debilidades potenciales en la forma en que se implementan los CAP que pueden permitir que los actores de amenazas se escapen. Un error flagrante aquí es que los protocolos heredados como ROPC pueden eludir por completo algunos CAP mal configurados, ya que no pasan por el punto final de autorización donde se aplican las políticas».

Google corrige CVSS 10 Gemini CLI CI RCE y fallas del cursor que permiten la ejecución de código – CYBERDEFENSA.MX

Google ha abordado una falla de seguridad de máxima gravedad en Gemini CLI: el paquete npm «@google/gemini-cli» y el flujo de trabajo de acciones GitHub «google-github-actions/run-gemini-cli», que podría haber permitido a los atacantes ejecutar comandos arbitrarios en sistemas host.

«La vulnerabilidad permitió a un atacante externo sin privilegios forzar la carga de su propio contenido malicioso como configuración Gemini», Novee Security dicho en un informe del miércoles. «Esto desencadenó la ejecución del comando directamente en el sistema host, evitando la seguridad incluso antes de que se inicializara el entorno limitado del agente».

La deficiencia, que no tiene un identificador CVE, tiene una puntuación CVSS de 10,0. Afecta a las siguientes versiones:

  • @google/gemini-cli <0.39.1
  • @google/gemini-cli < 0.40.0-preview.3
  • google-github-actions/run-gemini-cli <0.1.22

en su aviso publicado La semana pasada, Google dijo que el impacto se limita a los flujos de trabajo que utilizan Gemini CLI en modo sin cabeza, y agregó que cualquier uso de la herramienta en modo sin cabeza sin confianza en la carpeta requerirá una revisión manual para configurar este mecanismo de confianza.

«En versiones anteriores, Gemini CLI que se ejecuta en entornos CI (modo sin cabeza) confiaba automáticamente en las carpetas del espacio de trabajo con el fin de cargar la configuración y las variables de entorno», decía.

Ciberseguridad

«Esto es potencialmente riesgoso en situaciones en las que Gemini CLI se ejecuta en carpetas que no son de confianza en modo sin cabeza (por ejemplo, flujos de trabajo de CI que revisan las solicitudes de extracción enviadas por los usuarios). Si se usa con contenidos de directorios que no son de confianza, esto podría llevar a la ejecución remota de código a través de variables de entorno maliciosas en el directorio .gemini/ local».

Esta confianza automática de la carpeta del espacio de trabajo actual significaba que la herramienta podía cargar cualquier configuración de agente que encontrara sin revisión, espacio aislado o consentimiento explícito del usuario. Un atacante podría convertir este comportamiento en un arma al implementar una configuración especialmente diseñada que podría allanar el camino para la ejecución de código en el host que ejecuta el agente, convirtiendo efectivamente los canales de CI/CD en rutas de ataque a la cadena de suministro.

La actualización soluciona el problema al requerir que se confíe explícitamente en las carpetas antes de poder acceder a los archivos de configuración. Con ese fin, se insta a los usuarios a revisar sus flujos de trabajo y adoptar uno de dos enfoques:

  • Si el flujo de trabajo se ejecuta con entradas confiables (por ejemplo, revisar solicitudes de extracción de colaboradores confiables), configure GEMINI_TRUST_WORKSPACE: ‘true’ en el flujo de trabajo.
  • Si el flujo de trabajo se ejecuta en entradas que no son de confianza, revise la guía de Google en google-github-acciones/run-gemini-cli para reforzar el flujo de trabajo contra contenido malicioso y establecer la variable de entorno.

El gigante tecnológico también señaló que está tomando medidas para reforzar la lista de herramientas permitidas cuando Gemini CLI está configurado para ejecutarse en modo –yolo para evitar escenarios en los que entradas no confiables (por ejemplo, problemas de GitHub enviados por el usuario) podrían conducir a la ejecución remota de código mediante inyección rápida, aprovechando el hecho de que el modo de aprobación automática ignoraría cualquier lista de permitidos en «~/.gemini/settings.json» y ejecutaría todas las llamadas a herramientas automáticamente (incluido «run_shell_command») sin necesidad de usuario. confirmación.

«En la versión 0.39.1, el motor de políticas Gemini CLI ahora evalúa la lista de herramientas permitidas en el modo –yolo, lo cual es útil para los flujos de trabajo de CI que permiten incluir algunos comandos seguros para ejecutar cuando se procesan entradas que no son de confianza», dijo Google. «Como resultado, algunos flujos de trabajo que anteriormente dependían de este comportamiento pueden fallar silenciosamente a menos que se modifiquen las listas de herramientas permitidas para adaptarse a la tarea».

El error del cursor conduce a la ejecución del código

La divulgación se produce cuando Novee Security también destacó una vulnerabilidad de alta gravedad en la herramienta de desarrollo basada en IA Cursor anterior a la versión 2.5 (CVE-2026-26268, puntuación CVSS: 8.1) que también podría conducir a la ejecución de código arbitrario mediante una inyección rápida.

Cursor, en una alerta liberado en febrero de 2026, lo describió como un caso de escape de la zona de pruebas a través de configuraciones .git, lo que permite a un agente deshonesto configurar un repositorio simple («».git») con un archivo malicioso. gancho git eso se activa automáticamente cada vez que se ejecuta una operación de confirmación dentro del contexto del repositorio integrado sin requerir ninguna interacción del usuario.

El resultado final es la ejecución de código arbitrario aprobado automáticamente en la máquina de la víctima mediante la siguiente secuencia de acciones:

  • El usuario clona un repositorio público de GitHub con el repositorio básico integrado que contiene un enlace malicioso posterior al pago
  • El usuario abre el repositorio en CursorIDE
  • Los usuarios solicitan un mensaje inocuo para «explicar el código base»
  • El agente de cursor analiza el AGENTES.md que le indica que navegue hasta el repositorio básico y realiza un «git checkout» de la rama maestra
  • Se activa el gancho posterior al pago dentro del repositorio básico, lo que lleva a la ejecución del código.

«La causa raíz no es una falla en la lógica central del producto Cursor, sino más bien una consecuencia de una interacción de características en Git, una que se vuelve explotable en el momento en que un agente de IA comienza a ejecutar de forma autónoma operaciones de Git dentro de un repositorio que no controla», dijo el investigador de seguridad Assaf Levkovich. dicho.

Ciberseguridad

«Cuando el agente ejecuta git checkout como parte del cumplimiento de una solicitud de rutina, no está haciendo nada que el usuario no haya autorizado implícitamente. Pero ni el usuario ni el agente tienen visibilidad de lo que las reglas del cursor del repositorio han puesto en marcha. Un gancho malicioso de confirmación previa incrustado en un repositorio anidado se ejecuta silenciosamente, fuera de la cadena de razonamiento del agente y fuera del campo de visión del usuario».

Los hallazgos también coinciden con el descubrimiento de otra vulnerabilidad de control de acceso de alta gravedad en el IDE (puntuación CVSS: 8,2) que podría permitir que cualquier extensión instalada acceda a claves y credenciales API confidenciales almacenadas localmente en una base de datos SQLite, lo que permitiría la apropiación de cuentas, la exposición de datos y pérdidas financieras derivadas del uso no autorizado de API. El problema, con nombre en clave CursorJacking por LayerX, permanece sin parchear.

«Cursor no impone límites de control de acceso entre las extensiones y esta base de datos», dijo el investigador de LayerX Roy Paz. «La explotación de esta vulnerabilidad puede provocar la exposición de tokens de sesión y claves API, acceso no autorizado a los servicios backend de Cursor y robo de datos mediante la suplantación de usuarios».

Cursor ha sostenido que el acceso está limitado a la máquina local donde el usuario ya instaló y otorgó permisos a la extensión, lo que significa que cualquier extensión maliciosa con acceso al sistema de archivos local podría potencialmente extraer información valiosa de varios almacenes de datos de aplicaciones. Para contrarrestar la amenaza, es esencial que los usuarios se limiten a descargar extensiones confiables.

CLI de Bitwarden comprometida en la campaña en curso de la cadena de suministro de Checkmarx – CYBERDEFENSA.MX

CLI de Bitwarden se ha visto comprometido como parte de la campaña de cadena de suministro Checkmarx recientemente descubierta y en curso, según nuevos hallazgos de JFrog y Socket.

«La versión del paquete afectado parece ser @bitwarden/cli@2026.4.0y el código malicioso se publicó en ‘bw1.js’, un archivo incluido en el contenido del paquete», dijo la empresa de seguridad de aplicaciones. dicho.

«El ataque parece haber aprovechado una GitHub Action comprometida en el proceso de CI/CD de Bitwarden, consistente con el patrón observado en otros repositorios afectados en esta campaña».

En una publicación en X, JFrog dicho la versión fraudulenta del paquete «roba tokens de GitHub/npm, .ssh, .env, historial de shell, acciones de GitHub y secretos de la nube, luego filtra los datos a dominios privados y a medida que GitHub se compromete».

Si bien la versión maliciosa ya no está disponible para descargar desde npm, Socket dijo que el compromiso sigue el mismo vector de cadena de suministro de GitHub Actions identificado en la campaña Checkmarx.

Ciberseguridad

Como parte del esfuerzo, se descubrió que los actores de amenazas abusan de tokens de GitHub robados para inyectar un nuevo flujo de trabajo de GitHub Actions que captura secretos disponibles para la ejecución del flujo de trabajo y utiliza credenciales npm recopiladas para enviar versiones maliciosas del paquete para leer el malware a los usuarios posteriores.

Según el investigador de seguridad Adnan Khan, se dice que el actor de amenazas utilizó un flujo de trabajo malicioso para publicar la CLI maliciosa de bitwarden. «Creo que esta es la primera vez que un paquete que utiliza la publicación confiable de NPM se ve comprometido», Khan agregado.

Cadena de ataque CLI de Bitwarden | Fuente: Seguridad OX

Se sospecha que el actor de amenazas conocido como TeamPCP está detrás del último ataque dirigido a Checkmarx. Al momento de escribir este artículo, TeamPCP La cuenta X ha sido suspendida. por violar las reglas de la plataforma.

OX Security, en un desglose del ataque, dicho identificó la cadena «Shai-Hulud: The Third Coming» en el paquete, lo que sugiere que esta es probablemente la siguiente fase de la campaña de ataque a la cadena de suministro que salió a la luz el año pasado.

Referencia al «Shai-Hulud: La Tercera Venida»

«El último incidente de Shai Hulud es sólo el último de una larga cadena de amenazas dirigidas a desarrolladores de todo el mundo. Los datos de los usuarios se están filtrando públicamente a GitHub, a menudo pasando desapercibidos porque las herramientas de seguridad normalmente no señalan los datos que se envían allí», dijo Moshe Siman Tov Bustan, líder del equipo de investigación de seguridad de OX Security.

«Esto hace que el riesgo sea significativamente más peligroso: cualquiera que busque en GitHub puede potencialmente encontrar y acceder a esas credenciales. En ese punto, los datos confidenciales ya no están en manos de un solo actor de amenazas, sino que están expuestos a cualquiera».

Cuando se le contactó para hacer comentarios, Bitwarden confirmó el incidente, pero enfatizó que no se accedió a datos del usuario final como parte del ataque. La declaración completa se reproduce textualmente a continuación:

El equipo de seguridad de Bitwarden identificó y contuvo un paquete malicioso que se distribuyó brevemente a través de la ruta de entrega npm para @bitwarden/cli@2026.4.0 entre las 5:57 p.m. y las 7:30 p.m. (ET) el 22 de abril de 2026, en relación con un incidente más amplio en la cadena de suministro de Checkmarx.

Ciberseguridad

La investigación no encontró evidencia de que se hubiera accedido a los datos de la bóveda del usuario final o que estuvieran en riesgo, o que los datos o sistemas de producción estuvieran comprometidos. Una vez que se detectó el problema, se revocó el acceso comprometido, la versión maliciosa de npm quedó obsoleta y se iniciaron medidas de reparación de inmediato.

El problema afectó el mecanismo de distribución de npm para la CLI durante esa ventana limitada, no la integridad del código base legítimo de la CLI de Bitwarden ni los datos almacenados de la bóveda.

Los usuarios que no descargaron el paquete de npm durante esa ventana no se vieron afectados. Bitwarden ha completado una revisión de los entornos internos, las rutas de lanzamiento y los sistemas relacionados, y no se han identificado productos o entornos afectados adicionales en este momento. Se está emitiendo un CVE para Bitwarden CLI versión 2026.4.0 en relación con este incidente.

(Esta es una historia en desarrollo. Consulte para obtener más detalles).