La seguridad en el ecosistema cripto ha tenido unos días realmente difíciles. De hecho, se han vuelto a encender las alarmas tras la divulgación de una vulnerabilidad crítica en Electrum, una de las billeteras de escritorio para Bitcoin más antiguas y respetadas del mercado.
El fallo, catalogado bajo el registro de seguridad GHSA-6jp4-8v48-cc5v y corregido con urgencia en la versión 4.8.3, expone un riesgo inherente en la arquitectura de los clientes ligeros SPV (Simple Payment Verification o Verificación Simplificada de Pagos), por la confianza ciega en la información que proporcionan los servidores remotos sobre el estado de la mempool.
Vulnerability disclosure: https://t.co/EayMVF94V3
— Electrum (@ElectrumWallet) October 24, 2026
En un mensaje en la red social X, se señala: “Nueva versión: Electrum 4.8.3. Esta versión corrige un problema de seguridad crítico, por lo que instamos a todos los usuarios a actualizar. La descripción de la vulnerabilidad se publicará más tarde el día de hoy. (Nota: es posible que Windows Defender muestre una advertencia sobre ZXing.dll; ignórela, se trata de un falso positivo)”.
El hallazgo demuestra cómo un vector de ataque que combina la manipulación de datos del lado del servidor con el engaño psicológico hacia el usuario puede derivar en la pérdida definitiva de fondos, sin necesidad de comprometer las claves privadas ni romper la criptografía de la red.
Para comprender la magnitud de la falla, es necesario repasar la estructura operativa de Electrum. Creada en 2011, la billetera popularizó el uso de la Verificación de Pago Simplificada (SPV, por sus siglas en inglés).
En lugar de exigir a los usuarios que descarguen e indexen los cientos de gigabytes que componen la cadena de bloques de Bitcoin, Electrum se conecta a una red descentralizada de servidores externos que le sirven el historial de transacciones y los saldos en tiempo real.
Sin embargo, como aclara la propia documentación del proyecto, el cliente delega la confianza en el servidor al que se conecta cuando se trata de transacciones no confirmadas o presentes en la memoria temporal (mempool) y esa precisamente fue la brecha conceptual donde los atacantes encontraron la rendija para operar.
El vector explotado en la práctica opera en varios pasos coordinados de manera precisa, porque como primer paso efectúa la retención de la transacción legítima que ocurre cuando el usuario genera y transmite una nueva transacción (tx 1) para enviar bitcoins a un destino específico, el servidor malicioso al que está conectado intercepta el envío y evita propagarlo a la red P2P global de Bitcoin.
Concretamente, el engaño (Spoofing) hace que el servidor inyecte una transacción conflictiva en el historial local de la billetera, cambiando la dirección de destino por una controlada por el atacante (usando a menudo técnicas de plantado de direcciones similares en los últimos caracteres para confundir al usuario).
En esta parte del proceso, se realiza la inyección de una transacción manipulada, que ocurre luego que el servidor actualiza el historial local de la billetera del usuario mostrando una transacción alternativa (tx 2) en la cual la dirección de destino original es reemplazada por una dirección diferente.
Y como último paso, se usa el truco de las firmas inválidas y las vanity addresses. Aunque la tx 2 carece de firmas criptográficas válidas para gastar los fondos, las versiones antiguas de Electrum no verificaban la autenticidad de las firmas de entradas en transacciones no confirmadas antes de plasmarlas en la interfaz.
Para reducir las sospechas en una revisión visual rápida, los atacantes generaron direcciones maliciosas cuya terminación coincidía exactamente con los últimos cuatro caracteres del destinatario legítimo.
En consecuencia, una tx 2 con una comisión de red nula o extremadamente baja, provoca que la transacción apareciera “atascada” en la interfaz pero al intentar destrabar el envío utilizando la función nativa de reemplazo por comisión (Replace-by-Fee o RBF), la billetera tomaba la estructura de tx 2, le asignaba una comisión más alta y solicitaba la firma del usuario.
En ese instante preciso, el usuario autorizaba criptográficamente una transacción completamente nueva dirigida al atacante, consolidando la pérdida irreversible de los bitcoins involucrados en esa transacción.
De allí que el aviso oficial revela que los desarrolladores de Electrum recibieron las primeras señales de este problema el 11 de octubre de 2026, cuando un primer usuario notificó una disparidad inusual en su historial tras enviar un pago. Sin embargo, en esa fase inicial no se comprobó la ejecución del mecanismo de aumento de comisiones.
El escenario empeoró el 18 de octubre de 2026, cuando un segundo usuario informó la pérdida efectiva de sus fondos tras haber aplicado la función RBF sobre una transacción alterada por un servidor comprometido.
Evidentemente, que ante la gravedad del vector de ataque y la evidencia de servidores maliciosos activos en la red, el equipo de desarrollo encabezado por Thomas Voegtlin decidió actuar con rapidez por lo que el 23 de octubre de 2026 se etiquetó en el repositorio oficial el commit 90fe308, que incorpora la validación estricta de las firmas en la mempool.
Posteriormente, al día siguiente se liberó oficialmente la versión 4.8.3 de Electrum y se emitió el comunicado de seguridad público instando a la comunidad a actualizar sus clientes (sin demora) de manera que no se siguiera usando la versión anterior.
La actualización a la versión 4.8.3 introduce un cambio fundamental en el comportamiento del cliente porque a partir de ahora, la billetera ahora valida rigurosamente las firmas de las entradas pertenecientes al usuario (wallet.is_mine) en todas las transacciones de la mempool antes de permitir que se agreguen al historial local.
No obstante, los desarrolladores hicieron hincapié en las limitaciones inherentes al software. Dado que Electrum no es un nodo completo y carece de un motor de consenso integral, no puede validar de forma exhaustiva las entradas entrantes de terceros sin realizar una comprobación recursiva pesada.
Para la base de usuarios de Electrum —compuesta en su mayoría por maximalistas, operadores de nodos y usuarios avanzados de almacenamiento en frío—, el incidente deja lecciones operativas clave, como la actualización inmediata y la verificación de firmas y direcciones.
En la actualización obligatoria, todos los usuarios deben migrar a la versión 4.8.3 descargando los ejecutables únicamente desde el dominio oficial electrum.org y verificando la firma GPG del archivo.
En la verificación de firmas y direcciones, se introdujo como medida de precaución adicional, se recomienda contrastar manualmente el importe y la totalidad de los caracteres de la dirección de destino antes de autorizar cualquier firma, especialmente durante maniobras de ajuste de comisiones (RBF o CPFP).
No obstante, en lo que respecta a la conexión a nodos propios, los usuarios que conectan Electrum de forma exclusiva a sus propios nodos completos de Bitcoin, a través de software como Fulcrum o Electrs (abreviatura de Electrum Server en Rust) no se vieron ni se verán expuestos a este tipo de manipulación por parte de servidores de terceros.
De cara a sus usuarios, este vector de ataque es un recordatorio claro de que en los clientes ligeros SPV, la confianza en el servidor de la mempool siempre ha sido un punto ciego porque la combinación de manipulación de la interfaz local, comisiones en cero para inducir la acción del usuario (RBF baiting) y suplantación parcial de direcciones representa una ingeniería social técnica sumamente pulida.
De allí que, para mitigar este tipo de riesgos, la mejor práctica sigue siendo conectar las carteras a nodos propios (como Electrum Personal Server o Bitcoin Core) o verificar de forma rigurosa los scripts de salida antes de autorizar cualquier firma manual.
Es así como este incidente recalca que, en el paradigma del almacenamiento propio, la vigilancia técnica y la verificación de las fuentes siguen siendo la primera y más sólida línea de defensa.