Nuevas vulnerabilidades de escalamiento en Linux (Ubuntu y Red Hat)

Vulnerabilidad LPE en snap-confine (en Ubuntu)

Investigadores de ciberseguridad han revelado detalles de una nueva vulnerabilidad de escalamiento de privilegios local (LPE) en snap-confine que un usuario sin privilegios puede activar para obtener acceso de administrador y el control total de un entorno objetivo.

Esta vulnerabilidad de alta gravedad, identificada como CVE-2026-8933 (CVSS: 7.8), afecta a las instalaciones predeterminadas de Ubuntu Desktop 24.04, 25.10 y 26.04. Esta revelación se produce en un contexto en el que se han publicado 442 vulnerabilidades de seguridad en Linux durante los últimos tres días.

"El problema se origina en un cambio de seguridad que introdujo inadvertidamente una condición de carrera durante la inicialización del entorno aislado", declaró Saeed Abbasi, jefe de la Unidad de Investigación de Amenazas (TRU) y director de producto en Qualys.

Snap-confine es un programa utilizado internamente por snapd para construir el entorno de ejecución de las aplicaciones snap. Snapd es el servicio en segundo plano o demonio que gestiona los paquetes snap en sistemas Linux. Snaps no es más que un formato de empaquetado de software ideado por Canonical que permite que una aplicación se ejecute de forma segura en un entorno aislado en la mayoría de las distribuciones de Linux.

Aunque las versiones recientes de Ubuntu utilizan el modelo set-capabilities para aplicar el principio de mínimo privilegio (PoLP) y minimizar así la superficie de ataque, los cambios permiten que snap-confine se ejecute con el UID efectivo del usuario que lo llama, manteniendo al mismo tiempo capacidades cercanas a las de root.

"Durante la configuración del entorno aislado, el binario crea directorios y archivos temporales en /tmp que inicialmente pertenecen al usuario sin privilegios", explicó Qualys. "La propiedad se transfiere a root poco después, pero existe un breve lapso durante el cual quien llama conserva el control total".

El problema identificado por el proveedor de ciberseguridad es el resultado de dos condiciones de carrera concurrentes:

• Un atacante monta un sistema de archivos FUSE malicioso sobre el directorio temporal scratch inmediatamente después de su creación, eludiendo el aislamiento del espacio de nombres de montaje aplicado por snap-confine y manteniendo el directorio accesible fuera del entorno aislado.
• El atacante crea un enlace simbólico (también conocido como symlink) que apunta a un archivo de destino arbitrario, redirigiendo efectivamente las operaciones de archivo a ubicaciones sensibles del sistema.

Al manipular los permisos de archivo antes de que el sistema transfiera la propiedad, el atacante puede inyectar reglas maliciosas en los directorios del sistema y obtener ejecución de código como root, señaló Qualys.

"Cuando snap-confine intenta crear un archivo en el entorno aislado, la llamada a open() sigue al enlace simbólico y escribe en el destino. Una segunda condición de carrera permite al atacante ampliar los permisos de archivo a 0666 antes de que snap-confine llame a fchown() para transferir la propiedad a root".

Para eludir la protección de AppArmor, el exploit se dirige a la ruta /run/udev/**, que permite acceso de lectura y escritura. Al colocar un archivo .rules malicioso en /run/udev/rules.d/ y provocar un ciclo de montaje/desmontaje de FUSE, el atacante fuerza a systemd-udevd a ejecutar comandos arbitrarios como root.

Para contrarrestar el riesgo que supone la vulnerabilidad CVE-2026-8933, las organizaciones deben aplicar las últimas actualizaciones de snapd lo antes posible. "Un atacante aún necesita acceso de usuario o ejecución de código, pero la vulnerabilidad CVE-2026-8933 puede convertir ese acceso en control total del host", declaró Jason Soroko, investigador sénior de Sectigo. "Su presencia en las instalaciones predeterminadas de Ubuntu Desktop hace que las estaciones de trabajo de los empleados, los sistemas de los desarrolladores y los puntos finales administrativos formen parte del alcance de la respuesta".

Ubuntu 24.04 es relevante porque los sistemas actualizados pueden contener la variante afectada de snap-confine, lo que demuestra la importancia de que los administradores verifiquen la versión de snapd instalada en lugar de basarse en la antigüedad de la versión o el estado de los parches anteriores. Con las correcciones disponibles, la implementación y confirmación rápidas deben ser prioritarias.

Esta no es la primera vez que se descubren fallos de seguridad en el componente snap-confine. En febrero de 2022, Qualys detalló otro fallo de escalada de privilegios local, denominado Oh Snap! More Lemmings (CVE-2021-44731), que podía explotarse para obtener privilegios de root aprovechando una condición de carrera en la función setup_private_mount() de snap-confine.

Vulnerabilidad en RefluXFS (en Red Hat)

RefluXFS, una nueva vulnerabilidad del kernel de Linux revelada el 22 de julio y registrada como CVE-2026-64600, permite a un usuario local sin privilegios sobrescribir archivos propiedad del usuario root en un sistema de archivos XFS y obtener acceso root persistente.

Qualys afirmó que las instalaciones predeterminadas de Red Hat Enterprise Linux y sus derivados, Fedora Server y Amazon Linux cumplen las condiciones para su explotación.

La compañía demostró la competencia con los binarios /etc/passwd y setuid-root. La sobrescritura se produce en la capa de bloques. Sobrevive a un reinicio y deja intactos la propiedad, los permisos, las marcas de tiempo y el bit setuid del objetivo, por lo que un binario setuid-root modificado sigue ejecutándose como root.

La solución se integró el 16 de julio y los proveedores de Linux han comenzado a distribuir kernels retroportados. El parche rastrea el error hasta Linux 4.11 en 2017 en una correcciónmarcada como # 4.11.

¿Quiénes están expuestos?

La explotación requiere tres condiciones:

• El sistema ejecuta Linux 4.11 o posterior sin la corrección RefluXFS.
• El sistema de archivos XFS se creó con reflink=1.
• El objetivo legible y un directorio escribible por el atacante se encuentran en el mismo sistema de archivos XFS.

Qualys indicó que se debe parchear primero los sistemas expuestos y multiusuario, lo que significa cualquier host XFS con reflink habilitado donde se pueda ejecutar código no confiable localmente, ya sea a través de una shell, un trabajo de CI o un servicio comprometido.

El aviso enumera las instalaciones predeterminadas que pueden cumplir estas condiciones: Red Hat Enterprise Linux, CentOS Stream, Oracle Linux, Rocky Linux, AlmaLinux y CloudLinux 8, 9 y 10, Fedora Server 31 y versiones posteriores, Amazon Linux 2023 e imágenes de Amazon Linux 2 a partir de diciembre de 2022. Los sistemas de archivos de RHEL 7 no se ven afectados, ya que son anteriores a la compatibilidad con XFS reflink.

Debian, Ubuntu, SLES y openSUSE generalmente no utilizan XFS como sistema de archivos raíz de forma predeterminada. Solo se exponen si un administrador seleccionó XFS con reflink habilitado durante la instalación.

Verifique el sistema de archivos raíz:

xfs_info / | grep reflink=

reflink=1 significa que se cumple la segunda condición. Realice la misma verificación en cualquier otro volumen XFS montado donde un archivo protegido y un directorio con permisos de escritura para atacantes compartan el sistema de archivos.

Qualys no publicó ningún código de explotación independiente. El sistema de seguimiento de Red Hat registró una prueba de concepto pública el 22 de julio, remitiendo al aviso publicado en la lista de correo oss-security, donde se detallan la carrera y los pasos para la explotación. Al momento de redactar este informe, ninguno de los proveedores que monitoreaban la vulnerabilidad había reportado su explotación en la práctica.

Red Hat ha emitido avisos de kernel de categoría Importante para las versiones afectadas de RHEL 8, 9 y 10. Las erratas comenzaron a aparecer el 14 de julio, ocho días antes de la divulgación coordinada: RHSA-2026:39179 y RHSA-2026:39180 para RHEL 8 y RHSA-2026:39494 para RHEL 10, y las versiones de soporte extendido y SAP se actualizaron hasta el 17 de julio. La instalación del paquete no reemplaza el kernel que ya se está ejecutando en memoria. Aplique la actualización del proveedor, reinicie el sistema y verifique que se esté ejecutando el kernel corregido.

Fuente: THN

Seguir leyendo...

Una mujer fue engañada por un falso Kevin Costner y le transfirió más de $3.600.000

La víctima, de 70 años cayó en una estafa virtual tras entablar una conversación en TikTok y Zangi con alguien que se hacía pasar por el actor estadounidense.

La mentira comenzó en otra red social. Según pudo saber Infobae, la mujer comenzó a seguir en TikTok a un perfil con el nombre del actor. Un posteo en un grupo muestra el mensaje de un perfil que utiliza el nombre de usuario Kevin Costner: "Cariño, solo un saludo de tu parte podría poner una sonrisa en mi rostro. Estoy esperando tu mensaje".

El texto aparece junto a una foto del actor dentro de un jet con un ramo de rosas y enlaces a cuentas de Telegram y Zangi. Por supuesto, no se trata del verdadero actor, sino de una persona que busca engañar a usuarios en redes sociales.

Luego de que ese perfil fuera eliminado, el supuesto Costner le propuso continuar la charla a través de la app de mensajería y llamadas Zangi —caracterizada por priorizar la privacidad, sin almacenar datos en servidores ni dejar rastros de las conversaciones—, donde se desarrolló una relación virtual que se extendió durante meses.

En el ida y vuelta de mensajes, el estafador le ofreció a la víctima un carnet especial, de "Club Fan", a cambio de $3.600.000 y además le sugirió vender su casa en Madariaga para que él, supuestamente, le comprara una vivienda en Santa Marta, California.

La mujer no vendió su casa, pero sí transfirió el dinero solicitado. Las transferencias se realizaron entre el 19 y el 21 mayo pasados, por un total de $3.621.712,35, a una billetera virtual. El engaño se sostuvo aún más cuando el estafador le envió un carnet falso que la acreditaba como socia del club de fans. Por esa razón, la jubilada no sospechó durante un tiempo y no realizó la denuncia enseguida.

Sin embargo, más adelante, al leer comentarios de otros usuarios en TikTok y descubrir que había transferido el dinero a una cuenta de una billetera virtual argentina, tomó dimensión de la situación. Entonces decidió denunciar el hecho.

En mayo del año pasado, ocurrió otro caso de estafa muy similar que también involucró a una figura de Hollywood. En esa oportunidad, una mujer argentina fue robada por delincuentes que utilizaron inteligencia artificial para recrear la imagen y la voz de George Clooney.

Fuente: Infobae

Seguir leyendo...

Vulnerabilidad crítica en SharePoint on-prem explotada activamente (CVE-2026-50522)

Según watchTowr, una tercera vulnerabilidad de SharePoint Server on-premises , corregida por Microsoft como parte de su actualización Patch Tuesday de julio de 2026, está siendo explotada activamente.

La vulnerabilidad en cuestión es CVE-2026-50522 (CVSS: 9.8), una deserialización crítica de datos no confiables en Microsoft Office SharePoint que podría permitir a un atacante no autorizado ejecutar código a través de una red. Microsoft reconoció al investigador de DEVCORE, "splitline", por descubrir y reportar la vulnerabilidad.

"En un ataque basado en la red, un atacante autenticado como al menos un propietario del sitio podría escribir código arbitrario para inyectarlo y ejecutarlo remotamente en el servidor de SharePoint", declaró Microsoft en un aviso publicado la semana pasada.

El vector de ataque es de red porque esta vulnerabilidad es explotable de forma remota y puede explotarse desde internet. La complejidad del ataque es baja porque un atacante no requiere un conocimiento previo significativo del sistema y puede lograr el éxito de forma repetible con la carga útil contra el componente vulnerable.

En una publicación compartida en LinkedIn, watchTowr afirmó haber detectado la explotación activa de esta vulnerabilidad en implementaciones locales de Microsoft SharePoint tras la publicación de una prueba de concepto (PoC) pública, que permite a los atacantes robar claves de máquina para mantener el acceso persistente.

"Los atacantes están obteniendo las claves de máquina de SharePoint mediante una sola solicitud", declaró el proveedor de seguridad. "Aplicar parches no es suficiente; los defensores deben rotar las credenciales en cualquier activo que pueda haber sido expuesto".

Defused Cyber ​​también reveló que es probable que los ciberdelincuentes estén explotando la vulnerabilidad CVE-2026-50522 para enviar una carga útil de deserialización .NET a un punto final de inicio de sesión de SharePoint. "Las solicitudes capturadas no contienen material de autenticación, lo que coincide con el perfil no autenticado de la vulnerabilidad 50522", afirmó.

La vulnerabilidad CVE-2026-50522 es la tercera en SharePoint Server, después de CVE-2026-56164 (CVSS: 5.3) y CVE-2026-58644 (CVSS: 9.8), que ha sido objeto de intentos de explotación activa. Las dos últimas se utilizaron como vulnerabilidades de día cero antes de su corrección en julio de 2026.

CISA ha advertido que ciberdelincuentes están explotando múltiples vulnerabilidades de SharePoint Server, incluidas CVE-2026-32201, CVE-2026-45659, CVE-2026-56164 y CVE-2026-58644, para obtener acceso no autorizado a instancias locales.

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

Fuente: THN

Seguir leyendo...

Priorización y gestión de vulnerabilidades: CVSS, EPSS, SSVC y KEV (4 y conclusión)

Leer Priorización y gestión de vulnerabilidades: CVSS, SSVC, EPSS y KEV

Qué es KEV - Catálogo de Vulnerabilidades Explotadas Conocidas

El catálogo de Vulnerabilidades Explotadas Conocidas (KEV - Known Exploited Vulnerabilities) es una lista mantenida por CISA (Cybersecurity and Infrastructure Security Agency) de los Estados Unidos que reúne las vulnerabilidades para las que existe evidencia confiable de explotación activa. A diferencia de CVSS y EPSS, que expresan severidad y probabilidad mediante un valor numérico, el KEV es un catálogo binario: una vulnerabilidad está o no está en la lista.

Su inclusión confirma que la explotación ya no es teórica, sino que actores maliciosos la están utilizando de forma real, lo que la convierte en una de las señales de priorización más contundentes disponibles.

Criterios para incluir una vulnerabilidad en el catálogo

Para que una vulnerabilidad se incorpore al catálogo KEV, CISA exige que cumpla tres condiciones:

• Tener asignado un identificador CVE.
• Contar con evidencia confiable de explotación activa en entornos reales (in the wild), y no solo con una prueba de concepto o la mera existencia de un exploit público.
• Disponer de una acción de remediación clara, como una actualización o parche del proveedor, o una medida de mitigación indicada por CISA.

El mandato BOD 22-01

El catálogo se creó en noviembre de 2021 en el marco de la Directiva Operativa Vinculante (BOD) 22-01. Esta directiva obliga a las agencias del poder ejecutivo civil federal (FCEB) de los Estados Unidos a remediar las vulnerabilidades listadas dentro de los plazos que CISA fija para cada entrada. Aunque el mandato solo es de cumplimiento obligatorio para dichas agencias, CISA recomienda encarecidamente que toda organización —pública o privada— utilice el KEV como insumo prioritario en su proceso de gestión de vulnerabilidades.

Cómo se integra con CVSS, EPSS y SSVC

El KEV complementa a los otros sistemas en lugar de reemplazarlos. Mientras el EPSS estima la probabilidad de que una vulnerabilidad sea explotada, el KEV confirma que la explotación ya está ocurriendo; por eso, un CVE presente en el KEV debería tratarse como prioridad máxima aun cuando su puntuación EPSS o CVSS sea baja.

En un flujo de priorización, el KEV funciona como un filtro de arranque: cualquier vulnerabilidad del entorno que figure en el catálogo se atiende de inmediato, y recién después se aplican CVSS, EPSS y SSVC para ordenar el resto. En el árbol de decisión de SSVC, la presencia en el KEV corresponde al estado de explotación más alto (active), que empuja la decisión hacia Attend o Act.

Cómo usarlos en la práctica CVSS | EPSS | SSVC

La combinación de estos tres sistemas permite un enfoque de priorización mucho más inteligente y eficiente:

1. Utiliza CVSS como punto de partida: Escanea tu entorno para identificar vulnerabilidades y usa su puntuación CVSS para tener una idea de la severidad técnica. Las vulnerabilidades con una puntuación CVSS alta o crítica (7.0-10.0) son un buen punto de partida.
2. Añade el contexto del EPSS: De las vulnerabilidades con CVSS alto, revisa sus puntuaciones EPSS. Una vulnerabilidad con una puntuación CVSS de 9.8 pero un EPSS de 0.01% probablemente no es una prioridad inmediata para ser parcheada, ya que no se está explotando activamente. Por otro lado, una vulnerabilidad con un CVSS de 7.5 y un EPSS de 90% debería ser una prioridad máxima, ya que es probable que sea explotada.
3. Aplica el SSVC para la toma de decisiones operativas: Una vez que has priorizado las vulnerabilidades basándote en la severidad (CVSS) y la probabilidad de explotación (EPSS), utiliza el marco SSVC para determinar la acción operativa adecuada. El árbol de decisiones del SSVC te ayudará a decidir si necesitas parchear inmediatamente, monitorear o aceptar el riesgo, basándote en el contexto de tu organización (por ejemplo, la criticidad del sistema afectado).

Esto permite pasar de un enfoque reactivo basado en la gravedad a un enfoque proactivo y basado en el riesgo real, optimizando el uso de recursos y tiempo.

Conclusión

La priorización de vulnerabilidades es hoy una necesidad operativa: como los recursos de remediación son limitados y las amenazas evolucionan de forma dinámica, el problema central no es únicamente detectar debilidades, sino decidir cuáles atender primero. A lo largo de estos posts se analizaron cuatro instrumentos complementarios —CVSS, SSVC, EPSS, y KEV— que, utilizados en conjunto, permiten pasar de un enfoque reactivo a uno proactivo, fundamentado en el riesgo real.

Cada marco responde a una pregunta distinta y aporta una capa de información diferente:

• CVSS mide la severidad técnica de una vulnerabilidad —qué tan grave sería su explotación—. Es un punto de partida estandarizado, pero por sí solo resulta insuficiente, ya que no contempla ni la probabilidad de explotación ni el contexto del activo afectado.
• EPSS complementa a CVSS incorporando una estimación probabilística, basada en datos y modelos, de que una vulnerabilidad sea explotada en el corto plazo. Ayuda a distinguir lo grave de lo verdaderamente urgente.
• SSVC traslada la evaluación a una decisión operativa: mediante árboles de decisión que consideran el estado de explotación, el impacto en la misión y la exposición, orienta la acción concreta a tomar según la criticidad de cada activo.
• KEV, el catálogo de CISA, funciona como una señal binaria de máxima prioridad: si una vulnerabilidad figura en él, existe evidencia confirmada de explotación activa y debe remediarse de inmediato.

En la práctica, estos marcos no compiten entre sí, sino que se encadenan. KEV actúa como filtro de arranque —lo que ya está siendo explotado se atiende primero—; CVSS establece la severidad técnica de base; EPSS pondera la probabilidad de explotación para ordenar aquello que aún no es crítico pero podría llegar a serlo; y SSVC integra estas señales en una decisión accionable acorde con la criticidad del activo. El crecimiento sostenido del catálogo KEV, que superó las 1.480 vulnerabilidades hacia fines de 2025, confirma que la explotación activa es un fenómeno constante y que la priorización basada en evidencia dejó de ser opcional.

En definitiva, ningún indicador aislado ofrece una respuesta completa. La combinación de severidad (CVSS), probabilidad (EPSS), explotación confirmada (KEV) y contexto de decisión (SSVC) permite asignar los recursos limitados de remediación allí donde el riesgo es mayor, mejorando la eficiencia del proceso y la resiliencia de la organización frente a un panorama de amenazas en permanente cambio.

Leer Priorización y gestión de vulnerabilidades: CVSS, SSVC, EPSS y KEV

Seguir leyendo...

Vulnerabilidad crítica de NGINX

F5 ha publicado correcciones para una vulnerabilidad crítica de NGINX que permite a un atacante remoto no autenticado provocar un desbordamiento de búfer en el montón del proceso de trabajo mediante solicitudes HTTP manipuladas. La vulnerabilidad CVE-2026-42533 se corrigió el 15 de julio en NGINX 1.30.4 (estable) y 1.31.3 (principal), y en NGINX Plus 37.0.3.1; se recomienda actualizar a las versiones anteriores.

Activar esta vulnerabilidad puede provocar el bloqueo o el reinicio del proceso de trabajo, causando una denegación de servicio. F5 advierte que, si ASLR está deshabilitado o se puede eludir, también podría permitir la ejecución remota de código.

El desbordamiento reside en el motor de scripts de nginx, el código que ensambla cadenas a partir de directivas en el momento de la solicitud. Solo se manifiesta bajo una configuración específica: un mapa basado en expresiones regulares cuya variable de salida se referencia en una expresión de cadena después de una captura de una coincidencia de expresión regular anterior.

Esto no afecta a todos los servidores nginx; la vulnerabilidad depende de la configuración, no solo de la versión. El aviso de F5 indica que la vulnerabilidad afecta a NGINX Ingress Controller, Gateway Fabric, App Protect WAF e Instance Manager, además del servidor principal y NGINX Plus. Sin embargo, al momento de la publicación, F5 no había publicado versiones corregidas para estos cuatro productos.

F5 le otorga una puntuación de 9.2 en CVSS v4 y de 8.1 en la escala anterior v3.1, y la complejidad del ataque es alta. Todas las versiones de nginx desde la 0.9.6 hasta la 1.31.2 son vulnerables, un rango que se remonta a 2011, cuando la función map incorporó soporte para expresiones regulares.

Más de una docena de investigadores informaron a F5 de forma independiente sobre la vulnerabilidad CVE-2026-42533; el proveedor les agradeció por "haber llamado nuestra atención sobre este problema de forma independiente". El registro de cambios de nginx atribuye la corrección a Mufeed VH de Winfunc Research y al mantenedor Maxim Dounin.

Uno de los reporteros, Stan Shaw, que publica bajo el seudónimo de cyberstan, publicó un informe detallado que va más allá del aviso. F5 condiciona la ejecución del código a que ASLR esté deshabilitado o sea eludible, y el argumento de Shaw es que la vulnerabilidad proporciona la propia elusión. La manipulación de la captura también funciona a la inversa: cuando la captura manipulada es más pequeña que la original, el búfer sobredimensionado devuelve datos de montón no inicializados, y en una compilación predeterminada de Ubuntu 24.04, una sola solicitud GET no autenticada recupera las direcciones que necesita una carga útil.

"Un lector del aviso de F5 podría concluir razonablemente que se trata de un ataque DoS exclusivo de sistemas predeterminados. Pero no es así", afirmó Shaw. Su afirmación es más contundente que la de F5, y según él, obtuvo una puntuación perfecta en sus propias pruebas. Por el momento, no proporciona detalles sobre la explotación ni una prueba de concepto, para que nadie pueda verificarla de forma independiente.

La solución consiste en actualizar a nginx 1.30.4 o 1.31.3, o a NGINX Plus 37.0.3.1. Para quienes no puedan aplicar el parche de inmediato, la solución temporal de F5 consiste en cambiar los mapas de expresiones regulares afectados por capturas con nombre, lo que, según Shaw, cierra la ruta principal y cubre la mayoría de las configuraciones.

Sin embargo, esta solución deja abierta una ruta más estrecha: un mapa que define el mismo grupo con nombre que la expresión regular de ubicación alcanza el mismo desbordamiento a través de una segunda ruta de código, algo que confirmó con AddressSanitizer y que el aviso de F5 no menciona. "Actualizar a la versión 1.30.4 / 1.31.3 es la única solución completa", afirmó.

Las automatizaciones del escáner de Shaw revisan la configuración, siguen las inclusiones y marcan solo el orden vulnerable; no explotan nada, pero como herramienta del reportero, no es un producto del proveedor.

Este es el tercer desbordamiento de búfer en el código de evaluación de expresiones de nginx que se revela en aproximadamente dos meses, después de Rift (CVE-2026-42945) en mayo y un error de capturas superpuestas en el módulo de reescritura (CVE-2026-9256) días después.

Las tres vulnerabilidades pertenecen al mismo tipo: el motor de scripts de dos pasadas de nginx dimensiona un búfer en una pasada y escribe en él en la siguiente, y en cada ocasión la escritura excede el tamaño medido. El desencadenante difiere: una bandera obsoleta en Rift, capturas superpuestas en el error de reescritura, estado de captura modificado en este caso. La debilidad común, como señala el investigador, es un diseño de dos pasadas que confía en su propia medición.

Al 20 de julio, la vulnerabilidad aún no ha aparecido ningún código de explotación público. Shaw afirma que publicará su propia prueba de concepto 21 días después del parche, y Rift sirve de advertencia: su exploit se hizo público en cuestión de días y pronto fue objeto de explotación activa. Por eso es importante actualizar antes de que llegue esta vulnerabilidad.

Fuente: THN

Seguir leyendo...

Hugging Face confirma ataque y brecha ejecutado por agentes autónomos

Hugging Face reveló que detectó y contuvo una intrusión en su infraestructura de producción, impulsada de principio a fin por un sistema de agentes de IA autónomos, y se defendió de ella utilizando su propio análisis forense basado en IA.

Los atacantes explotaron dos fallos de ejecución de código en el flujo de procesamiento de conjuntos de datos de Hugging Face: un cargador de conjuntos de datos de código remoto y una vulnerabilidad de inyección de plantillas en la configuración del conjunto de datos.

Actualización: OpenAI admitió que el ataque de la semana pasada a Hugging Face, calificado como "el primer caso histórico de una invasión autónoma de IA", fue perpetrado por uno de sus propios modelos.

Una vez dentro de un trabajador de procesamiento, el actor escaló el acceso al nivel de nodo, recolectó credenciales de la nube y del clúster, y se movió lateralmente a través de varios clústeres internos durante un solo fin de semana.

El acceso no autorizado afectó a un conjunto limitado de conjuntos de datos internos y credenciales de servicio, aunque Hugging Face no encontró pruebas de que los modelos públicos, los conjuntos de datos, los Spaces o su cadena de suministro de software fueran manipulados.

Este incidente refleja una tendencia más amplia en la industria. La firma de seguridad Sysdig recientemente reveló lo que llama JADEPUFFER, descrito como la primera operación de ransomware totalmente autónoma impulsada por IA, donde un agente de IA se infiltró independientemente en un servidor expuesto a Internet, se movió lateralmente, cifró archivos y emitió una demanda de rescate sin ninguna intervención humana.

Por separado, el Informe Anual de Seguridad de IA 2026 de Check Point documenta intrusiones en vivo dirigidas cada vez más por IA, reduciendo la ventana entre la divulgación de la vulnerabilidad y su explotación de días a horas.

Lo que hizo que esta campaña fuera distinta fue la escala y la autonomía: la intrusión ejecutó miles de acciones individuales a través de un enjambre de sandboxes de corta duración, utilizando una infraestructura de comando y control automigratoria alojada en servicios públicos, coincidiendo con el escenario de "atacante agente" previsto hace tiempo.

El propio flujo de detección de anomalías de Hugging Face, que utiliza un triaje basado en LLM sobre telemetría de seguridad, señaló primero el compromiso al correlacionar señales que, de otro modo, se habrían perdido en el ruido diario.

Para reconstruir la línea de tiempo completa del ataque a partir de más de 17.000 acciones registradas del atacante, Hugging Face ejecutó agentes de análisis impulsados por LLM sobre todo el registro, comprimiendo lo que normalmente toma días en cuestión de horas.

Un hallazgo crítico de la investigación: las APIs de modelos comerciales de vanguardia se negaron a procesar el análisis forense porque sus barreras de seguridad no podían distinguir a un respondedor de incidentes que enviaba cargas útiles de exploits reales y artefactos de C2 de un atacante real.

Hugging Face cambió a GLM-5.2, un modelo de pesos abiertos ejecutado en su propia infraestructura, lo que también aseguró que ningún dato del atacante ni credenciales referenciadas abandonaran su entorno.

Esto expone una asimetría cruda: los atacantes que utilizan modelos con "jailbreak" o sin restricciones no enfrentan tales límites de política, mientras que los defensores que utilizan modelos comerciales alojados pueden quedar bloqueados a mitad de un incidente.

Hugging Face te aconseja rotar tus tokens de acceso y revisar la actividad reciente de tu cuenta como precaución.

El impulso de la industria refleja que las herramientas ofensivas de IA autónoma han pasado de la teoría a la práctica; el Centro Nacional de Ciberseguridad del Reino Unido ya ha lanzado una iniciativa de "Escudo Cibernético" para desplegar defensa impulsada por IA a escala nacional en respuesta.

La lección fundamental que surge de este incidente: las organizaciones necesitan un modelo de IA capaz y alojado localmente, evaluado y listo antes de que ocurra un incidente, tanto para evitar el bloqueo de las barreras de seguridad durante el trabajo forense como para evitar que los datos sensibles del ataque salgan de su entorno.

Como señaló Hugging Face, la superficie de datos y modelos debe tratarse ahora como un vector de ataque de primera clase, requiriendo una defensa impulsada por IA para hacer frente a la ofensiva impulsada por IA a velocidad de máquina.

Fuentes: CyberSecurityNews

Seguir leyendo...

Vulnerabilidad crítica en WordPress permite ejecutar código a atacantes anónimos

WordPress 6.8.6 6.9.5 y 7.0.2 corrigen wp2shell, una vulnerabilidad de ejecución remota de código (RCE) en el núcleo que permite a atacantes anónimos ejecutar código en instalaciones predeterminadas, incluso sin plugins.

Una solicitud HTTP anónima puede ejecutar código en un sitio de WordPress. El fallo reside en el núcleo, por lo que una instalación básica sin plugins es vulnerable.

Todos los sitios con las versiones 6.9 y 7.0 estaban expuestos hasta el viernes. WordPress lanzó las versiones 6.9.5 y 7.0.2 el 17 de julio de 2026, solucionando una vulnerabilidad de ejecución remota de código (RCE) previa a la autenticación en el núcleo que una solicitud anónima podía activar en una instalación predeterminada sin plugins. Dos rangos de versiones se ven afectados:

• 6.8.0 a 6.8.5: Solo inyección SQL, corregido en 6.8.6
• 6.9.0 a 6.9.4: Cadena RCE completa, corregido en 6.9.5
• 7.0.0 a 7.0.1: Cadena RCE completa, corregido en 7.0.2

Adam Kues, de Assetnote, la división de gestión de la superficie de ataque de Searchlight Cyber, descubrió la vulnerabilidad y la reportó a través del programa HackerOne de WordPress. El informe técnico, publicado bajo el nombre de wp2shell, indica que el ataque "no requiere condiciones previas y puede ser explotado por un usuario anónimo".

La empresa aún no ha revelado los detalles técnicos y ha habilitado una herramienta de análisis en wp2shell.com para que los propietarios puedan probar sus propias instancias. También hay un script de nuclei.

WordPress no ha confirmado si la actualización forzada llega a los sitios que desactivaron las actualizaciones automáticas. Verifique la versión que está utilizando en lugar de asumir que la actualización se instaló.

La versión 7.1 beta2 incluye la misma corrección. Los sitios que aún usan la versión 6.8 también tienen una actualización pendiente, pero la versión 6.8.6 corrige el segundo error de inyección SQL de la misma ronda, reportado por otro equipo.

La publicación de Searchlight estima que más de 500 millones de sitios web usan WordPress. Esta cifra corresponde a la base total de instalaciones, no a la población vulnerable: el código defectuoso solo existe a partir de la versión 6.9, que se lanzó el 2 de diciembre de 2025. Por lo tanto, todos los sitios afectados usan una versión con menos de ocho meses de antigüedad, y ninguno de los avisos especifica cuántos sitios se ven afectados.

WordPress es más transparente sobre la clasificación del error que el propio investigador. En su publicación, describe el hallazgo de Kues como "una confusión en el enrutamiento por lotes de la API REST y un problema de inyección SQL que conduce a la ejecución remota de código". La publicación cubre un fallo crítico y otro de alta gravedad, y WordPress no especifica cuál es cuál.

La página de la versión enumera los tres archivos afectados por la versión 7.0.2, que incluyen ambas correcciones: /wp-includes/rest-api/class-wp-rest-server.php, /wp-includes/class-wp-query.php y /wp-includes/rest-api.php. El endpoint de procesamiento por lotes no es nuevo. WordPress lo incluye desde la versión 5.6 (noviembre de 2020) y ha documentado públicamente el formato de la solicitud desde entonces. Hasta el momento, no se ha publicado ninguna explicación sobre qué cambió en la versión 6.9 para que se hiciera público.

wp2shell consta de dos vulnerabilidades, no de una, y ambas cuentan ahora con identificadores CVE. CVE-2026-63030 se refiere a la confusión en el enrutamiento por lotes de la API REST; CVE-2026-60137 es una vulnerabilidad de inyección SQL en el núcleo de WordPress. Encadenadas, permiten que una solicitud anónima se ejecute directamente.

Mitigación

Todas las medidas de mitigación que ofrece Searchlight se basan en impedir que usuarios anónimos accedan al endpoint de procesamiento por lotes. Hay tres opciones, todas provisionales hasta que actualice, y todas pueden interrumpir integraciones legítimas:

• En el WAF, bloquee tanto /wp-json/batch/v1 como rest_route=/batch/v1. La empresa insiste en que ambos deben bloquearse, ya que una regla que solo cubra la ruta /wp-json deja abierta la ruta de la cadena de consulta.
• Desactive la API REST de WordPress, lo que bloquea completamente el acceso REST no autenticado.
• Un plugin sencillo que publica y rechaza las solicitudes anónimas de /batch/v1 en rest_pre_dispatch. Hasta el 18 de julio no se había reportado ningún intento de explotación. Sin una CVE que etiquetar ni una firma pública que la coincida, nadie está investigando realmente.

La explotación masiva de WordPress se ha convertido en una industria. Antes de que su servidor se filtrara en junio, una sola vulnerabilidad en un plugin de caché permitió al grupo WP-SHELLSTORM acceder a más de 17.000 sitios, según sus propios cálculos. Ese fallo ya era público, ya había sido parcheado y solo funcionaba con una configuración no predeterminada.

El núcleo de WordPress es de código abierto, y tanto la versión 7.0.1 como la 7.0.2 se encuentran en el archivo de versiones públicas, por lo que la comparación está disponible para quien la desee. Este es el dilema de todo proyecto de código abierto: no se puede publicar la solución sin publicar el mapa del error, y la única opción que queda es la rapidez con la que el parche llega a los sitios antes de que alguien lo lea.

WordPress activó esa opción el viernes. El tráfico contra batch/v1 mostrará cuándo llegan los atacantes, y las estadísticas de versiones de WordPress mostrarán si el parche llegó primero. Solo una de esas cifras suele aparecer en las noticias.

Fuente: THN

Seguir leyendo...

Priorización y gestión de vulnerabilidades: CVSS, SSVC, EPSS y KEV (3 de...)

Leer Priorización y gestión de vulnerabilidades: CVSS, SSVC, EPSS y KEV

EPSS - Sistema de Puntuación de Predicción de Exploits

El Sistema de Puntuación de Predicción de Exploits (Exploit Prediction Scoring System - EPSS) es una iniciativa basada en datos para estimar la probabilidad de que una vulnerabilidad de software sea explotada en la práctica.

Su objetivo es ayudar a los defensores de la red a priorizar mejor las iniciativas de remediación de vulnerabilidades. Si bien otros estándares de la industria han sido útiles para capturar las características innatas de una vulnerabilidad y proporcionar medidas de gravedad, su capacidad para evaluar la amenaza es limitada.

EPSS cubre esta deficiencia, ya que utiliza información actualizada sobre amenazas de CVE y datos de exploits reales. El modelo EPSS genera una puntuación de probabilidad entre 0 y 1 (0 y 100%). Cuanto mayor sea la puntuación, mayor será la probabilidad de que una vulnerabilidad sea explotada.

¿Cómo funciona el EPSS?

El modelo del EPSS está entrenado para identificar correlaciones y patrones entre los datos de vulnerabilidades y la actividad de explotación observada y proporcionar una estimación diaria de la probabilidad de que se intente explotar una vulnerabilidad en los próximos 30 días.

Esta estimación se basa en un análisis exhaustivo de diversas fuentes de datos, como la lista CVE de MITRE, la National Vulnerability Database, Metasploit y ExploitDB, e informes de proveedores e investigadores, incluidos los socios de datos del EPSS. La información sobre la actividad de explotación, por ejemplo, puede recopilarse continuamente de fuentes como honeypots, sistemas de detección/prevención de intrusiones (IDS/IPS) y métodos de detección basados en hosts. Esta información básica se actualiza diariamente para cada CVE, lo que permite al sistema generar nuevas estimaciones de probabilidad más precisas.

La información sobre vulnerabilidades que utiliza el EPSS incluye detalles cruciales como el proveedor (además de la popularidad del producto afectado), el tiempo transcurrido desde su publicación, las referencias, las debilidades asociadas, las métricas CVSS (un proyecto gestionado también por FIRST), los debates y el código de explotación público (incluida, por ejemplo, la fecha de su incorporación a Metasploit) y la facilidad para obtenerlo.

El rendimiento del sistema se evalúa repetidamente y se realizan ajustes en los parámetros o en los valores de las variables para maximizar su capacidad de predicción y garantizar su precisión y eficacia.

Para evaluar su poder predictivo, el EPSS se entrena con 12 meses de datos históricos. A continuación, para simular la predicción del futuro, el modelo se pone a prueba en relación con los dos meses inmediatamente posteriores a ese periodo de entrenamiento (también datos históricos). Como el modelo no ha visto estos datos "futuros", los investigadores pueden ver con qué precisión anticipa la actividad de explotación en el "mundo real". Este proceso les permite probar diferentes versiones del modelo y fuentes de datos, garantizando que las predicciones del EPSS sean lo más fiables posible.

Además de proporcionar probabilidades de que se exploten vulnerabilidades específicas, el EPSS también ofrece clasificaciones por percentiles. Los percentiles permiten ordenar las probabilidades y comunicar su importancia relativa. Como Romanosky y Jacobs afirman en un post para FIRST, el percentil es la proporción de todos los valores menores o iguales al rango actual. Por lo tanto, por ejemplo, si una vulnerabilidad con una puntuación EPSS de 0,15 (o 15%) está en el percentil 89, esto significa que el 89% de todos los CVEs puntuados tienen una puntuación EPSS igual o inferior a 0,15 (o que esta vulnerabilidad está en el 11% superior).

Así pues, aunque una probabilidad del 15% puede no parecer excepcionalmente alta de forma aislada, la clasificación por percentiles revela que, en relación con todas las demás vulnerabilidades puntuadas globalmente, se encuentra entre las que tienen las puntuaciones más altas. Esto proporciona una perspectiva diferente a la que se obtiene simplemente observando la probabilidad del 15% por sí sola, lo que ayuda aún más en el proceso de priorización.

Diferencias y correlación entre EPSS y CVSS

Tanto EPSS como el Common Vulnerability Scoring System (CVSS) son valiosas herramientas de acceso público para priorizar la remediación de vulnerabilidades. Estas métricas, desarrolladas y mantenidas gracias a los esfuerzos de colaboración de individuos que van desde investigadores hasta personal gubernamental, proporcionan información crucial sin costo alguno. Sin embargo, su enfoque difiere significativamente: El CVSS cuantifica principalmente la severidad de una vulnerabilidad basándose en sus propiedades intrínsecas, mientras que el EPSS estima la probabilidad de que sea explotada por los atacantes maliciosos, proporcionando así una medida más cercana al panorama de amenazas.

CVSS hace hincapié en las características fundamentales y relativamente estáticas de las vulnerabilidades, como la complejidad del ataque, la disponibilidad del exploit y el impacto potencial. Aunque CVSS incorpora factores temporales y ambientales en su puntuación global, las organizaciones suelen confiar únicamente en la "puntuación Base" debido a las dificultades para evaluar con precisión estas variables dinámicas. Sin embargo, esta puntuación base puede no reflejar plenamente los riesgos reales.

Por el contrario, el EPSS, aunque valioso, tiene sus propias limitaciones. No tiene en cuenta los factores ambientales, los controles de seguridad específicos ni el impacto potencial en los activos exclusivos de una organización. Como subraya FIRST, el EPSS nunca debe tratarse como una puntuación de riesgo. Además, sus resultados dependen de la exactitud e integridad de las fuentes de datos subyacentes y, por supuesto, proporciona una estimación probabilística, no una garantía de (no) explotación. Por último, funciona exclusivamente con vulnerabilidades a las que se han asignado identificadores CVE públicos.

Aunque tanto el EPSS como el CVSS pueden contribuir por separado a la gestión de vulnerabilidades, se utilizan mejor como métricas complementarias. La combinación de la información de ambos puede mejorar significativamente la priorización de vulnerabilidades. 

Desempeño del modelo EPSS

Para evaluar el rendimiento del modelo EPSS a la hora de contribuir a la priorización de vulnerabilidades, los investigadores emplean varias métricas de análisis clave. Las primeras métricas categorizan las vulnerabilidades en función de su priorización y estado de explotación utilizando las siguientes definiciones:

• Verdaderos positivos (TP): Vulnerabilidades priorizadas "correctamente" porque fueron explotadas.
• Falsos positivos (FP): Vulnerabilidades priorizadas "incorrectamente" porque no fueron explotadas.
• Falsos negativos (FN): Vulnerabilidades "incorrectamente" retrasadas (no priorizadas) porque fueron explotadas.
• Verdaderos negativos (TN): Vulnerabilidades "correctamente" retrasadas (no priorizadas) porque no fueron explotadas.

A partir de estas categorías, se determinan tres métricas cruciales: esfuerzo, eficiencia y cobertura (las dos últimas son análogas a la precisión y la recuperación, respectivamente, en los F-scores).

El esfuerzo mide la proporción de vulnerabilidades priorizadas. La eficiencia evalúa qué tan bien se utilizaron los recursos midiendo el porcentaje de vulnerabilidades priorizadas que fueron realmente explotadas. Esto se calcula como:

Eficiencia = TP / (TP + FP)

Por ejemplo, podrías tener una eficiencia del 100% si todas tus vulnerabilidades priorizadas estuvieran dentro del conjunto de vulnerabilidades explotadas.

La cobertura considera el porcentaje de vulnerabilidades explotadas a las que se dio prioridad. Esto se calcula como:

Cobertura = TP / (TP + FN)

Siguiendo el ejemplo anterior con una eficiencia del 100%, si el conjunto de vulnerabilidades explotadas fuera mucho mayor que el conjunto de vulnerabilidades priorizadas, la cobertura sería baja. Lo ideal sería que ambos conjuntos tuvieran un solapamiento exacto.

Una mayor cobertura implica un mayor esfuerzo y suele traducirse en una menor eficiencia. Mejorar la eficiencia disminuiría el esfuerzo, pero suele representar una menor cobertura. El objetivo siempre es encontrar una estrategia de priorización mejorada.

Leer Priorización y gestión de vulnerabilidades: CVSS, SSVC, EPSS y KEV

Seguir leyendo...

Suplantación de ID de cliente de OAuth

Al menos dos grupos de ciberdelincuentes están utilizando una novedosa técnica de evasión llamada suplantación de ID de cliente OAuth en campañas en la nube, eludiendo la telemetría.

Esta actividad permite a los usuarios enumerar cuentas de usuario y validar credenciales robadas en entornos Microsoft Entra ID, sin generar un inicio de sesión exitoso que alertaría a los sistemas de seguridad. Los ciberdelincuentes han comenzado a explotar esta vulnerabilidad para obtener acceso no autorizado a los servicios en la nube de las organizaciones.

"Un punto ciego en la telemetría de inicio de sesión en la nube: Entra ID devuelve diferentes respuestas de error según la validez del ID de cliente OAuth proporcionado", declaró Proofpoint. "Los atacantes aprovechan esto para inferir nombres de usuario y contraseñas válidas a gran escala, comprobando así listas de credenciales robadas sin registrar un inicio de sesión exitoso".

En otras palabras, los ataques utilizan el ID de cliente OAuth, un identificador único global (GUID) asignado a las aplicaciones al solicitar acceso a los datos de usuario, que se transmite como "client_id" en las solicitudes de autenticación. Al proporcionar identificadores de cliente falsificados, permite la enumeración de cuentas sin una aplicación OAuth registrada y permite a los atacantes inferir la validez de la contraseña y la cuenta sin generar un inicio de sesión exitoso.

"Los registros de inicio de sesión de Entra son una fuente principal de telemetría para identificar actividades de autenticación maliciosas, incluyendo la enumeración de usuarios, el ataque de fuerza bruta contra contraseñas y los intentos de acceso iniciales", afirmó Rachel Rabin, investigadora de Proofpoint.

Se ha observado que grupos de amenazas como UNK_CustomCloak falsifican cadenas de agente de usuario para orquestar campañas de fuerza bruta dirigidas a entornos de Microsoft Entra ID, explotando una aplicación obsoleta de Microsoft llamada Windows Live Custom Domains para eludir las restricciones de inicio de sesión estándar y sondear las contraseñas de los usuarios en más de 4.000 inquilinos.

Sin embargo, los últimos esfuerzos representan una evolución de esta técnica al falsificar los identificadores de cliente de OAuth mediante solicitudes HTTP POST al punto final de token OAuth 2.0 de Microsoft utilizando el flujo de Credenciales de Contraseña del Propietario del Recurso (ROPC). En concreto, esto implica proporcionar un ID de cliente sintácticamente válido, pero que no corresponde a una aplicación real.

En estos casos, solo se registra el ID de la aplicación en el registro de inicio de sesión de Entra, sin el nombre de la aplicación correspondiente. La respuesta, que contiene un código de error del Servicio de tokens de seguridad de Azure Active Directory (AADSTS), puede utilizarse para deducir si la cuenta existe y si la contraseña es correcta, incluso sin una aplicación registrada.

"Si el ID de cliente falsificado no es un UUIDv4 válido, Entra no rechaza la solicitud directamente", explicó Proofpoint. "Por lo tanto, los atacantes pueden analizar esta respuesta de error para identificar cuentas y contraseñas válidas, a pesar de utilizar ID de cliente mal formados. Cuando se utiliza un ID de cliente falsificado, no se registra el nombre de la aplicación correspondiente en el registro de inicio de sesión. Esto significa que las detecciones que buscan picos de actividad asociados a un nombre de aplicación específico pueden pasar por alto esta actividad por completo, ya que el campo aparece en blanco".

Con esta información, los atacantes podrían identificar cuentas susceptibles de ser explotadas para obtener acceso sigiloso, dificultando a los defensores la detección de actividades sospechosas.

Proofpoint ha identificado dos grandes campañas que adoptaron esta técnica de forma independiente a finales de diciembre de 2025, lo que indica que este método se está incorporando cada vez más a las tácticas de los atacantes, en lugar de ser un incidente aislado:

• UNK_pyreq2323 (de enero a marzo de 2026), que utilizó más de 700.000 ID de cliente falsificados de la infraestructura de Amazon Web Services (AWS) para atacar a más de un millón de cuentas en casi 4.000 clientes, provocando el bloqueo de aproximadamente el 28% de los usuarios afectados debido a intentos fallidos.
• UNK_OutFlareAZ (a partir de diciembre de 2025), que aprovechó la infraestructura de Cloudflare para atacar a más de dos millones de usuarios con 3,7 millones de ID de aplicación falsificados generados aleatoriamente. Se ha observado que ambas campañas utilizan UUID válidos en lugar de identificadores mal formados y demuestran patrones que coinciden con listas de nombres de usuario precompiladas. Sin embargo, mientras que UNK_OutFlareAZ enumeraba a los usuarios alfabéticamente, UNK_pyreq2323 no lo hacía. Otra diferencia radicaba en cómo se falsificaban los ID de cliente.

Se dice que UNK_pyreq2323 modificaba los últimos dígitos de un ID de aplicación conocido y luego reutilizaba los ID falsificados para hasta 12 usuarios. En cambio, UNK_OutFlareAZ generaba un ID de cliente único por solicitud.

"Al fragmentar los intentos de autenticación en múltiples aplicaciones ficticias, la actividad se vuelve más difícil de correlacionar y puede eludir las detecciones y limitaciones de velocidad por aplicación. Las organizaciones pueden intentar mitigar los ataques de enumeración tradicionales aplicando políticas de acceso condicional (CA) dirigidas a las aplicaciones que suelen ser objetivo de la enumeración. Los ID de cliente falsificados no activarán las políticas CA dirigidas a una aplicación específica.

Fuente: THN

Seguir leyendo...

Estudio de 85 extensiones de billeteras de criptomonedas detecta filtraciones

Investigadores de la KU Leuven probaron 85 de las billeteras de criptomonedas más populares que funcionan como extensiones de navegador y descubrieron que las propias billeteras presentan fugas de información suficientes para vincular y rastrear a sus usuarios.

La forma en que estas billeteras se comunican con sitios web y servidores blockchain puede conectar las distintas direcciones de una persona y permitir que terceros la sigan de un sitio a otro. Incluso en un sitio que ya contiene un nombre o correo electrónico, estas mismas fugas pueden asociar un nombre real a una identidad criptográfica "anónima".

Esto no es un hackeo. Las billeteras funcionan exactamente como fueron diseñadas. Las 85 extensiones suman alrededor de 35 millones de usuarios registrados en la Chrome Web Store.

El equipo, perteneciente al grupo de seguridad DistriNet de la universidad, publicó el artículo este mes y lo presentará en la conferencia de privacidad PETS 2026 en Calgary a finales de julio. Realizaron pruebas con billeteras reales en sitios Web3 reales e identificaron cinco vulnerabilidades de privacidad en la interacción entre billeteras y sitios web. Cuando informaron a los fabricantes de monederos sobre el problema de mayor alcance antes de su publicación, la mayoría se negó a considerarlo un error.

Problema 1: Tus direcciones de monedero se vinculan

Muchas personas mantienen varias direcciones de monedero a propósito para mantener separadas partes de su vida financiera. Esto solo funciona si nadie puede saber que las direcciones pertenecen a la misma persona. Pero para mostrar tu saldo, un monedero envía constantemente solicitudes a servidores externos, y esas solicitudes transmiten tu dirección, sin cifrar, a quien administra el servidor.

Cuando un monedero incluye dos de tus direcciones en una sola solicitud, el servidor sabe que son tuyas. Diecisiete monederos expusieron conexiones entre las direcciones de monedero de un usuario. Trece lo hicieron de la forma obvia, agrupando dos direcciones en una sola solicitud. Cuatro más se delataron al enviar solicitudes separadas con milisegundos de diferencia, una señal más débil pero aún útil.

En conjunto, estos monederos abarcan aproximadamente 23 millones de las instalaciones estudiadas. Quien administra el servidor, o cualquiera que obtenga sus datos posteriormente, puede unir las direcciones en un solo perfil.

Problema 2: Cerrar sesión a menudo no cierra la sesión por completo.

Este problema y el siguiente comparten un punto de partida: un sitio web puede saber qué billeteras tienes instaladas. Cada billetera se identifica en cada página que carga, por lo que un script puede leer el conjunto exacto que llevas, una huella digital que funciona incluso si nunca conectas una billetera y aunque bloquees las cookies.

Los investigadores descubrieron que 36 de las 85 billeteras hacen esto, y sus usuarios representan aproximadamente el 82% de las instalaciones estudiadas. Esas mismas 36 billeteras son las responsables de las cifras que se muestran a continuación.

Cuando conectas una billetera a un sitio y luego te desconectas, asumes que el sitio pierde el acceso. A menudo no es así, por dos razones distintas.

Primero, muchos sitios nunca le indican a la billetera que corte el acceso. De las 30 aplicaciones Web3 populares que el equipo probó, solo 11 enviaron una orden de revocación real cuando un usuario hizo clic en Desconectar o Cerrar sesión. El resto simplemente borró su pantalla.

Segundo, incluso cuando se envía la orden, muchas billeteras la ignoran. En 22 de esas 36 carteras, el sitio aún podía leer tu dirección después de solicitar a la cartera que la revocara, y ese acceso se mantuvo incluso después de borrar las cookies y reiniciar el navegador.

Esto convierte la dirección en una potente etiqueta de seguimiento. Es única a nivel global y, a diferencia de una cookie, no desaparece al borrar el navegador. El permiso obsoleto permanece en la extensión hasta que se abre la lista de "Sitios conectados" de la billetera y se elimina el sitio manualmente; hasta entonces, un script en la página sigue leyendo la dirección en segundo plano.

Problema 3: Una billetera a la que te conectaste puede exponerte en otros sitios.

Este último problema tiene mayor alcance. De esas 36 billeteras, 23 compartirán tu dirección desde dentro de un marco que una página ha cargado desde otro sitio. Por sí solo, esto no tiene ninguna consecuencia. El problema radica en lo que un rastreador compartido puede hacer con ella.

Supongamos que el mismo script de seguimiento se ejecuta en una aplicación de criptomonedas a la que te conectaste y en un sitio web común y corriente. En el sitio común, el rastreador carga silenciosamente la aplicación de criptomonedas dentro de un marco invisible.

La página de la aplicación ya estaba autorizada por la billetera, y estas billeteras responden desde dentro del marco, por lo que la billetera devuelve la dirección al script sin que el usuario haga clic. La aplicación debe permitir la integración para que esto funcione, aunque muchas lo permiten.

Vincula esa dirección a un nombre o correo electrónico que el sitio ya tenga registrado, y un perfil criptográfico seudónimo se convierte en una persona identificada. La dirección de una billetera es un registro público de sus saldos, transacciones y tenencias de tokens. Si la vinculas a una identidad real y a un historial de navegación, un atacante tiene un objetivo identificado cuyo dinero ahora está a la vista.

Los investigadores demostraron que este método es real y utilizable; no afirmaron que los rastreadores ya lo estén utilizando a gran escala.

Qué hacer y cómo respondió la industria

Para los usuarios, las soluciones son solo parciales. Abre tu billetera y elimina los permisos de sitios antiguos que ya no uses. Esto detiene el rastreo de direcciones obsoletas del Problema 2, pero no soluciona las filtraciones de direcciones a los servidores ni la huella digital de la billetera instalada.

La demostración de los investigadores muestra cómo funciona tu propia billetera; se ejecuta en tu navegador y, según afirman, no almacena nada. Usa una billetera desechable para mayor seguridad. También ayuda mantener las diferentes actividades en carteras o perfiles de navegador separados. Las soluciones más importantes están fuera del alcance de los usuarios.

Los investigadores centraron su informe en el problema de vulnerabilidad entre sitios y notificaron a los fabricantes de carteras afectadas antes de su publicación. Para una nueva prueba en febrero de 2026, Coinbase Wallet y Coin98 ya lo habían solucionado, y Hana Wallet lo hizo posteriormente. Sin embargo, de los ocho proveedores que, según el informe, respondieron a través de sus programas de recompensas por errores, la mayoría se negó a considerarlo un error.

MetaMask lo calificó como un problema conocido, cerró el informe como duplicado y afirmó que no tenía planes inmediatos de dejar de inyectar malware en su proveedor, ya que esto afectaría a demasiadas aplicaciones.

Rabby afirmó que el ataque requeriría que el mismo script malicioso se ejecutara en dos sitios simultáneamente, lo cual calificó de "prácticamente imposible", y concluyó que "la vulnerabilidad no existe". OKX coincidió en que el hallazgo era técnicamente correcto, pero lo cerró como informativo porque expone datos sin robar dinero.

Bybit, Backpack y Core lo consideraron de bajo riesgo o fuera de su alcance. Las respuestas completas se publican en el repositorio de los investigadores.

El estudio se basa en la investigación de 2023 de Christof Ferreira Torres y sus colegas, quienes fueron los primeros en demostrar que las carteras digitales filtraban direcciones a servidores externos. Este trabajo detecta filtraciones que las herramientas anteriores no detectaron, mapea el rastreo entre sitios y muestra cómo la misma filtración podría usarse para revelar la identidad de los usuarios.

Mientras que escáneres como WalletRadar y WalletProbe buscan errores evidentes, este artículo demuestra que una cartera digital no necesita un error para exponer a un usuario. Esto la diferencia de las extensiones de cartera falsas que robaron claves el año pasado. En esos casos, los delincuentes robaron. Aquí, no se roba nada, y la filtración está integrada en el diseño.

El artículo se publicó en arXiv el 7 de julio y se presentará en PETS 2026 en Calgary, del 20 al 25 de julio. Por ahora, las carteras funcionan según lo previsto, y varios de sus fabricantes han afirmado, en efecto, que el diseño es correcto.

La solución real no es otra advertencia a los usuarios. Se trata de carteras que dejan de exponerse dentro de marcos integrados, y de un estándar del ecosistema que define qué debe hacer realmente el cierre de sesión.

Fuente: THN

Seguir leyendo...