El malware Umbrij abusa de OAuth para acceder a Gmail a través de la API de Google.

El grupo de ciberdelincuentes conocido como ToddyCat ha sido atribuido a un nuevo malware llamado Umbrij, diseñado para obtener acceso subrepticio al GMail de las víctimas a través de la API de Google.

"En esta campaña, los atacantes centraron su atención en las comunicaciones de correo electrónico corporativas alojadas en Gmail, con el objetivo de comprometer el acceso a través de las API", afirmó Kaspersky en un informe detallado publicado esta semana. "Dado que la API de Google se basa en el protocolo OAuth 2.0 para la autorización, las aplicaciones pueden usar un token OAuth para acceder a los recursos de correo electrónico solicitados".

Se cree que el atacante desarrolló Umbrij para obtener este token y usarlo para conectarse a la consola de administración del navegador en modo sin interfaz gráfica (headless mode) a través de un puerto de depuración remota.

Posteriormente, se emitieron varias solicitudes para obtener un código de autorización OAuth, que luego se intercambió por un token de acceso para acceder a los recursos objetivo a través de la API. Esta técnica ha sido denominada "Shadow Token via Remote Debug" (STRD) por el proveedor ruso de ciberseguridad.

Lo más destacable de este ataque es que funciona en navegadores basados ​​en Chromium y aprovecha una sesión activa de Gmail. En otras palabras, la idea es ejecutar el navegador en modo sin interfaz gráfica, conectarse a través del puerto de depuración remota para tomar el control y utilizar una sesión de Gmail ya iniciada para acceder a los recursos de la cuenta de Google.

Se han descubierto tres versiones diferentes de Umbrij, incluyendo versiones con funciones auxiliares para la depuración y para buscar y seleccionar cuentas de usuario dentro del navegador.

ToddyCat es el nombre asignado a una amenaza persistente avanzada (APT) que ha atacado a diversas organizaciones en Europa y Asia desde al menos 2020. En noviembre de 2025, Kaspersky detalló el uso que hizo el grupo de una herramienta personalizada llamada TCSectorCopy para obtener datos de correo electrónico de Microsoft Outlook pertenecientes a las empresas objetivo.

La empresa de ciberseguridad declaró haber descubierto Umbrij durante una operación de búsqueda de amenazas, en la que se utilizó una tarea programada que suplantaba la identidad de su software ("KasperskyEndpointSecurityEDRAvp") para ejecutar un archivo firmado digitalmente. Este archivo, a su vez, ejecutó Umbrij mediante la carga lateral de DLL.

Para lograrlo, se aprovecharon tres binarios legítimos vulnerables a la carga lateral de DLL:

• BDSubWiz.exe, un componente del Asistente de Envío de Bitdefender ConnectAgent;
• VSTestVideoRecorder.exe, un componente de la herramienta de grabación de vídeo utilizada para realizar pruebas con Microsoft Visual Studio;
• GoogleDesktop.exe, una aplicación de búsqueda de escritorio de Google ya descontinuada que se utilizaba para indexar archivos y realizar búsquedas rápidas en un equipo Windows local.

Independientemente del ejecutable utilizado, el resultado final es el mismo: la ejecución de la DLL maliciosa de Umbrij, escrita en .NET y ofuscada con ConfuserEx, un ofuscador de código abierto. La herramienta también puede ejecutarse mediante parámetros de línea de comandos que especifican los navegadores a los que dirigirse (Google Chrome o Microsoft Edge), le indican que guarde una captura de pantalla del perfil de usuario como archivo PDF y proporcionan el nombre de usuario del sistema con el que se ejecutará la herramienta.

Umbrij, al igual que la mayoría de las herramientas del conjunto de herramientas de ToddyCat, registra sus acciones en detalle y las guarda en un archivo. También guarda el código de autorización recuperado en este archivo de registro, que el operador posteriormente extrae del host comprometido."

"El código de autorización obtenido se intercambia por un token de acceso OAuth. Los ciberdelincuentes utilizan ese token para conectarse a la cuenta de Gmail a través de la API, comprometiendo así las comunicaciones de correo electrónico corporativas."

Para contrarrestar la amenaza, se recomienda revisar los códigos de autorización otorgados a las aplicaciones accediendo a "myaccount.google[.]com/connections" y buscando aplicaciones llamadas "Google Workspace Migration for Microsoft Outlook" o "Google Workspace Sync for Microsoft Outlook". Si alguna de estas aplicaciones está presente y no se utiliza en la organización, es fundamental revocar su acceso para invalidar los tokens OAuth.

"El grupo APT ToddyCat continúa buscando formas de comprometer las comunicaciones de correo electrónico corporativas", afirmó Andrey Gunkin, analista sénior de malware en Kaspersky. Su nueva herramienta, Umbrij, automatiza los intentos de los atacantes por acceder a las cuentas de correo electrónico de las organizaciones. Esta automatización no solo contribuye a aumentar la escala y la frecuencia de sus ataques, sino que también demuestra la gran motivación y las avanzadas habilidades técnicas de ToddyCat.

Fuente: THN

Seguir leyendo...

Ataque de fuerza bruta masivo contra CLI de Azure

Investigadores de ciberseguridad de Huntress han alertado sobre un ataque masivo, continuo y automatizado de fuerza bruta contra contraseñas dirigido a la interfaz de línea de comandos (CLI) de Azure de Microsoft, que ha comprometido decenas de cuentas.

Según Huntress, la actividad se 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 atacante realizó más de 81 millones de intentos de inicio de sesión y logró comprometer al menos 78 cuentas de Microsoft en 64 organizaciones. "La estrategia de estos ataques parece basarse exclusivamente en la frecuencia de las contraseñas en las listas de combinaciones de contraseñas comprometidas, sin estar específica para ningún tipo de empresa o sector".

Lo que hace que este ataque de fuerza bruta sea relevante no es solo su magnitud, sino también el hecho de que muchas de las organizaciones afectadas tenían habilitadas las políticas de acceso condicional. En concreto, se ha descubierto que la campaña aprovecha un flujo de OAuth obsoleto llamado Credenciales de Contraseña del Propietario del Recurso (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. Se dejó de usar en OAuth 2.1.

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

"En la mayoría de los casos, existen alternativas más seguras que se recomiendan. Este flujo requiere un alto grado de confianza en la aplicación y conlleva riesgos que no están presentes en otros flujos. Solo debe usarse cuando no sea viable usar flujos más seguros", afirma el gigante tecnológico.

Se dice que los ataques de fuerza bruta contra credenciales y tokens resultaron en 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 se vieron comprometidas 12 cuentas de usuario (también conocidas como identidades). El ritmo constante cambió el 22 de junio, cuando 30 identidades de 23 empresas se vieron afectadas.

En total, 78 cuentas de usuario se vieron comprometidas en 64 organizaciones como parte de la campaña. La gran mayoría de los ataques de fuerza bruta contra contraseñas provino de LSHIY LLC. Algunas de las direcciones IP corresponden a Estados Unidos, mientras que otras corresponden a China.

"Estos ataques forman parte de una oleada generalizada de ataques de fuerza bruta contra credenciales en varios sistemas autónomos (ASN)", declaró Huntress, añadiendo que ha observado un aumento de más de 155 veces en el volumen de ataques de este tipo entre sus clientes. "Los ataques surgieron especialmente entre finales de mayo y principios de junio, con un promedio actual de aproximadamente 1964 ataques fallidos al mes por cada cliente protegido por Huntress".

La actividad parece centrarse específicamente en el uso de combinaciones antiguas de nombre de usuario y contraseña que ya habían sido vulneradas, pero que nunca se habían actualizado. El uso del vector ROPC permitió a los atacantes dirigirse a empresas que habían implementado la autenticación multifactor (MFA), pero que no la tenían configurada para gestionar los inicios de sesión ROPC de la CLI de Azure.

"ROPC se considera problemático por varias razones, pero una de ellas es que no ofrece compatibilidad con flujos de autenticación modernos como MFA o SSO. Esto significa que, como vimos en esta campaña, ROPC envía la contraseña directamente al punto final /token sin solicitar la autenticación multifactor de forma interactiva", explica Huntress.

Esto incluía escenarios en los que no se activaba la autenticación multifactor (MFA):

• Aplicar la MFA solo para aplicaciones específicas, en lugar de para "Todas las aplicaciones en la nube", lo que impedía cubrir los inicios de sesión de la CLI de Azure utilizados por los ciberdelincuentes.
• Aplicar la MFA solo para grupos de usuarios específicos, como los administradores.
• Aplicar la MFA solo cuando las solicitudes se originaban en ubicaciones no confiables.

"Cabe destacar que ocho empresas afectadas por la campaña no contaban con ninguna política de autenticación multifactor (MFA): Si bien los ciberdelincuentes lograron acceder a pesar de tener MFA configurada, la conclusión no debe ser que MFA no funcione en absoluto; en cambio, las organizaciones deben asegurarse de que sus políticas de MFA estén configuradas correctamente para abordar el flujo de autorización utilizado en estos incidentes".

Para contrarrestar este tipo de ataque, se recomienda a las organizaciones que exijan MFA para todos los usuarios, todas las aplicaciones en la nube y todos los tipos de aplicaciones cliente al habilitar CAP, que restrinjan el acceso a la aplicación Azure CLI para usuarios que no sean administradores y que prioricen la respuesta según la validez de las credenciales.

Este ataque revela vulnerabilidades en los CAP que no se han configurado adecuadamente. Todavía existen posibles debilidades en la implementación de los CAP que pueden permitir que los ciberdelincuentes se filtren. Un error evidente 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.

El rango de direcciones IPv6 desde el que se originaron los ataques pertenece a LSHIY, un proveedor de infraestructura de internet registrado en Hong Kong, Wuhan (China) y Nueva York. También existen otros informes que indican que los rangos de IPv6 asociados con AS32167 y AS955, dos sistemas autónomos (ASN) operados por la empresa, se originan en China.

Fuente: THN

Seguir leyendo...

CitrixBleed: seis vulnerabilidades de NetScaler permiten la lectura de archivos y ataques de denegación de servicio

Ayer Citrix publicó actualizaciones de seguridad para solucionar múltiples fallos en NetScaler ADC (anteriormente Citrix ADC) y NetScaler Gateway (anteriormente Citrix Gateway) que podrían ser explotados por un atacante para facilitar la lectura arbitraria de archivos o provocar una denegación de servicio (DoS).

Las vulnerabilidades se enumeran a continuación:

• CVE-2026-8451 (CVSS: 8.8): Vulnerabilidad de validación de entrada insuficiente que provoca una lectura excesiva de memoria cuando NetScaler ADC o NetScaler Gateway se configura como un IDP SAML.
• CVE-2026-8452 (CVSS: 8.8): Vulnerabilidad de desbordamiento de memoria que provoca un comportamiento impredecible o erróneo y una denegación de servicio cuando el dispositivo se configura como una puerta de enlace o un servidor virtual AAA.
• CVE-2026-8655 (CVSS: 8.8): Múltiples vulnerabilidades de desbordamiento de memoria que provocan un comportamiento impredecible o erróneo y una denegación de servicio cuando NetScaler ADC se configura como un balanceador de carga de tipo Oracle, un proxy DNS o una implementación de resolución recursiva DNS.
• CVE-2026-10816 (CVSS: 7.7): Control externo del Vulnerabilidad de ruta de archivo que permite la lectura arbitraria de archivos sin autenticación cuando el acceso a NSIP, la IP de administración del clúster o SNIP con acceso de administración está habilitado.
• CVE-2026-10817 (CVSS: 6.9): Vulnerabilidad de validación de entrada insuficiente que provoca una lectura excesiva de memoria cuando TCP TimeStamp está habilitado en el perfil TCP y asociado con el servidor virtual (de tipo LB, CS, VPN) o el servicio configurado en NetScaler.
• CVE-2026-13474 (CVSS: 8.7): Vulnerabilidad de liberación de memoria faltante después del tiempo de vida efectivo que provoca una denegación de servicio mediante solicitudes HTTP/2 mal formadas cuando HTTP/2 está habilitado en el perfil HTTP y asociado con el servidor virtual (de tipo LB, CS, VPN) o el servicio configurado en NetScaler.

Se han publicado parches para las vulnerabilidades de seguridad en las siguientes versiones:

• NetScaler ADC y NetScaler Gateway 14.1-72.61 y versiones posteriores
• NetScaler ADC y NetScaler Gateway 13.1-63.18 y versiones posteriores de la versión 13.1
• NetScaler ADC 14.1-FIPS, 14.1-72.61 FIPS y versiones posteriores de la versión 14.1-FIPS
• NetScaler ADC 13.1-FIPS y 13.1-NDcPP, 13.1.37.272 y versiones posteriores de las versiones 13.1-FIPS y 13.1-NDcPP

En cuanto a la vulnerabilidad CVE-2026-13474, se recomienda a los clientes que actualicen sus configuraciones modificando el parámetro Http2SmallWndTimeout, que controla el tiempo de espera (en segundos) para las transmisiones HTTP/2 de ventana pequeña bloqueadas.

Para los dispositivos que utilizan perfiles HTTP estrictos, este parámetro tiene un valor predeterminado de 30 segundos. La solución se aplica inmediatamente después de la actualización.

Para los dispositivos que NO utilizan perfiles HTTP estrictos, el valor predeterminado es 0. En este caso, la simple actualización a las versiones que incluyen la solución no resolverá la vulnerabilidad por completo. Los clientes deben configurar manualmente Http2SmallWndTimeout a 30 segundos.

El comando para configurar este parámetro se muestra a continuación:

set ns httpProfile <profile_name> -http2SmallWndTimeout <value_in_seconds>

Cisco reconoció la labor de Michael Tucker del equipo XOR de JPMorgan Chase, Aliz Hammond de watchTowr y Maxim Suhanov por reportar las vulnerabilidades. No hay evidencia de que estos problemas se hayan explorado en entornos reales.

watchTowr Labs, en un informe técnico publicado junto con el boletín de Citrix, indicó que la vulnerabilidad CVE-2026-8451 se descubrió y reportó a finales de marzo de 2026 tras intentos de reproducir la CVE-2026-3055 (CVSS: 9.3), una vulnerabilidad independiente de validación de entrada insuficiente que se dio a conocer a principios de este año.

La empresa de ciberseguridad afirmó que la vulnerabilidad se origina en la forma en que NetScaler analiza las solicitudes de autenticación SAML y comparte la misma causa raíz que la vulnerabilidad de marzo de 2026, lo que provoca lecturas de memoria fuera de los límites al enviar solicitudes SAML mal formadas.

"Un aspecto que nos interesa destacar es que, a diferencia de la vulnerabilidad original CVE-2026-3055, que permitía la filtración de kilobytes de datos binarios, esta lectura excesiva interrumpe la lectura fuera de límites cuando se leen diversos caracteres de control, como NULL (o incluso >)", explicó el investigador de seguridad Hammond. "En la práctica, comprobamos que, variando la longitud de la solicitud, podíamos extraer consistentemente algunos bytes del servidor. Sin embargo, lo que debería preocuparnos es el panorama general: la tendencia, que sugiere claramente que la gestión de memoria sigue siendo vulnerable en los dispositivos Citrix NetScaler, hasta el punto de que incluso una configuración incorrecta accidental puede provocar la filtración de memoria".

En los últimos años, los dispositivos Citrix han sido un objetivo lucrativo para los ciberdelincuentes, quienes han explotado múltiples fallos de seguridad en su software para el despliegue de ransomware. Por ello, es fundamental que los usuarios apliquen los parches para una protección óptima.

Fuente: THN

Seguir leyendo...

Explotan activamente una vulnerabilidad crítica de Oracle E-Business Suite

Actores maliciosos están explotando activamente la vulnerabilidad CVE-2026-46817, una vulnerabilidad crítica de acceso remoto sin autenticación en Oracle E-Business Suite (EBS). Se detectó actividad de ataque en tiempo real en infraestructura honeypot durante el fin de semana del 27 y 28 de junio de 2026.

CVE-2026-46817 es una vulnerabilidad de gravedad crítica que reside en el producto Oracle Payments dentro de Oracle E-Business Suite, específicamente en el componente de transmisión de archivos. La vulnerabilidad tiene una puntuación base CVSS de 9.8 y permite que un atacante no autenticado con acceso a la red a través de HTTP comprometa completamente Oracle Payments, lo que conlleva el control total de la confidencialidad, la integridad y la disponibilidad.

Esta vulnerabilidad de seguridad se descubrió en el componente de transmisión de archivos del producto Oracle Payments de EBS y permite que agentes maliciosos no autenticados con acceso a la red HTTP se apoderen de sistemas vulnerables mediante ataques de baja complejidad.

Las versiones afectadas abarcan desde Oracle E-Business Suite 12.2.3 hasta 12.2.15. El vector CVSS refleja la baja complejidad del ataque y la ausencia de requisitos de autenticación, lo que facilita su explotación a gran escala.

Aunque no existe código de prueba de concepto (PoC) público, esta es la primera explotación real conocida de esta vulnerabilidad, lo que indica que el atacante podría estar utilizando capacidades de explotación desarrolladas de forma privada.

El tráfico de ataque capturado en los honeypots de Defused reveló solicitudes POST dirigidas a /OA_HTML/ibytransmit, el punto final de transmisión de archivos de Oracle iPayment.

La IP del atacante, 45.84.137[.]125, operando a través de AS136787 PacketHub S.A. (Francia), se dirigió al puerto 443 y envió una carga útil XML DeliveryRequest manipulada.

La carga útil contenía un esquema de transmisión CODEX_PULL, con el parámetro FULL_FILE_PATH configurado en /etc/passwd, un indicador clásico de una cadena de explotación de lectura de archivos locales/recorrido de rutas diseñada para extraer archivos confidenciales del sistema.

Según Shadowserver, el 28 de junio se registraron un total de 456 ataques en todas las regiones monitorizadas, con Norteamérica (193) y Asia (181) concentrando la mayor parte del tráfico. Europa registró 53 ataques, Sudamérica 18, África 9 y Oceanía 2.

Oracle abordó la vulnerabilidad CVE-2026-46817 en su Actualización Crítica de Parches de Seguridad (CSPU), publicada el 28 de mayo de 2026. Esta actualización corrigió 35 vulnerabilidades CVE distintas en diversas familias de productos de Oracle, 11 de las cuales se clasificaron como críticas.

Oracle recomendó encarecidamente a todos sus clientes que aplicaran los parches inmediatamente después de su publicación. Posteriormente, el 16 de junio de 2026, se publicó una CSPU complementaria que reforzó la postura de Oracle respecto a las vulnerabilidades.

Las organizaciones que utilizan Oracle E-Business Suite deben actuar de inmediato:

• Aplicar sin demora el parche CSPU de mayo de 2026 para las versiones 12.2.3 a 12.2.15 de EBS.
• Bloquee o restrinja el acceso público a internet a las interfaces de Oracle EBS, en particular a la ruta /OA_HTML/.
• Auditar los registros del servidor web en busca de solicitudes POST a /OA_HTML/ibytransmit con cargas útiles XML inusuales.
• Investigar la IP del atacante (45.84.137[.]125) y la cadena User-Agent (ibytransmit-lab-poc/1.0) en los registros del firewall y del proxy.
• Realizar una evaluación de la vulnerabilidad si la aplicación del parche se retrasó más allá del 28 de mayo de 2026.

Dada la ausencia de código PoC público y la aparición confirmada de herramientas de explotación privadas, las implementaciones de Oracle EBS sin parchear siguen expuestas a un grave riesgo de sufrir una vulneración total del sistema.

Fuente: CyberSecurityNews

Seguir leyendo...

Microsoft extiende el soporte gratuito de ESU para Windows 10 hasta octubre de 2027

El 14 de octubre de 2025, Windows 10 llegó al final del soporte y Microsoft ya no brinda soporte técnico, actualizaciones de funciones o actualizaciones de seguridad para el sistema operativo a menos que esté ejecutando una versión LTSC de Windows.

Para aquellos que no pueden actualizar a Windows 11, Microsoft originalmente ofreció a los consumidores un año adicional de actualizaciones de seguridad si se inscribían en un programa gratuito de actualizaciones de seguridad extendidas (ESU) que expiraría el 12 de octubre de 2026.

Ahora, Microsoft ha extendido silenciosamente su programa gratuito de Actualizaciones de seguridad extendidas (ESU) de Windows 10 para consumidores por un año adicional, lo que permite que los dispositivos inscritos continúen recibiendo actualizaciones de seguridad hasta el 12 de octubre de 2027.

El cambio se realizó sin un anuncio formal y, en cambio, apareció en actualizaciones de la documentación ESU de Windows 10 de Microsoft y como una "nota del editor" de una publicación del blog Windows Experience publicada ayer.

"Nota del editor – 25 de junio de 2026 – Esta publicación se actualizó para reflejar que el programa de Actualizaciones de seguridad extendidas (ESU) de Windows 10 para dispositivos de uso personal se proporciona por un año adicional, con cobertura ahora disponible hasta el 12 de octubre de 2027", se lee en la publicación de blog actualizada.

Esta extensión brinda a los clientes más tiempo para realizar la transición a una nueva PC con Windows 11 mientras continúan recibiendo actualizaciones de seguridad críticas.

Los clientes empresariales también podrían inscribirse en el programa ESU por hasta tres años, lo que eleva el costo total por dispositivo a $427 durante ese período.

Cuando se le preguntó por qué se amplió el programa ESU gratuito, Microsoft compartió la siguiente declaración con BleepingComputer: "Entendemos que pasar a una nueva PC puede llevar tiempo. Como parte de nuestro compromiso continuo de ayudar a los clientes a mantenerse seguros durante la transición, el programa de actualizaciones de seguridad extendidas (ESU) de Windows 10 para dispositivos personales se ofrece por un año adicional", explicó Microsoft.

Los consumidores pueden seguir recibiendo seguridad ampliada de forma gratuita utilizando uno de estos métodos:

• Pagando $30.
• Hacer una copia de seguridad de su configuración de Windows en su cuenta de Microsoft.
• Canjear 1000 puntos de recompensa de Microsoft.
• Los usuarios del Espacio Económico Europeo pueden recibir ESU de forma gratuita iniciando sesión en Windows 10 con una cuenta de Microsoft.

Microsoft dice que una licencia ESU se puede usar en hasta 10 dispositivos asociados con la misma cuenta de Microsoft, y los usuarios ya inscritos permanecerán cubiertos automáticamente hasta la nueva fecha final de octubre de 2027.

La compañía señala que el programa ESU para consumidores es solo para dispositivos personales y no está disponible para sistemas unidos a dominios de Active Directory, Microsoft Entra o administrados a través de Mobile Device Management (MDM). Sin embargo, los dispositivos registrados en Microsoft Entra son elegibles.

Fuente: BC

Seguir leyendo...

Pedit COW: nueva vulnerabilidad en Linux permite a los usuarios obtener root

Una nueva vulnerabilidad de Linux permite el acceso de administrador mediante la manipulación de binarios en caché. La vulnerabilidad en el subsistema de control de tráfico del kernel de Linux permite que un usuario local sin privilegios obtenga acceso de root en los sistemas afectados.

La vulnerabilidad CVE-2026-46331, apodado "pedit COW", permite a los usuarios locales obtener acceso de administrador en sistemas Linux afectados corrompiendo la memoria caché de páginas a través de act_pedit.

Esta vulnerabilidad es una escritura fuera de límites en la acción de edición de paquetes (act_pedit) que corrompe la memoria caché de páginas compartida. Un exploit público y funcional apareció apenas un día después de la asignación de la CVE, el 16 de junio. Red Hat considera esta vulnerabilidad importante.

El exploit nunca accede al archivo en disco. Envenena la copia en caché de un binario de root setuid (/bin/su) en memoria, inyecta una pequeña carga útil y ejecuta esa imagen modificada como root. Las comprobaciones de integridad de archivos no generan ningún problema mientras ya hay una shell de root abierta.

El exploit requiere dos condiciones: que act_pedit sea cargable y que los espacios de nombres de usuario sin privilegios estén abiertos, lo que otorga al atacante la capacidad de red local del espacio de nombres (CAP_NET_ADMIN) necesaria para activar el fallo.

En los sistemas RHEL y Debian probados, ambas condiciones estaban presentes.

Cómo funciona el error

La herramienta de control de tráfico tc de Linux puede reescribir las cabeceras de los paquetes en tránsito mediante una acción llamada pedit. La función del kernel que realiza esta acción, tcf_pedit_act(), debería crear una copia privada de los datos antes de editarlos, siguiendo el patrón estándar de copia en escritura.

Se verifica el rango de escritura una sola vez, antes de conocerse los desplazamientos finales. Algunas claves de edición solo resuelven su desplazamiento en tiempo de ejecución. Cuando esto sucede, la escritura se produce fuera de la región copiada privadamente, por lo que el kernel modifica una página de la caché de páginas compartida en lugar de una copia privada. Si esa página pertenece a un archivo en caché, la imagen en memoria del archivo se corrompe.

El patrón es conocido. Dirty Pipe, Copy Fail, Dirty Clone y Dirty Frag comparten la misma estructura: una ruta rápida del kernel escribe en una página que no le pertenece exclusivamente, y la caché de páginas sufre la penalización.

La novedad reside en el punto de entrada. Un usuario sin privilegios puede configurar las acciones de tc desde dentro de un espacio de nombres de usuario, lo que le otorga el CAP_NET_ADMIN que necesita el exploit.

Sistemas afectados

El autor de la prueba de concepto informó de una explotación de usuario sin privilegios a root en RHEL 10 y Debian 13 (trixie), donde los espacios de nombres de usuario sin privilegios están abiertos por defecto. Ubuntu 24.04 requería enrutar la ejecución a través de perfiles de AppArmor que aún permitían espacios de nombres de usuario. Ubuntu 26.04 bloquea esta ruta por defecto, ya que sus perfiles de AppArmor restringen los espacios de nombres de usuario sin privilegios, aunque el kernel subyacente sigue siendo vulnerable.

Las correcciones varían según el proveedor.

• Debian ha corregido trixie a través de su canal de seguridad. Debian 11 y 12 siguen figurando como vulnerables.
• Ubuntu enumera las versiones compatibles desde la 18.04 hasta la 26.04 como vulnerables a fecha de 25 de junio.
• Red Hat enumera RHEL 8, 9 y 10 como afectadas; RHEL 7 no aparece en el boletín.

Qué hacer

Instalar el kernel parcheado y reiniciar. Priorizar los sistemas donde "usuario local" no significa usuario de confianza: hosts multiusuario, ejecutores de CI/CD, nodos de Kubernetes, trabajadores de compilación y máquinas compartidas de investigación o laboratorio.

Si aún no puedes aplicar el parche, existen dos medidas para interrumpir la cadena de explotación. En sistemas que no requieren reglas de `tc pedit`, verifica si el módulo está en uso:

lsmod | grep act_pedit
echo 'install act_pedit /bin/true' | sudo tee /etc/modprobe.d/disable-act_pedit.conf`

Como alternativa, desactivar los espacios de nombres de usuario sin privilegios (user.max_user_namespaces=0 en RHEL, kernel.unprivileged_userns_clone=0 en Debian/Ubuntu). Esto elimina la capacidad de acceso local al espacio de nombres que necesita la explotación, pero afecta a los contenedores sin privilegios de root, a algunos entornos aislados de CI y a los navegadores aislados. Realiza pruebas antes de comenzar.

Dado que la sobrescritura se realiza en la memoria caché, es posible que las comprobaciones de integridad de archivos no la detecten. Se puede vaciar la caché de páginas:

echo 3 > /proc/sys/vm/drop_caches

Con esto se borra la copia en memoria infectada, pero no se soluciona el problema de la shell de root que el atacante ya había abierto. Se debe considerar el host como comprometido.

La solución se publicó en la lista de correo de netdev a finales de mayo, presentada como un parche rutinario para la corrupción de datos. El detalle explotable permaneció en una lista de correo pública durante semanas. Se incluyó en la advertencia de seguridad CVE. La CVE se asignó cuando se integró la solución el 16 de junio. La prueba de concepto con potencial de explotación se publicó al día siguiente. Para los errores de corrupción de la caché de páginas del kernel, esperar a que se complete una regla de escaneo es demasiado lento.

Aquí hay un repositorio para validarlo.

Fuente: THN

Seguir leyendo...

Vulnerabilidades explotadas: ya no puedes salir de esto con parches

Durante treinta años, la gestión de vulnerabilidades se ha basado en lo que ahora parece un lujo imposible: un margen de meses entre el momento en que se encontró una vulnerabilidad y el momento en que alguien pudo descubrir cómo convertirla en un arma. Clasificar por gravedad, programar la solución, validar y seguir adelante.

Ese generoso amortiguador es lo que hizo que todo el sistema funcionara.

La IA ha eliminado el arrastre manual que hacía que la creación y utilización de "armas" fuera lenta. Leer el aviso, encontrar el camino, dar forma a la cadena, probar qué funciona: nada de eso puede darse el lujo de moverse a la velocidad humana. Hoy en día, los plazos desde la divulgación hasta la explotación son de horas, no de meses.

El Zero Day Clock, que rastrea esto en tiempo real, actualmente tiene un promedio de alrededor de 8 horas para 2026, frente a aproximadamente 53 días hace apenas dos años. La cifra cambia a medida que llegan nuevos datos, pero en este punto se sitúa firmemente por debajo de las 24 horas.

No puedes salir de esto con parches

El reflejo suele ser simplemente parchear más rápido. Pero la remediación no es simplemente un interruptor que se activa. Los parches esperan una serie de contingencias: pruebas de regresión, ventanas de cambio y compromisos de tiempo de actividad. Y hoy, lamentablemente, todos los números que importan van en la dirección equivocada.

El Informe de investigaciones de vulneración de datos de 2026 de Verizon, elaborado en más de 13.000 organizaciones, encontró que:

• El tiempo medio de reparación de vulnerabilidades conocidas y explotadas es ahora de 43 días, frente a los 32 del año pasado.
• La proporción de organizaciones que los parchean completamente se redujo del 38% al 26%.
• Incluso los que tienen mejor desempeño cierran sólo entre el 30 y el 40% de estas vulnerabilidades en la primera semana, una tasa que apenas ha variado en años.

Cuando la infracción se desarrolla en horas y la reparación en semanas, la infracción se produce en el medio. Y la pista cada vez es más larga.

El volumen lo garantiza: 48.185 CVE en 2025, menos del 0,6% jamás parcheados. "Parchear para salir" ha dejado de ser una matemática viable.

Mythos es el umbral en el que los modelos de IA fueron capaces de encontrar y convertir en armas vulnerabilidades por sí solos, y no es teórico: el modelo de clase Mythos de Anthropic encontró una falla que había estado oculta en OpenBSD, ampliamente considerado como uno de los sistemas operativos más seguros del mundo, durante 27 años.

La línea de base para 2025 se ha convertido en el piso, no en el techo.

La pregunta ya no es "¿qué es vulnerable?" porque en una lista donde todo tiene una puntuación de 9 o 10, esto efectivamente no prioriza nada. La verdadera pregunta es: "¿Qué es realmente explotable contra nosotros en este momento, con los controles que ya estamos aplicando?". Encontrar la exposición nunca fue la parte difícil. Demostrar la decisión correcta (parchear, mitigar, monitorear o aceptar) es la brecha crítica.

Las herramientas de pentesting automatizados toman la prueba de penetración manual que solía realizarse una vez por trimestre y la ejecutan continuamente, a escala, activando cadenas de exploits reales contra activos reales. Donde se puede ejecutar eso, es la prueba más fuerte que existe: ves cómo el exploit tiene éxito. Pero, aunque automatizar el lanzamiento te hace más rápido; no cambia lo que puede alcanzar la explotación.

La explotación en vivo solo funciona cuando es seguro activar un exploit y cuando existe un exploit funcional. Eso deja tres espacios en la herramienta pentest que se pueden cerrar, y apilarlos juntos tampoco ayuda. ¿Por qué?

• Sin exploit, nada que ejecutar. Una gran parte de los CVE divulgados nunca obtienen un exploit público o seguro. Sin nada que iniciar, la ejecución no puede indicarle si son explotables en su entorno.
• Activos que no puedes arriesgar. Los sistemas críticos para el negocio, regulados y aislados son exactamente aquellos contra los que no se puede detonar un exploit de forma segura y, por lo general, son los que más importan.
• La ventana del primer día. Armar un nuevo exploit y conectarlo a sus herramientas lleva tiempo. Los atacantes ya se están moviendo mientras tu lanzamiento todavía está en el banco.

En una empresa típica, la porción que puede explotar de forma segura en vivo suele ser sólo del 10 al 15% de su imagen de exposición total. Para el 85% o 90% restante, la ejecución no tiene respuesta que dar.

Probar en tierra un cohete que no se puede lanzar

La forma más segura de demostrar que un cohete volará es lanzarlo. Pero ningún programa espacial demuestra que su flota sea así.

Algunos existen sólo como un diseño en papel, otros cuentan con tripulación y son demasiado valiosos para arriesgarlos, y otros todavía están en la línea de ensamblaje. Así que los ingenieros los prueban en tierra: el motor empuja en una posición estática, prueba el sistema de combustible bajo presión total y el escudo térmico contra su carga térmica máxima. Si algún componente requerido falla, el cohete no puede volar y ellos lo saben sin abandonar la plataforma.

Ésa es la misma brecha de tres partes que enfrentan los equipos de seguridad.

• El CVE sin exploits es el cohete que sólo existe en el papel.
• El activo prohibido es el cohete tripulado que no arriesgarás.
• El CVE del primer día es el fuselaje parcialmente construido mientras se agota la ventana de lanzamiento.
• El lanzamiento es la prueba a la que llegas cuando puedes; la prueba sobre el terreno es la prueba en la que confías cuando no puedes.

Romper la cadena, rompe el exploit

Un exploit no es mágico. Es una cadena de técnicas específicas, los TTP que un atacante tiene que ejecutar en secuencia: obtener ejecución, eludir una protección, escalar privilegios, deshacerse de credenciales, avanzar hacia el objetivo.

Cada enlace depende de las condiciones de su entorno, y cada uno puede probarse por sí solo con los controles implementados reales, de la misma manera que un ingeniero prueba un motor en un soporte estático sin tener que arrancar todo el vehículo.

Esa es la validación de la cadena TTP. Usted asigna un CVE a la cadena de técnicas que requiere su explotación y luego valida cada técnica con sus controles existentes. Si su entorno rompe algún vínculo requerido, el exploit no podrá tener éxito allí y usted lo sabrá sin tener que activar un exploit activo. Si todos los vínculos se mantuvieran, la exposición sería genuinamente explotable, con evidencia.

Cuatro cosas distintas que veredicto de una etiqueta CVSS o EPSS estática:

• Valida por inferencia, no por detonación. Por lo tanto, funciona donde la explotación en vivo sería insegura o imposible.
• Es consciente del control. El veredicto refleja su EDR, GPO, protección LSASS, lista de permitidos y firewall reales, no solo un número en una hoja de datos.
• Pesa la accesibilidad. Las exposiciones contenidas no se contabilizan en exceso.
• Envía pruebas. La cadena, los controles probados y el resultado: una pista de auditoría que llega hasta la junta directiva.

Cómo se ve en un CVE real

Tomemos como ejemplo CVE-2025-29824, un uso después de la liberación de CLFS de Windows que escala a SYSTEM (visto en estado salvaje en la actividad Storm-2460 o RansomEXX).

En lugar de activar un exploit, lo descompones en la cadena que un atacante debe ejecutar y prueba cada paso con tu pila:

• Ejecución de certutil y MSBuild – T1105 / T1127
• Bypass KASLR / SysInfo – T1082
• Explotación CLFS UAF → ejecución del kernel – T1068
• modificación de token e inyección de dllhost – T1134 / T1055
• Volcado de LSASS a través de dllhost enmascarado – T1003

Cada técnica se prueba con respecto a la política de EDR, GPO/refuerzo, protección LSASS, lista de aplicaciones permitidas y NGFW.

Si su lista de permitidos detiene el ejecutivo de MSBuild, o su protección LSASS bloquea el volcado de credenciales, la cadena se rompe, el CVE no es explotable en ese activo y puede mostrar exactamente por qué. No se necesita un exploit certificado y funciona en la caja aislada a la que nunca apuntarías un exploit en vivo. Y al hacerlo, ha pasado de una nueva identificación CVE a una decisión defendible en horas, el día de la divulgación, en lugar de semanas después.

Pruébelo en todas partes, no sólo donde pueda lanzarlo

El lanzamiento y la prueba en tierra no son rivales, son simbióticos. Los programas más potentes ejecutan ambos y siguen probando a medida que el entorno avanza a través del tiempo y las configuraciones.

Se pueden ejecutar cadenas de exploits en vivo donde el disparo es seguro, encadenamiento TTP para los activos fuera de los límites y CVE del primer día que un lanzamiento no puede alcanzar, y validación de control continuo para que la "aceptación" del último trimestre se vuelva a probar, no se asuma.

Esto da una respuesta a la única pregunta que importa: "¿Qué es realmente explotable aquí y ahora?"

Fuente: BC

Seguir leyendo...

LastPass confirma (de nuevo) brecha que filtró nombres, teléfonos y direcciones de correo de sus usuarios

LastPass ha tenido un historial complicado en materia de seguridad durante los últimos años. De acuerdo con TechCrunch, la brecha no ocurrió directamente en LastPass, sino en Klue, una plataforma que la empresa utiliza en sus operaciones comerciales. Según el reporte, los atacantes aprovecharon el acceso a Klue para obtener tokens OAuth que la plataforma almacenaba en nombre de sus clientes, incluido LastPass.

LastPass se suma a una creciente lista de empresas de ciberseguridad que han reportado robos de datos como consecuencia de la brecha de seguridad en Klue, que la compañía reveló la semana pasada. Otras empresas afectadas incluyen Gong, Jamf, HackerOne, Insurity, OneTrust, Recorded Future, Snyk, Sprout Social, and Tanium.

Con esas credenciales, los atacantes lograron entrar en el entorno de Salesforce de LastPass y extraer datos de sus usuarios. La información comprometida incluye nombres, números de teléfono, direcciones de correo electrónico y direcciones físicas, junto con datos de casos de soporte al cliente y registros relacionados con ventas. Tras detectar la presencia de atacantes en su sistema, Klue notificó a LastPass sobre el incidente.

Lo que todavía no está claro es el contenido exacto de los tickets de soporte al cliente. Ese tipo de registros suele contener fragmentos de información sensible, ya que los usuarios generalmente contactan con soporte cuando tienen problemas de facturación o necesitan recuperar el acceso a sus cuentas. Incidentes anteriores con datos de tickets de soporte han llegado a exponer credenciales y documentos de identidad oficiales.

LastPass ha declarado que la brecha de Klue no afectó a sus sistemas en ningún momento. Las contraseñas almacenadas en las bóvedas de los usuarios permanecen seguras, y no hay evidencia de que los atacantes accedieran a datos relacionados con la plataforma Gong, otra herramienta integrada con Klue.

La reputación de LastPass lleva tiempo acumulando golpes. En 2022, la compañía sufrió una brecha mucho más grave en la que los atacantes se hicieron con todas las bóvedas cifradas de contraseñas de sus clientes. Aunque esos archivos estaban protegidos con las contraseñas maestras de cada usuario, los hackers consiguieron descifrar algunas de ellas que usaban claves débiles y las aprovecharon para acceder a billeteras de criptomonedas.

Este nuevo incidente es menos catastrófico en comparación, pero tiene sus propias implicaciones. Tener tu nombre, teléfono y dirección en manos de atacantes es suficiente para convertirte en objetivo de phishing o ingeniería social. LastPass lo reconoce en su comunicado oficial y recomienda a sus usuarios estar alerta ante cualquier contacto no solicitado, ya sea por email, teléfono u otros canales.

Otro detalle que vale la pena recordar es que nadie de LastPass te pedirá jamás tu contraseña maestra. Si recibes un mensaje solicitándola, independientemente de cómo esté redactado, es una señal de alarma.

Según el reporte, el responsable del ataque es un grupo de extorsión llamado Icarus, que también ha atacado a otras compañías a través de la brecha en Klue. El grupo ya amenazó con publicar los datos robados si no recibe un pago por rescate. Klue, por su parte, aún no ha confirmado cuántos clientes se han visto afectados ni si ha habido contacto con los atacantes.

LastPass confirmó que han remediado el problema y los tokens OAuth expuestos han sido rotados desde entonces. "Los productos, servicios e infraestructuras de LastPass no se vieron afectados de ninguna manera y las bóvedas de clientes siguen siendo seguros", mencionó.

Fuente: TechCrunch

Seguir leyendo...

FortiBleed: detalles de la operación de robo de 110 millones de credenciales (y contando)

Se cree que un intermediario de acceso inicial (IAB) de habla rusa, motivado por el lucro, está detrás de una operación de robo de credenciales a gran escala conocida como FortiBleed, que ha afectado a más de 430.000 firewalls FortiGate en todo el mundo.

La campaña, activa desde febrero de 2026, consiste en recopilar listas de credenciales, buscar servicios expuestos, realizar ataques de fuerza bruta contra sistemas accesibles e implementar analizadores de red personalizados en los firewalls comprometidos.

"Una vez implementados, estos analizadores capturan credenciales en texto plano y cifradas del tráfico que pasa por los dispositivos comprometidos", afirma SOCRadar en un informe reciente. "Los atacantes luego descifran, validan y reutilizan las credenciales contra dominios de Active Directory y otros servicios expuestos".

La clave de la operación es una herramienta basada en Go llamada FortigateSniffer, que aprovecha el comando de diagnóstico integrado de FortiOS, `-diagnose sniffer packet`, para capturar pasivamente el tráfico de autenticación de los dispositivos infectados. La herramienta está diseñada para monitorizar el tráfico a través de 24 protocolos, analizar los datos de autenticación y extraer las credenciales.

Se sospecha que los ciberdelincuentes podrían haber recurrido a una plataforma de seguridad ofensiva de código abierto basada en IA, denominada CyberStrike, para optimizar algunas partes del proceso. Curiosamente, otro marco de código abierto, CyberStrikeAI, se utilizó en relación con otra campaña de escaneo masivo automatizado dirigida a dispositivos FortiGate, que Amazon Threat Intelligence reveló a principios de este año.

La campaña muestra un fuerte enfoque en las pequeñas y medianas empresas (pymes) con menos de 200 empleados. El atacante se dirige a múltiples sectores y regiones, con especial énfasis en Estados Unidos e India. El sector de servicios de TI parece ser un objetivo clave. Esta elección de objetivos probablemente ayuda al atacante a maximizar el acceso posterior, ya que los proveedores de servicios comprometidos pueden crear vías de acceso a los entornos de los clientes.

Quizás el hallazgo más interesante sea que FortiBleed parece formar parte de una operación de acceso inicial más amplia y multivendedor, orquestada no solo para atacar dispositivos Fortinet, sino también para vulnerar NAS de Synology, firewalls de Sophos, portales RDWeb, VPN SSL de Citrix y servidores MS-SQL mediante ataques de fuerza bruta automatizados desde el 28 de febrero de 2026.

En total, se estima que los atacantes lanzaron al menos 659 campañas de robo de credenciales entre el 31 de mayo y el 15 de junio de 2026, lo que resultó en la identificación de más de 110 millones de credenciales. Esto incluyó:

• 14,8 millones de credenciales RADIUS (Servicio de Autenticación Remota de Usuarios por Marcación)
• 924.000 hashes NTLM
• 130.000 hashes Kerberos
• 89 millones de tokens de autenticación MySQL

La campaña FortiBleed se desarrolla en cinco etapas:

1. Primero, se realiza un reconocimiento exhaustivo utilizando herramientas como Masscan y Shodan para identificar firewalls FortiGate vulnerables con acceso a internet. Posteriormente, se utilizan una utilidad personalizada llamada FortiProbe-fast y GeoSplit para filtrar los sistemas FortiGate y agruparlos por país, respectivamente.
2. Comprometer los dispositivos con un verificador de credenciales llamado "forticheck" que ataca específicamente el panel administrativo y el portal SSL-VPN de FortiGate, además de utilizar herramientas para obtener acceso administrativo SSH mediante ataques de relleno de credenciales y de diccionario.
3. Tras establecer el acceso por SSH, FortigateSniffer se implementa para interceptar pasivamente el tráfico de autenticación en 24 protocolos (p. ej., TACACS+, Kerberos, RPC, SMB, LDAP, SMTP, FTP, Telnet, RDP, WinRM, MS-SQL, MySQL, PostgreSQL y RADIUS) mediante comandos de diagnóstico nativos de FortiOS, lo que permite obtener credenciales en texto plano y hashes de contraseñas.
4. Los hashes de contraseñas se descifran con Hashmat y Hashtopolis, y se procesan mediante un bot de Telegram llamado HASHBOT. Posteriormente, se utilizan para el movimiento lateral y la enumeración de Active Directory.
5. Se extraen datos confidenciales de los recursos compartidos de red, mientras que las cookies de sesión robadas se utilizan para mantener un acceso persistente y autenticado.

"El grupo no trata a todos los objetivos por igual", dijo SOCRadar. "En cambio, los objetivos se clasifican según su valor económico antes de asignar los recursos para su explotación".

Además, el mecanismo de rastreo incluye un filtro de geolocalización que restringe las operaciones a rangos de IP específicos, limitando la actividad al horario comprendido entre las 7:00 y las 18:00, hora de Moscú. Según datos capturados por SpyCloud, el ciclo de captura relacionado con FortiGate habría comenzado el 19 de mayo de 2026, y la infraestructura de descifrado de hashes se instaló a finales de mes.

"La operación se ejecuta en ciclos de 300 minutos (cinco horas), con actualizaciones de estado cada minuto", declaró Zenox. "En cada ciclo, carga una lista de objetivos regionales [...] y realiza la validación con 1.000 hilos simultáneos, mostrando contadores de éxito, fallo, tiempo de espera agotado y advertencia. En los primeros ciclos, la tasa de validación exitosa rondaba el 90%".

La empresa brasileña de ciberseguridad también informó haber encontrado ciertas combinaciones de nombre de usuario y contraseña repetidas en miles de direcciones IP distintas, lo que plantea la posibilidad de que el atacante haya creado estas cuentas como puerta trasera clandestina.

Este hecho se produce después de que una cuenta en ruso llamada "SantaAd" anunciara el acceso a miles de dispositivos Fortinet por un precio inicial de 30.000 dólares, que horas después aumentó a 60.000 dólares. Sin embargo, no está claro si esto tiene alguna relación con la filtración de FortiBleed.

"El grupo de ciberdelincuentes responsable de 'FortiBleed' no solo atacaba las VPN de FortiGate", declaró SpyCloud. "En realidad, atacaban una variedad de dispositivos conectados a internet con una cadena de ataques estándar de tipo 'bombardeo masivo' que se basa principalmente en escaneos masivos y ataques de fuerza bruta para obtener accesos".

Fuente: THN 

Seguir leyendo...

(Supuestamente) el modelo de IA Mythos violó los sistemas clasificados de la NSA en cuestión de horas

Según informes, el modelo de IA Mythos, el producto estrella de Anthropic, se infiltró en casi todos los sistemas clasificados de la Agencia de Seguridad Nacional (NSA) en cuestión de horas durante una evaluación de seguridad autorizada realizada el 11 de junio. Este incidente parece ser la principal razón de la directiva del gobierno estadounidense sobre controles de exportación emitida al día siguiente.

El senador Mark Warner, vicepresidente del Comité de Inteligencia del Senado, reveló que el general Joshua Rudd, quien dirige simultáneamente la NSA y el Comando Cibernético de EE.UU., le comunicó directamente que el modelo Mythos de Anthropic "irrumpió en casi todos nuestros sistemas clasificados, no en semanas, sino en horas".

Esta declaración, publicada inicialmente por The Economist, no ha sido confirmada formalmente por ninguna agencia gubernamental, pero ha modificado rápidamente el discurso en torno a la decisión de Washington de retirar del acceso público los dos modelos más avanzados de Anthropic.

La revelación recontextualiza la directiva del Departamento de Comercio del 12 de junio, que prohibía a todos los ciudadanos extranjeros, incluidos los empleados no ciudadanos de Anthropic, el acceso a Fable 5 y Mythos 5.

Posteriormente, Anthropic suspendió ambos modelos para todos sus clientes. Es crucial destacar que esta es la primera vez que Estados Unidos aplica controles de exportación directamente a un modelo de IA en lugar de al hardware o los chips que lo impulsan, un precedente regulatorio histórico en la gobernanza de la seguridad nacional de la IA.

Según se informa, los gobiernos aliados de la alianza de inteligencia Five Eyes, incluidos Australia, Gran Bretaña, Canadá y Nueva Zelanda, fueron tomados por sorpresa, ya que se revocaron los permisos de agencias gubernamentales, bancos y grandes empresas sin previo aviso.

Anthropic refuta la justificación del gobierno. La compañía sostiene que el detonante citado fue una vulnerabilidad específica que otros modelos líderes, como GPT-5.5, también presentan, y califica la retirada masiva como una reacción desproporcionada.

Según Anthropic, la conducta detectada consistió en solicitar al modelo que analizara el código fuente y corrigiera los problemas identificados, y no en una intrusión ofensiva autónoma real. La empresa está trabajando activamente para restablecer el acceso y está preparando un marco de gestión de riesgos en colaboración con la Casa Blanca.

Fuente: CyberSecurityNews

Seguir leyendo...