VS Code agrega un retraso de actualización automática de extensión de 2 horas para limitar los ataques a la cadena de suministro

Microsoft ha anunciado que Visual Studio Code (VS Code) aplicará un retraso de dos horas antes de que las extensiones para el entorno de desarrollo integrado (IDE) se actualicen automáticamente a una versión más nueva en un intento de abordar las amenazas a la cadena de suministro de software.

«Cuando las actualizaciones automáticas están habilitadas, las nuevas versiones se actualizan automáticamente dos horas después de su publicación, agregando una capa adicional de protección contra versiones problemáticas o potencialmente comprometidas», Microsoft dicho.

La nueva función está disponible a partir de VS Code 1.123.

El gigante tecnológico señaló que los usuarios aún tienen la opción de actualizar cualquier extensión inmediatamente en cualquier momento usando el botón «Actualizar». Cuando las extensiones tienen actualizaciones pendientes, un motivo por el cual aún no se han actualizado estará disponible en la vista de detalles, junto con cuándo se realizará la actualización automática.

Dicho esto, este retraso de dos horas no se aplica a extensiones de editores confiables como Microsoft, GitHub y OpenAI, agregó. Las extensiones de dichos editores seguirán actualizándose inmediatamente.

Ciberseguridad

El desarrollo se produce días después de que RubyGems agregara una función de enfriamiento opcional a Bundler 4.0.13 que retrasa la instalación de versiones de gemas recién publicadas durante un período predefinido.

Específicamente, la función permite a los desarrolladores configurar Bundler para introducir un retraso de instalación basado en el tiempo con el objetivo de reducir la exposición potencial que surge de las versiones maliciosas recientemente publicadas.

Durante el año pasado, también se agregaron controles de instalación similares a Bun, pnpm, npm y Yarn.

  • Bollo – edad mínima de liberación (Bun 1.3+)
  • mpn – edad mínima de lanzamiento (npm v11.10.0+)
  • pnpm – edad mínima de liberación (pnpm 10.16+)
  • Hilo – npmMinimalAgeGate (Yarn Berry 4.10.0+)

Estos cambios llegan en el contexto de un aumento en los incidentes en la cadena de suministro de software que tienen como objetivo varios ecosistemas para violar los sistemas de los desarrolladores y propagar malware a los usuarios intermedios.

Antes de imponer un umbral de edad mínima antes de que se pueda instalar una versión de paquete en particular, el control defensivo minimiza la ventana durante la cual se propaga antes de que los mantenedores del registro lo marquen como malicioso y lo eliminen.

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

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

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

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

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

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

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

Ciberseguridad

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

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

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

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

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

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

El gusano Miasma ataca 73 repositorios de Microsoft GitHub en un importante ataque a la cadena de suministro – CYBERDEFENSA.MX

Los repositorios GitHub de Microsoft se han convertido en los últimos en ser víctimas de la actual Miasma Campaña de ataque autorreplicante a la cadena de suministro.

El incidente afectó a 73 repositorios de Microsoft en cuatro de sus organizaciones de GitHub, incluidas Azure, Azure-Samples, Microsoft y MicrosoftDocs, según Código abiertoMalware. El desarrollo cuenta con GitHub para deshabilitar el acceso a esos repositorios.

«El personal de GitHub ha deshabilitado el acceso a este repositorio debido a una violación de los términos de servicio de GitHub», se lee en el mensaje al intentar acceder al «Azure/azure-functions-host» repositorio. «Si usted es el propietario del repositorio, puede comunicarse con el Soporte de GitHub para obtener más información».

Según OpenSourceMalware, algunos de los repositorios afectados por el incidente se enumeran a continuación:

  • azure-search-openai-demo-purviewdatasecurity
  • Conectores-NET-LSP
  • Conectores-NET-SDK
  • tarea duradera
  • durabletask-dotnet
  • durabletask-go
  • tarea duradera-js
  • tarea duradera-mssql
  • funciones-contenedor-acción
  • funciones caseras
  • llm-ajuste fino
  • documentos-controladores-de-windows

Lo que es notable de la última campaña es el nuevo compromiso del paquete PyPI «durabletask», que fue infectado por TeamPCP el mes pasado para entregar un ladrón de información en sistemas Linux.

Ciberseguridad

«Un mes después, no solo desapareció Azure/durabletask, sino que también desaparecieron todos los repositorios hermanos en el ecosistema Durable Task, ubicados en una organización en Microsoft: las implementaciones .NET, Go, Java, JS, MSSQL, Netherite y protobuf, además del monitor Durable Functions», dijo el investigador de seguridad Paul McCarty (también conocido como 6mile).

«Cuando el repositorio en la raíz del compromiso del mes pasado es el centro de la eliminación de este mes, eso no es una coincidencia: es la misma reapertura de la herida. Quienquiera que tuviera esas credenciales en mayo probablemente nunca las perdió por completo».

Se considera que Miasma es una variante del gusano Mini Shai-Hulud que TeamPCP liberado públicamente a mediados de mayo de 2026. Desde entonces, ha seguido mutando y refinando sus tácticas, incluso cuando ha infectado más paquetes durante los últimos días, utilizando varias descripciones para los repositorios públicos recién creados que contienen los secretos robados –

  • Miasma: la plaga que se extiende
  • Miasma: la plaga que se extiende
  • Miasma: la plaga que se extiende
  • Hades – El fin de los condenados

Al momento de escribir, hay 13 repositorios con la descripción «Hades – El fin de los condenados» y 82 repositorios con los tres patrones de nombres restantes.

También se ha observado que Miasma se salta el registro npm por completo, y los actores de amenazas envían código malicioso directamente a «icflorescu/mantine-datatable» y a cuatro repositorios relacionados: «mantine-contextmenu», «next-server-actions-parallel», «mantine-datatable-v6» y «mantine-contextmenu-v6».

«La confirmación no agregó dependencias. Plantó un ejecutor de carga útil de 4,3 MB y lo conectó para que se ejecutara automáticamente a través de cinco herramientas de desarrollo: Claude Code, Gemini CLI, Cursor, VS Code y el script de prueba npm», SafeDep dicho. «El ataque detona cuando un desarrollador clona uno de los repositorios afectados y lo abre en un agente de codificación de IA. El dropper es el mismo cargador Bun preparado, aquí reutilizado para la persistencia del repositorio fuente de GitHub en lugar de envenenar el registro».

Ciberseguridad

Estos ataques a la cadena de suministro de software han expuesto las debilidades subyacentes en el modelo de confianza que forma la base de la entrega de software en ecosistemas de código abierto, lo que la convierte en una de las campañas más importantes y sostenidas observadas hasta la fecha. Lo que separa la actividad de otros incidentes es su capacidad de propagarse exponencialmente por el ecosistema comprometiendo a los usuarios intermedios y repitiendo el mismo ciclo.

«La genialidad del gusano y la razón por la que las defensas convencionales fallaron en gran medida es que opera completamente dentro de canales legítimos. No explota una vulnerabilidad en npm o GitHub», FalconFeeds.io dicho. «Explota el modelo de confianza en el que se construyen esas plataformas: la suposición de que si un paquete está firmado con una clave válida y publicado por un mantenedor autenticado, es seguro».

«Shai-Hulud compromete la clave y al mantenedor, luego procede a actuar exactamente como lo haría un editor legítimo. Desde la perspectiva del registro, cada evento de publicación malicioso es indistinguible de una actualización de rutina».

Un agente de IA descubre 21 días cero en FFmpeg; Los parches de Chrome registran 429 errores – CYBERDEFENSA.MX

Dos cosas aterrizaron con unos días de diferencia esta semana. Una startup de seguridad informó de 21 vulnerabilidades previamente desconocidas en FFmpeg, la biblioteca multimedia que se encuentra dentro de casi todo lo relacionado con el vídeo, todas ellas encontradas por un agente autónomo de IA.

La misma semana, Google envió Cromo 149 con parches para 429 errores de seguridad, la mayor cantidad jamás realizada en una sola versión.

La IA solo encontró los errores de FFmpeg. El récord de Chrome llegó después de que Google revisara su programa de recompensas para hacer frente a una avalancha de informes generados por IA. Los mecanismos difieren, pero la presión es la misma: la IA está poniendo más vulnerabilidades ante las personas que tienen que lidiar con ellas, y más rápido que antes.

Los hallazgos de FFmpeg provienen de profundidad primerocuyo agente de seguridad autónomo escaneó aproximadamente 1,5 millones de líneas de C del proyecto y produjo 21 días cero confirmados, cada uno con una entrada de prueba de concepto reproducible.

La empresa calcula el coste de la ejecución en unos 1.000 dólares. Varios de los errores habían estado latentes durante 15 a 20 años; un desbordamiento de pila en el código de la tabla de descripción de servicios data de 2003 y permaneció intacto durante 23 años.

Ciberseguridad

La mayoría son desbordamientos de pila o montón en analizadores y demuxers, que abarcan componentes desde el demuxer TS hasta el decodificador VP9. Depthfirst dice que algunos ya llevan identificadores CVE; su informe enumera nueve, CVE-2026-39210 a CVE-2026-39218, y señala que el resto están arreglados pero aún no numerados. También publicó un PoC.

En noticias separadas, Chrome 149 corrige 429 vulnerabilidades, un récord para una sola versión. Más de 100 son críticos o de alta gravedad, en su mayoría de uso después de la liberación y validación de entrada insuficiente.

Lo peor, CVE-2026-10881 (CVSS 9.6), es una lectura y escritura fuera de límites en el motor gráfico ANGLE que permite que una página diseñada escape del entorno limitado y ejecute código en el host. Google pagó 97.000 dólares por él.

Los errores de mayor gravedad fueron en su mayoría hallazgos internos: de aproximadamente 90 errores de alta gravedad, sólo 10 provinieron de investigadores externos y 19 de los 22 críticos fueron del propio Google. La conexión con la IA tiene más que ver con el volumen que con la autoría.

Google no ha vinculado el 429 a la IA; la señal grabada es la revisión de recompensas lo hizo en abril, motivado por una avalancha de envíos generados por IA y ahora solicita un reproductor conciso de los largos artículos que produce la IA.

El agente Big Sleep de Google informó una serie de errores de FFmpeg el año pasado, ahora visibles en la página del proyecto. pagina de seguridad etiquetado como BIGSLEEP, y el modelo Mythos de Anthropic sacó un defecto H.264 de 16 años de antigüedad y otros de FFmpeg por alrededor de $10,000, tres de los cuales se enviaron en FFmpeg 8.1, según su propia redacción.

Hace días, otra herramienta autónoma encontró un RCE autenticado en Redis que había estado presente desde la versión 7.2.0, desapercibido durante más de dos años. La investigación apunta en la misma dirección: en un estudio de febrero, un agente reprodujo PoC en funcionamiento durante más de la mitad de los casos. 100 errores reales del kernel de Linux de N díassuperando la pelusa.

Ciberseguridad

Para FFmpeg, extraiga la compilación ascendente fija o la actualización de seguridad de su distribución tan pronto como llegue, y priorice cualquier cosa que ingiera RTSP o AV1-over-RTP que no sea de confianza. FFmpeg se incluye ampliamente en canalizaciones de medios, ruedas de Python, imágenes de contenedores y dispositivos, por lo que no se detenga en los paquetes del sistema; esas copias incrustadas también necesitan parches.

Para Chrome, actualice a 149.0.7827.53 en Linux o 149.0.7827.53/54 en Windows y macOS, o confirme que se haya ejecutado la actualización automática.

La respuesta tiene que adaptarse al nuevo ritmo: ciclos de parches más cortos, actualización automática dondequiera que exista y aumentos de dependencia que conllevan correcciones CVE tratadas como trabajo de seguridad, no como mantenimiento de rutina.

Sin embargo, lo difícil es cambiar. Encontrar estos errores se ha vuelto barato; clasificar los informes, enviar las correcciones e instalarlas no lo ha hecho, y gran parte de ese trabajo aún recae en voluntarios y una delgada capa de evaluadores humanos que ahora se espera que sigan el ritmo de las máquinas.

CISA agrega la falla DoS de SolarWinds Serv-U explotada activamente al catálogo KEV – CYBERDEFENSA.MX

La Agencia de Seguridad de Infraestructura y Ciberseguridad de EE. UU. (CISA) ha agregado una falla de seguridad de alta gravedad que afecta el software del servidor de archivos multiprotocolo SolarWinds Serv-U a sus vulnerabilidades explotadas conocidas (KEV) catálogo, citando evidencia de explotación activa.

La vulnerabilidad, identificada como CVE-2026-28318 (puntuación CVSS: 7,5), es un error de denegación de servicio (DoS) que provoca que el servicio falle en determinadas condiciones. CISA lo describió como una vulnerabilidad de consumo de recursos incontrolado que resulta en una condición DoS.

«SolarWinds Serv-U es susceptible a solicitudes POST especialmente diseñadas que bloquean el servicio Serv-U sin autenticación mediante Content-Encoding: deflate», SolarWinds dicho en un aviso publicado a principios de esta semana.

Ciberseguridad

El problema se solucionó en SolarWinds Serv-U versión 15.5.4 HF1. Como mitigación, se recomienda limitar el acceso a direcciones conocidas y bloquear cualquier solicitud que contenga «codificación de contenido», ya que el servicio vulnerable no requiere esta funcionalidad.

Actualmente no hay detalles sobre cómo se aprovecha la vulnerabilidad en ataques del mundo real ni quién está detrás de ellos. Tampoco está claro cuántas instancias de Serv-U expuestas a Internet están comprometidas, si es que hay alguna.

CISA ha ordenado a las agencias del Poder Ejecutivo Civil Federal (FCEB) que aborden la falla antes del 19 de junio de 2026. En el pasado, los malos actores han explotado múltiples fallas en Serv-U, incluidos aquellos asociados con el banda de ransomware cl0p.

Las aplicaciones gratuitas están convirtiendo silenciosamente los televisores inteligentes en servidores proxy de inteligencia artificial

Un investigador ha realizado ingeniería inversa al SDK de iOS que Bright Data incorpora en aplicaciones de consumo y ha documentado cómo convierte dispositivos, incluidos televisores inteligentes siempre encendidos, en nodos de salida que transmiten el tráfico web para un negocio de datos que Bright Data comercializa fuertemente en la industria de la IA.

La empresa, sucesora de Luminati, opera lo que llama la red de proxy residencial más grande del mundo, anunciada en más de 400 millones de IP residenciales. Parte de ese suministro proviene de este SDK, que se incluye dentro de aplicaciones gratuitas detrás de una pantalla de suscripción y se describe como un grupo de más de 150 millones de direcciones IP obtenidas mediante consentimiento.

Los hallazgos, publicados el 5 de junio por Incluir seguridad y el investigador independiente Buchodi, importan porque el scraping proviene de la IP doméstica del usuario, no de la del cliente. El riesgo inmediato no es una cuenta pirateada o datos robados; es que una conexión doméstica y su ancho de banda se utilizan como infraestructura de raspado de otra persona.

Un televisor conectado es casi ideal para eso: generalmente enchufado, con una conexión rápida, efectivamente no medido y sin mirar.

Ciberseguridad

La evidencia técnica más profunda proviene del SDK de iOS; El alcance de la televisión inteligente se basa en el soporte de la plataforma de Bright Data, su lista de socios públicos y sus informes anteriores. La investigación encontró que el canal de pares que realiza trabajos de scraping no tiene autenticación real y, en iOS, su tráfico pasa por alto una VPN configurada.

Dentro del túnel de pares

Cuando se abre la aplicación, el SDK se pone en contacto con uno de los servidores de Bright Data, que entrega sus instrucciones sin comprobar realmente quién pregunta. A partir de ese momento, el servidor puede indicarle al dispositivo que vaya a buscar páginas de otros sitios web, utilizando la conexión a Internet del hogar del usuario para hacerlo.

El investigador descubrió que el canal que realiza esas tareas no tiene ninguno de los controles de seguridad habituales y lo describió como más débil que los controles integrados en la mayoría del malware.

En los iPhone, el investigador descubrió que este tráfico pasa por una VPN y que gran parte de lo que hace la aplicación no aparece en las herramientas que los equipos de seguridad normalmente usan para monitorear las aplicaciones. El dispositivo también puede seguir transmitiendo en segundo plano mientras alguien mira la pantalla o atiende una llamada, siempre que la batería no esté baja.

La brecha de consentimiento

La pantalla de suscripción no coincide con lo que realmente permite el SDK. En una aplicación de Roku, Petflix, la pantalla decía que usaría el dispositivo y su conexión «ocasionalmente».

La configuración que carga el SDK permite hasta 200 GB de tráfico al mes. En algunos países, incluidos Uzbekistán y Omán, los límites son mucho más altos y el dispositivo puede seguir funcionando casi hasta que se agote la batería. El SDK también puede unir el teléfono de una persona y las computadoras que ejecutan las aplicaciones de la misma empresa, tratándolos como un solo usuario.

Bright Data publica su lista de socios de aplicaciones en una página que cualquiera puede abrir e incluye creadores de aplicaciones de televisión inteligente como PlayWorks Digital, CloudTV y Longvision. El investigador tiene cuidado de señalar que estar en la lista solo muestra que una empresa trabajó con Bright Data en algún momento, no que su aplicación incluya el SDK en la actualidad. Habría que comprobar cada uno por separado.

Un modelo antiguo, impulsado por la demanda de IA

Nada de esto es nuevo en cuanto a forma, sólo en escala. Bright Data es el sucesor de Luminati, el servicio de proxy pago que surgió de Hola VPN. En 2015 Hola fue fue sorprendido vendiendo el ancho de banda de sus usuarios gratuitos como nodos de salida a través de Luminati, a 20 dólares el gigabyte. El mismo modelo funciona ahora en la caja siempre encendida del salón.

Lo que cambió es el comprador. Las defensas anti-bot de Cloudflare, DataDome y otros bloquean los raspadores provenientes de las IP de los centros de datos, por lo que los raspadores de IA se dirigen a través de conexiones residenciales.

Ciberseguridad

krebs reportado en octubre de 2025 que los servidores proxy de botnets como Aisuru están impulsando la recolección de datos de IA a gran escala, y Google desmanteló la red proxy criminal IPIDEA en enero. Esas operaciones secuestran los dispositivos de los consumidores; Bright Data dice que sus nodos de salida optan por participar a través de una pantalla de consentimiento. Ese consentimiento es la línea divisoria entre ambos, y si es significativo es la cuestión abierta.

Lowpass, distribuido por The Verge, apareció por primera vez el ángulo de la televisión inteligente en febrero, y este es el desmontaje técnico. Desde entonces, Google, Amazon y Roku han restringido los SDK de proxy en segundo plano, y Bright Data eliminó esas plataformas, aunque todavía incluye Tizen de Samsung y webOS de LG.

que hacer

El tráfico es fácil de detectar y bloquear. En una red doméstica, el paso más sencillo es bloquear las direcciones web que utiliza el SDK para conectarse, con una herramienta a nivel de enrutador como Pi-hole o NextDNS.

Los principales son proxyjs.brdtnet.com, proxyjs.luminatinet.com, proxyjs.bright-sdk.com, clientdk.bright-sdk.com y clientdk.brdtnet.com. Según la investigación, bloquearlos impide que el dispositivo actúe como un relé sin afectar el servicio pago de Bright Data, que se ejecuta en direcciones separadas.

Las empresas que administran los teléfonos del personal también pueden buscar aplicaciones que incluyan el SDK. Un problema: en una conexión móvil, el tráfico evita el Wi-Fi de la oficina, por lo que un bloqueo de red por sí solo no siempre lo captará. Bright Data también podría cambiar la forma en que se conecta el SDK en el futuro, lo que significaría que es necesario actualizar cualquier lista de bloqueo.

Fallo CVE-2026-20245 de Cisco Catalyst SD-WAN Manager explotado activamente: no hay parche disponible

Ravie Lakshmanan6 de junio de 2026Vulnerabilidad/Seguridad de Red

Cisco advirtió que una falla de seguridad de alta gravedad que afecta a Catalyst SD-WAN Manager ha sido objeto de explotación activa.

La vulnerabilidad, rastreada como CVE-2026-20245tiene una puntuación CVSS de 7,8 sobre un máximo de 10,0. Afecta a los siguientes tipos de implementación:

  • Implementación local
  • Cisco SD-WAN Cloud-Pro
  • Nube Cisco SD-WAN (administrada por Cisco)
  • Cisco SD-WAN para gobierno (FedRAMP)

«Una vulnerabilidad en la CLI de Cisco Catalyst SD-WAN Manager, anteriormente SD-WAN vManage, podría permitir a un atacante local autenticado ejecutar comandos arbitrarios como root suministrando un archivo manipulado al sistema afectado», Cisco dicho en un aviso.

La empresa de seguridad de red dijo que la vulnerabilidad es el resultado de una validación insuficiente de la información proporcionada por el usuario, que un atacante podría explotar cargando un archivo manipulado en el sistema afectado. Esto, a su vez, podría permitir al atacante realizar ataques de inyección de comandos y elevar sus privilegios como usuario root.

«Para explotar esta vulnerabilidad, el atacante debe tener privilegios de administrador de red en el sistema afectado», añadió Cisco. «Esto requeriría credenciales válidas o la explotación de CVE-2026-20182 o CVE-2026-20127. Cisco no tiene conocimiento de una explotación exitosa mediante otros métodos».

Ciberseguridad

CVE-2026-20182 (puntaje CVSS: 10.0) fue revelado el mes pasado por Rapid7, describiéndolo como una omisión de autenticación que podría permitir a atacantes remotos no autenticados obtener privilegios administrativos en sistemas susceptibles. También se considera similar a CVE-2026-20127, otro caso de omisión de autenticación que afecta al mismo componente.

Ambas vulnerabilidades han sido explotadas en estado salvaje como de día cero, con un grupo de actividad de amenazas denominado UAT-8616 vinculado al abuso de CVE-2026-20127 ya en 2023.

En su aviso publicado el jueves, Cisco dijo que observó casos limitados en los que la explotación de CVE-2026-20245 resultó en un cambio de configuración llevado a los dispositivos de borde. Le dio crédito a los investigadores de Google Mandiant Chester Sng, Pete Boonyakarn y Logeswaran Nadarajan por descubrir e informar sobre la nueva vulnerabilidad. Se desconoce quién está detrás de los últimos esfuerzos de explotación.

Actualmente no hay parches ni mitigaciones disponibles para CVE-2026-20245. Se recomienda a los clientes que actualicen su software SD-WAN para asegurarse de haber aplicado las correcciones publicadas para CVE-2026-20182 el 14 de mayo de 2026.

Cisco también advirtió que los sistemas expuestos a Internet corren un mayor riesgo de verse comprometidos. Para buscar indicadores de compromiso (IoC), se recomienda a los usuarios que revisen el archivo «/var/log/scripts.log» para buscar entradas como las siguientes:

Apr 15 09:44:57 vmanage vScript: Tenant list upload per vsmart serial number: /usr/bin/vconfd_script_upload_tenant_list.sh -cli path /home/admin/malicious.csv vpn 0

Jun  5 13:06:39 Manager vScript: vSmart upload serial numbers: /usr/bin/vconfd_script_upload_vsmart_serial_numbers.sh -cli path /home/admin/vsmart_serial_numbers_safe.csv

Jun  5 13:08:47 Validator vScript: ZTP upload chassis numbers: /usr/bin/vconfd_script_upload_chassis_number_file.sh -cli path /home/admin/chassis_numbers_safe.csv

CVE-2026-20245 es la séptima falla que afecta a Cisco SD-WAN y que se marca como explotada activa solo este año después de CVE-2026-20182, CVE-2026-20127, CVE-2026-20122, CVE-2026-20128, CVE-2026-20133 y CVE-2022-20775.

La divulgación se produce días después de que Cisco abordara otra falla de seguridad de alta gravedad en Unified Communications Manager (CVE-2026-20230, puntuación CVSS: 8,6), para la cual dijo que un código de explotación de prueba de concepto es público. No hay evidencia de que la vulnerabilidad haya sido objeto de explotación activa.

IronWorm y la nueva variante de Miasma Worm atacan a npm en ataques a la cadena de suministro – CYBERDEFENSA.MX

Múltiples ataques a la cadena de suministro de software han afectado al ecosistema npm, y los actores de amenazas utilizan versiones maliciosas y envenenadas de más de 50 paquetes legítimos para distribuir un ladrón de información basado en Rust y un gusano que se propaga automáticamente, respectivamente.

De acuerdo a JFrogel ladrón de información «elimina todos los secretos que puede encontrar en la máquina de un desarrollador, se esconde detrás de un rootkit del núcleo eBPF y responde a su operador a través de Tor».

El ladrón también utiliza las credenciales robadas como mecanismo de propagación, generando similitudes con el infame gusano Shai-Hulud. El nuevo malware tiene un nombre en clave gusano de hierro por la empresa de seguridad de la cadena de suministro de software. Al publicarse en el registro npm en forma de paquetes troyanizados, este enfoque resulta en un ataque autorreplicante.

La actividad maliciosa se remonta a una cuenta npm comprometida llamada «asteroide«, que se ha descubierto que publica versiones de paquetes que contienen el binario Rust ELF que se ejecuta a través de un gancho de preinstalación.

El malware se dirige a 86 variables de entorno, varios archivos que pueden contener credenciales asociadas con OpenAI Codex, Anthropic, Claude, Google Gemini, Cursor, Amazon Web Services (AWS), Docker, Kubernetes y npm, configuraciones de bóveda y archivos de billetera de criptomonedas Exodus.

Una peculiaridad inusual que vale la pena mencionar aquí es que el ladrón incluye una lógica para que el componente de robo de datos de la billetera omita la billetera del propio actor de la amenaza. Al momento de escribir, el billetera de criptomonedas está vacío y no se han registrado transacciones.

Ciberseguridad

JFrog describió a IronWorm como «un arma de cadena de suministro creada para encontrar secretos, modificar proyectos e inyectar código malicioso para autopropagarse en GitHub». Las confirmaciones maliciosas, que abarcan nueve organizaciones de GitHub, se introdujeron bajo el nombre del autor «claude» («claude@users.noreply.github.com») en un intento de imitar el chatbot de inteligencia artificial (IA) de Anthropic.

«El paquete malicioso npm fue publicado por asteroiddao; asteroiddao corresponde a la organización asteroid-dao GitHub; y ocrybit es miembro de esa organización, así como de organizaciones Arweave relacionadas», explicó la compañía.

«El malware robó las credenciales de ocrybit y las usó para enviar confirmaciones a través de repositorios a los que podía acceder. Esas confirmaciones colocaron malware en otros paquetes, que luego podrían publicarse e infectar al siguiente desarrollador. Y luego desapareció».

Es más, la carga útil maliciosa está equipada para intercambiar los flujos de trabajo de GitHub Actions existentes por uno que sea capaz de recolectar los secretos, escribirlos en un archivo de apariencia inofensiva y cargarlo como un artefacto de compilación, eliminando así la necesidad de un servidor externo de comando y control (C2).

Las capacidades del malware no terminan ahí. En entornos de CI, abusa del flujo de publicación confiable de npm para obtener tokens de corta duración para enviar versiones envenenadas que contienen el malware al registro.

También incorpora una carga útil eBPF que funciona como un rootkit a nivel de kernel para ocultar procesos y frustrar análisis. Sin embargo, en los sistemas donde el bloqueo del kernel está habilitado, los trucos para ocultar procesos fallan y los supuestos procesos y sockets vuelven a ser visibles.

El gusano miasma emerge nuevamente

La revelación surge como Laboratorios Endor y PasoSeguridad arrojar luz sobre una distinta campaña de ataque a la cadena de suministro que ha comprometido 57 paquetes npm en más de 286 versiones maliciosas para servir una nueva variante del gusano Miasma, que previamente infectó 32 paquetes en más de 90 versiones bajo el espacio de nombres npm @redhat-cloud-services en 72 segundos a principios de esta semana.

Algunos de los paquetes afectados se enumeran a continuación:

  • ai-sdk-ollama
  • autotel
  • esperando
  • analizador de efectos
  • complemento-eslint-esperando
  • historias-ejecutables-ciprés
  • http-uploader-dev
  • montado
  • nodo-env-resolver
  • nodo-env-resolver-aws

Los datos robados a través del malware se filtran a una cuenta de GitHub ahora inaccesible «liuende501«, que actuó como un punto de exfiltración. Se almacenaron hasta 236 repositorios en la cuenta. Actualmente no se sabe si GitHub eliminó la cuenta o si el propio actor de la amenaza la eliminó.

«Esta ola utiliza una técnica que llamamos ‘Phantom Gyp’: en lugar de los scripts de ciclo de vida previos o posteriores a la instalación que las herramientas de seguridad normalmente monitorean, el atacante abusa de un archivo vinculante.gyp de 157 bytes para activar la ejecución del código durante la instalación de npm, evitando por completo la mayoría de los controles de seguridad de los scripts de instalación», dijo el investigador de StepSecurity, Sai Likhith.

Como en el caso de Miasmala cadena de ataque está diseñada para descargar e instalar el tiempo de ejecución de Bun JavaScript, usándolo para cargar un recolector de credenciales integral diseñado para extraer secretos de AWS, Google Cloud, Microsoft Azure, HashiCorp Vault, Docker, Kubernetes, GitHub Actions, npm, RubyGems, PyPI, SSH, administradores de contraseñas y asistentes de IA.

«La capacidad más novedosa y preocupante de esta variante es su objetivo en configuraciones de asistente de codificación de IA», dijo la compañía. «El malware inyecta archivos persistentes de puerta trasera en repositorios de proyectos que se ejecutan cada vez que un desarrollador abre el proyecto en su IDE asistido por IA».

Se recomienda a los desarrolladores que hayan instalado una versión afectada que roten las credenciales, desactiven los scripts de instalación y las reconstrucciones nativas de forma predeterminada y se aseguren de que los paquetes estén fijados con hashes de integridad.

Ciberseguridad

En una actualización compartida esta semana, Red Hat reveló que la causa principal detrás del incidente de la cadena de suministro de Miasma fue probablemente una cuenta de GitHub comprometida que se utilizó para enviar confirmaciones no autorizadas a los repositorios de la organización RedHatInsights GitHub.

«La carga útil operaba en Linux, macOS y Windows descargando dinámicamente el tiempo de ejecución de Bun correcto para cada plataforma, aunque los ejecutores de CI/CD de Linux parecían ser el objetivo principal», explicó Microsoft. dicho de la campaña.

«En los sistemas de desarrollo, el malware robó claves Secure Shell (SSH), credenciales de interfaz de línea de comandos (CLI), datos del navegador y de la billetera, mientras que en entornos CI/CD extrajo la memoria del ejecutor de GitHub Actions en busca de secretos, escaló privilegios usando sudo sin contraseña y volvió a publicar paquetes envenenados con niveles de cadena de suministro falsificados para artefactos de software (SLSA) para continuar con la propagación descendente».

Se considera que la carga útil Miasma es un derivado del gusano Shai-Hulud utilizado por EquipoPCP en campañas recientes, introduciendo cambios en gran medida «cosméticos» manteniendo similar la funcionalidad subyacente. A pesar de la superposición en el oficio, la atribución del último conjunto de ataques sigue sin estar clara, dado que TeamPCP ha publicado públicamente el código Shai-Hulud.

Desde entonces, OX Security ha descubierto etapas adicionales en la cadena de ataque de Miasma, incluidas búsquedas de confirmaciones de GitHub que contienen la cadena «firedalazer» (que reemplaza el punto muerto «FIRESCALE» previamente marcado) para recuperar otra carga útil, un archivo JavaScript («index.js») que contiene una versión alternativa del gusano Shai-Hulud, transformando efectivamente la infección en un bucle perpetuo.

En este caso, los datos robados se filtran a repositorios públicos de GitHub, cada uno con la descripción «Miasma: The Spreading Blight» o «Miasma – The Spreading Blight». Es importante señalar aquí que la versión anterior dice «Miasma: The Spreading Blight», que no tiene un espacio entre Miasma y el símbolo «:». Hay actualmente 82 repositorios de este tipo creado en las cuentas de usuario «0tabek16» y «windy629».

«El actor de amenazas puede cambiar dinámicamente las confirmaciones de ‘firedalazer’ en GitHub, haciendo que las nuevas versiones del malware sean más adaptables y más sofisticadas», afirman los investigadores de seguridad Moshe Siman Tov Bustan y Nir Zadok. dicho.

«Esto convierte a GitHub en algo más peligroso que un punto muerto. Es un C2 adaptable, uno que se apoya en una plataforma confiable y ampliamente incluida en la lista blanca, haciendo que la detección a nivel de red sea casi inútil. La mayoría de las herramientas de seguridad no están configuradas para tratar el tráfico de GitHub como sospechoso. El actor de la amenaza lo sabe».

El software espía de Android Asin se dirige a usuarios árabes a través de noticias falsas, PDF y aplicaciones de mapas de guerra

Los usuarios de habla árabe se han convertido en el objetivo de un nuevo software espía de Android con nombre en código Asínde acuerdo a recomendaciones de ESET.

La empresa eslovaca de ciberseguridad dijo que detectó por primera vez el malware propagado a través de múltiples campañas a principios de 2025, y que cada ola de ataque hacía uso de distintos sitios web que imitaban utilidades, actualizaciones relacionadas con la guerra y una fuente de noticias del gobierno:

  • gobernar[.]net, que se hace pasar por una fuente de noticias del gobierno (registrado el 27 de mayo de 2025)
  • lector de pdf[.]ayuda, que se hace pasar por un editor de PDF seguro (registrado el 29 de mayo de 2025)
  • mapa-de-guerra-en-vivo[.]com, que afirma ofrecer actualizaciones sobre incidentes militares (registrado el 20 de enero de 2025)

Dos de estos sitios web: govlens[.]mapa de guerra neto y en vivo[.]com – también se comercializaron a través de cuentas dedicadas en plataformas de redes sociales como Facebook y Telegram –

  • www.facebook[.]es/GovLens
  • t[.]yo/liveuamap_ar

«Cada uno de estos sitios web distribuye una aplicación maliciosa que combina funcionalidad legítima con capacidades de software espía sigilosas», afirmó ESET.

Ciberseguridad

La compañía de ciberseguridad señaló que el nombre del canal Telegram probablemente esté inspirado en Live Universal Awareness Map (Liveuamap), una plataforma legítima y conocida dedicada a mapear conflictos en curso, cuestiones de derechos humanos, desastres naturales y eventos geopolíticos en todo el mundo.

Desde entonces se han identificado varios artefactos asociados con Asin, incluido uno subido a VirusTotal desde Türkiye en octubre de 2025, un APK descargado del dominio «c-pdf[.]net» en diciembre de 2025 por un usuario en un dispositivo Xiaomi Redmi Note 13 Pro con Android 15, y una tercera muestra disfrazada de «Mapa de Defensa de Siria» detectada en un dispositivo Xiaomi Redmi Note 13 Pro+ 5G con Android 15 alrededor de mediados de enero de 2026.

En el último caso, se dice que el APK se descargó de un sitio web llamado «syriadefensemap[.]com.» Vale la pena señalar que el usuario debe instalar manualmente la aplicación y otorgarle los permisos necesarios para que el software espía alcance sus objetivos.

El grupo de actividad, según ESET, permanece sin atribuir. Tampoco se sabe cuáles son los objetivos principales de estas campañas. Sin embargo, basándose en los señuelos utilizados, se sospecha que el objetivo pueden haber sido periodistas e investigadores de OSINT en regiones de habla árabe.

«Tres de las cinco aplicaciones fraudulentas que descubrimos (GovLens, WarMap y Syria Defence Map) parecen estar destinadas principalmente a personas interesadas en la investigación de código abierto», dijo la compañía. «Por lo tanto, parece posible que este conjunto de actividades haya estado destinado, al menos parcialmente, a periodistas de habla árabe o profesionales de OSINT».

El incidente de Nightmare Eclipse muestra que es posible que las peleas entre investigadores y proveedores nunca desaparezcan por completo

Microsoft reabrió algunas heridas y ha reavivado el debate durante las últimas dos semanas sobre la divulgación de vulnerabilidades y la dinámica a veces conflictiva que crea entre investigadores y proveedores de seguridad.

La última controversia se produjo cuando Microsoft amenazó con emprender acciones legales penales contra un investigador de seguridad que reveló públicamente una serie de vulnerabilidades de día cero con exploits de prueba de concepto. microsoft insistió en que no recibió detalles sobre las vulnerabilidades antes del lanzamiento, y agregó que los defectos no fueron divulgados de manera responsable y pusieron a sus clientes en riesgos innecesarios.

La disputa pública entre Microsoft y el investigador conocido como “Eclipse de pesadilla«, que no pudo ser identificado ni contactado para hacer comentarios, provocó consternación entre algunos profesionales de la seguridad. La contundente respuesta de Microsoft y la reacción resultante revivieron un punto de fricción entre proveedores e investigadores que encuentran e informan fallas en el software que venden.

«La pelea se argumenta como una divulgación coordinada, pero la queja subyacente es personal y específica de una manera que la divulgación no debería serlo, especialmente con un proveedor que ha estado en esto durante tanto tiempo», dijo a CyberScoop Katie Moussouris, fundadora y directora ejecutiva de Luta Security.

«Microsoft pareció emocionarse y no debería haber dicho nada públicamente, pero de alguna manera se sintió justificado al llamar a un investigador e involucrar a las autoridades al mismo tiempo», dijo. «Eso los devuelve a las primeras etapas del duelo por la revelación de la vulnerabilidad: la negación y la ira».

El antiguo empleado de Microsoft que trabajó en contacto con la comunidad de seguridad, creó el primer programa de recompensas de la empresa y ha otorgado charlas en conferencias sobre el tema Ya en 2013, dijo que la compañía redobló su falta de responsabilidad en toda la saga.

Microsoft se negó a responder preguntas a raíz de las consecuencias.

Nightmare Eclipse insinuó una falla y una batalla inminente con el proveedor en una serie de publicaciones de blog previas a la misiva de Microsoft sobre las vulnerabilidades. rojosol, Desdefender, Martillo azul, llave amarillaGreenPlasma y MiniPlasma.

Los atacantes explotaron tres de las seis vulnerabilidades que Nightmare Eclipse lanzó antes de que Microsoft las parcheara.

El investigador afirmó que Microsoft se negó a comunicarse, no les pagó ni les dio crédito por descubrir e informar algunas de las vulnerabilidades, eliminó la cuenta del Centro de Respuesta de Seguridad de Microsoft que usaron para revelar las vulnerabilidades y marcó su cuenta de GitHub para su eliminación.

«Están demostrando a todos que están intensificando activamente este conflicto», escribieron, antes de amenazar a Microsoft con un comunicado a mediados de julio que «asegurará que sus huesos queden destrozados ese día».

La divulgación de vulnerabilidades es una vía de doble sentido

Las características de los procesos adecuados de divulgación de vulnerabilidades tienen matices y, a menudo, se enmarcan en los ojos del espectador.

Cualquier baile exitoso entre cazadores de insectos y vendedores se reduce a encontrarse a mitad de camino, dijo Andrew Morris, fundador y arquitecto jefe de GreyNoise.

Si bien los proveedores deben corregir los defectos del software y priorizar la seguridad, Morris señaló que la divulgación irresponsable de vulnerabilidades perjudica tanto a los respondedores de incidentes como a las víctimas potenciales.

«Personalmente, siento que este investigador está siendo extremadamente mezquino. Parece que tienen un interés especial», dijo.

«No puedes darle algo a alguien y decir que es por la bondad de tu corazón, y luego enojarte cuando no te pagan por ello».

Pero Morris también dejó claro que los proveedores tienen la responsabilidad de generar confianza entre los investigadores.

«Si realmente le importa ser el primero en enterarse de los errores en su software, no enterarse una vez que se ha producido un daño o una vez que alguien ha sido descubierto, entonces desea cultivar esa confianza con la comunidad de seguridad», dijo Morris.

Microsoft dijo que reconoce que la relación entre los investigadores de seguridad y los proveedores es crítica y, en ocasiones, frágil.

«Valoramos profundamente a la comunidad de seguridad y continuaremos tomando en serio sus comentarios», dijo la compañía en su publicación. en X.

Sin embargo, la compañía se mantiene firme en oponerse a las circunstancias de las revelaciones de Nightmare Eclipse, describiendo sus acciones como ilegales, injustificables e irresponsables.

«Cuando un individuo infringe la ley y participa en actividades maliciosas que causan un daño real a nuestros clientes, trabajaremos con las autoridades según corresponda», dijo Microsoft sin nombrar al investigador por su apodo. «Seguimos creyendo firmemente en la divulgación coordinada de vulnerabilidades como base para proteger a los clientes y mejorar nuestros productos. Sabemos que, dada la naturaleza de este trabajo, en ocasiones habrá malentendidos. Seguimos comprometidos a participar de buena fe y a brindar una experiencia respetuosa y profesional para todos los investigadores, independientemente de interacciones pasadas».

El costo del retroceso

Los investigadores de seguridad buscan defectos por varias razones: pagos de recompensas, reconocimiento, credibilidad de la industria o simplemente la emoción de la búsqueda que conlleva encontrar vulnerabilidades y solucionarlas.

En el mejor de los casos, este proceso ocurre entre bastidores, con parches publicados y advertidos a los clientes antes de que ocurra la explotación.

Este enfoque colaborativo ha arraigado y mejorado considerablemente, pero todavía hay casos en los que los investigadores se sienten despreciados.

“El público no tiene idea de lo que sucedió detrás de escena para juzgar por qué un investigador que previamente coordinaba finalmente se cansó y decidió abandonar un día cero. [vulnerability]», dijo Moussouris. Como tal, está menos inclinada a criticar las acciones de Nightmare Eclipse, y agrega que «parecen ser alguien que necesita ayuda».

Sin embargo, la confianza entre los investigadores y los proveedores de vulnerabilidades se rompe a menudo. A principios de esta semana, el investigador de seguridad Ammar Askar afirmó que su última interacción con el equipo de seguridad de Microsoft fue tan pobre que decidió revelar públicamente cualquier error que encuentre en VS Code en el futuro. Cumplió esa amenaza al dejando caer una vulnerabilidad y explotar el código para un defecto que permite a los atacantes robar tokens de GitHub.

Si bien acciones como esta pueden sabotear la confianza y abrir una brecha entre los proveedores y los investigadores de vulnerabilidades, el recurso es en gran medida limitado. Moussouris dijo que la mayoría de las veces los límites legales y éticos son claros para los involucrados. Los investigadores pueden informar errores, retenerlos, venderlos o publicarlos. «La única línea roja es el crimen: usar un defecto para extorsionar o atacar a la gente», dijo Moussouris.

«Amenazar con publicar en una fecha determinada es una amenaza con divulgar, y la divulgación es legal. El tono puede resultar feo. [Nightmare Eclipse] todavía no violó ninguna regla ni violó ningún deber”.

El momento no podría ser peor

Ambas partes son en parte responsables de lo sucedido, pero Microsoft empeoró las cosas, afirmó Morris. Amenazar con acciones legales y adoptar un enfoque agresivo nunca ha funcionado. Construir una buena relación entre investigadores y proveedores requiere comunicación abierta y confianza.

«Pensé que ya habíamos superado esto. Resulta que no», dijo.

El incidente de Nightmare Eclipse llega en un momento tenso en este espacio. Los proveedores y sus clientes se enfrentan a una avalancha de más vulnerabilidades, y el aumento de modelos de inteligencia artificial que las descubren está exacerbando este desafío, dejando a los expertos en seguridad alarmados por lo que se avecina.

Las perspectivas sobre dónde se descubrirán y explotarán las vulnerabilidades a continuación, y con qué impacto, son desconocidas y tremendamente inquietantes.

Estas señales implican que el sistema clásico basado en CVE con procesos divulgados responsablemente probablemente esté roto, dijo Morris. «Hay tantos CVE. Es como si esto ¿ya funciona?».

Por ahora, y a pesar de todos sus defectos, los programas coordinados de divulgación de vulnerabilidades se consideran ampliamente como el enfoque más sensato y escalable para este dilema.

«La divulgación coordinada es lo que sucede cuando un proveedor tiene suerte. Alguien a quien no contrató le entrega un error real en lugar de usarlo o venderlo. Eso pone toda la carga de mantener viva la coordinación en el proveedor», dijo Moussouris. «La aplicación de parches silenciosos sin CVE y la llamada a los investigadores que no siguen su cronograma de divulgación desperdician la suerte del proveedor».

Hizo hincapié en lo que está en juego: «Espero que Microsoft y todos los proveedores aprendan que la divulgación coordinada de vulnerabilidades es un regalo y una gracia de la comunidad de investigadores de seguridad para ellos, y la divulgación pública sigue siendo mejor que la no divulgación o el delito».

Las alternativas a una relación en deterioro podrían causar estragos y dejar a todos los proveedores y clientes más susceptibles a los ataques.

«Si los proveedores desaprenden cómo recibir propiedad intelectual y mano de obra gratuita de la comunidad de seguridad en forma de informes de vulnerabilidad con gratitud, nos dirigimos a un mundo donde nadie se molesta en avisar a los proveedores, o se mueven hacia un modelo de divulgación cronometrada que no da ninguna gracia», dijo Moussouris.

Concluyó con un mensaje directo: «Los proveedores de productos escribieron el código vulnerable, son dueños del riesgo y deben hacer todo lo que esté a su alcance para con sus usuarios para reducir ese riesgo». Eso incluye “guardar sus quejas para sí mismos y aprender de la introspección sobre la divulgación coordinada de vulnerabilidades que salieron mal”.

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.