Web3 en riesgo: las extensiones de monedero pueden vincular direcciones a identidades sin robar claves

Un equipo de la universidad KU Leuven ha mostrado algo que muchos usuarios de criptomonedas ya temían pero pocos habían podido documentar con números: las extensiones de monedero para navegador, diseñadas para facilitar el acceso a blockchains desde páginas web, revelan suficiente información como para vincular direcciones, seguir movimientos y, en última instancia, desanonimizar a las personas que las usan. El estudio, elaborado por el grupo DistriNet y publicado en arXiv antes de su presentación en la conferencia PETS 2026, pone en evidencia que no hace falta un exploit sofisticado ni un robo de claves para que la privacidad se pierda; basta con el comportamiento normal de muchas extensiones y la forma en que las aplicaciones Web3 interactúan con ellas. Más información sobre el grupo de investigación está disponible en la web de DistriNet: https://distrinet.cs.kuleuven.be/.

El trabajo probó 85 monederos populares en forma de extensión de navegador, que suman decenas de millones de instalaciones en plataformas como la Chrome Web Store, y trazó cinco vectores prácticos de filtración que permiten a un servidor remoto o a un tercero que capture su tráfico atar entre sí varias direcciones de un mismo usuario. Esos vectores incluyen desde el envío explícito de múltiples direcciones en una sola petición hasta señales temporales (peticiones separadas por milisegundos) que sirven para correlacionarlas, pasando por la capacidad de una página para detectar qué extensiones de monedero están instaladas sin que el usuario haya interactuado con ellas. El resultado: perfiles persistentes y globalmente únicos que sobreviven a borrados de cookies y reinicios del navegador si la extensión no revoca correctamente los permisos.

La más alarmante de las rutas descritas por los investigadores es la que aprovecha marcos incrustados (iframes) y scripts de seguimiento compartidos. Cuando un rastreador se ejecuta en varios sitios y uno de ellos ha sido previamente autorizado para leer una dirección, ese mismo script puede recargar la aplicación autorizada dentro de un iframe en otro sitio y recibir la dirección sin ninguna acción del usuario. Si el sitio “normal” ya tiene un nombre, correo o identificación de visitante, la combinación convierte una dirección cripto, que es pública por naturaleza, en un enlace directo entre patrimonio y identidad real. La comunidad que sigue la conferencia PETS puede consultar el programa en https://petsymposium.org/.

Más allá de las implicaciones de privacidad, hay consecuencias prácticas: conocer las direcciones asociadas a una persona permite ver todo su historial de transacciones, saldos y participaciones en tokens; esto facilita ataques selectivos de ingeniería social, extorsión o la construcción de perfiles económicos que muchos usuarios tratan de evitar con múltiples carteras. A diferencia de incidentes donde se roban claves, aquí no hay sustracción de activos, sino exposición consciente por diseño del software, y varios proveedores han defendido la elección de diseñar sus interfaces así por compatibilidad o por evitar romper la experiencia de desarrolladores de DApps.

¿Qué puede hacer un usuario hoy? Las mitigaciones son parciales pero prácticas: abrir la extensión y limpiar manualmente la lista de sitios conectados reduce el riesgo de que un permiso “stale” siga exponiendo una dirección; emplear carteras de usar y tirar (throwaway) para interacciones públicas; separar actividades en diferentes cuentas y, cuando sea posible, en perfiles de navegador distintos para evitar la correlación por huella de extensiones instaladas. También es aconsejable limitar las extensiones a las estrictamente necesarias, y desconfiar de aplicaciones que soliciten conexiones sin una razón clara. Estas acciones ayudan, pero No solucionan las fugas a servidores externos ni el fingerprinting de monederos instalados, que requieren cambios en el software y en los estándares.

Para desarrolladores de wallets y responsables de DApps hay pasos concretos y técnicos que el ecosistema debería adoptar: impedir que el proveedor de la extensión responda direcciones desde iframes a menos que exista una intención explícita y verificable del usuario; implementar y estandarizar una API de revocación que haga efectivo el “Desconectar” desde la interfaz de la dApp; minimizar telemetría y evitar empaquetar múltiples direcciones en una sola consulta hacia terceros. Estos son cambios que implican un coste de compatibilidad, pero sin ellos la promesa de “autonomía y privacidad” del ecosistema Web3 es débil.

La respuesta de varios fabricantes a la divulgación responsable fue variada: algunas correcciones ya se observaron en retests, pero otras compañías cerraron los informes como “informativos” o defendieron el diseño actual argumentando compatibilidad con aplicaciones existentes. Ese debate revela una tensión real entre interoperabilidad y privacidad; hasta que la industria acuerde estándares mínimos (por ejemplo, exigir consentimiento explícito y una revocación efectiva), la responsabilidad recae en los usuarios y en reguladores que quieran exigir prácticas más seguras. Mientras tanto, investigadores y auditores seguirán empujando a proveedores y plataformas a reevaluar lo que hoy aceptan como comportamiento normal.

En la práctica, hay poca solución milagrosa: combinar higiene digital (limpiar permisos, usar perfiles separados, carteras desechables) con presión sistémica (reclamaciones públicas, revisiones de código abierto, exigencia de garantías técnicas) es la vía más efectiva para reducir el riesgo. Los usuarios que manejan sumas significativas deberían además considerar soluciones fuera del navegador, como monederos hardware con interfaces limitadas, o servicios que minimicen la exposición de direcciones a terceros. La lección clave es que en Web3 la anonimidad no se logra sólo con claves y direcciones, sino con protocolos y productos que limiten explícitamente la señal que sale del cliente.