La semana pasada, un investigador de seguridad reveló un caso impactante: en una actualización de una wallet el 24 de diciembre, se incrustó un código backdoor que provocó la filtración de datos privados de los usuarios (incluyendo las frases mnemónicas), afectando a más de 2 millones de dólares en pérdidas.

Este incidente, a primera vista, parece novedoso, pero tras pensarlo bien, en realidad refleja un problema antiguo de las wallets de una generación—los usuarios no tienen control real sobre los límites de seguridad.

**Cuál es el verdadero riesgo de las wallets plugin**

Muchas personas, al discutir este tipo de incidentes, tienden a culpar a los usuarios: "¿Importaron la frase mnemónica? ¿Hicieron un操作 descuidado?" Pero desde el punto de vista del diseño del producto, el problema no está allí. El riesgo clave reside en el mecanismo de actualización automática en sí.

Las wallets plugin tienen una realidad ineludible:

Cada actualización automática, en esencia, es una autorización completa sobre todos tus activos.

Mientras el código en el paquete de actualización no sea manipulado—puede ser un problema interno, pero más comúnmente, la cadena de suministro ha sido atacada (procesos CI/CD, entorno de construcción, canales de distribución comprometidos)—la lógica maliciosa se ejecutará sin que el usuario se dé cuenta. Y el usuario, en realidad, no lo detecta.

Lo que es aún más preocupante: este riesgo no solo amenaza a las wallets en caliente. Incluso si solo usas un plugin para conectar una wallet hardware, el riesgo sigue siendo válido. Porque lo que controla el plugin es:

- El contenido de las transacciones que ves
- La dirección de recepción que confirmas
- Toda la información mostrada antes y después de firmar

La wallet hardware puede garantizar que la "clave privada nunca abandona el chip", pero no puede garantizar que la transacción que firmas sea la que realmente crees. Si el plugin tiene malas intenciones, puede hacer que firmes una cosa, y en la cadena se ejecute otra diferente.

**Por qué esto se ha convertido en un problema sistémico**

La raíz del problema está en: los permisos de actualización centralizados. Una vez que el usuario instala un plugin, entrega toda la seguridad en manos del equipo de desarrollo. El equipo puede ser confiable, pero si alguna parte de su infraestructura, proceso de publicación o las computadoras de los empleados son comprometidas, puede resultar en una pérdida masiva de activos.

Y el usuario, en todo esto, está completamente pasivo—no puede ver qué se ha actualizado, ni rechazar una versión específica.

Por eso, toda la comunidad de Web3 está empezando a reevaluar el diseño arquitectónico de las wallets. Algunos proyectos están explorando mecanismos de actualización basados en separación de claves, verificables por el usuario, o incluso arquitecturas con prioridad local—con el objetivo de que los usuarios tengan un control real sobre la seguridad de sus activos, en lugar de confiar ciegamente.