Cartera Electrum vulnerable antes de la versión 4.8.3: el próximo paso

Quien guarda bitcoin en Electrum debería revisar hoy el número de versión de su cartera. Toda versión anterior a la 4.8.3 arrastra un fallo con el que un servidor malicioso puede llevarte a firmar un pago a un atacante. Los desarrolladores lo cerraron el 23 de octubre de 2026 y lo hicieron público un día después. En su aviso de seguridad está la frase que distingue este caso de una vulnerabilidad teórica: algunos servidores ya están ejecutando este ataque.

El fallo está clasificado con gravedad alta y no lleva número CVE. Lo llamativo no es su técnica, sino su palanca: no captura tus claves ni rompe ningún cifrado. Espera a que aceleres una transacción atascada, uno de los gestos más habituales del día a día en bitcoin.

Qué corrige Electrum 4.8.3: se comprueban las firmas de tus propias entradas

Electrum es una cartera ligera, un llamado cliente ligero. El término describe una cartera que no mantiene una copia completa de la blockchain de Bitcoin, sino que pregunta a un servidor externo qué transacciones pertenecen a sus direcciones. Eso la hace rápida y ligera, y traslada parte de la confianza a ese servidor.

Justo ahí entraba el ataque. Hasta la versión 4.8.3, Electrum incorporaba al historial local las transacciones sin confirmar sin comprobar sus firmas. La corrección invierte el orden: antes de que una transacción sin confirmar pase al historial, la cartera comprueba las firmas de las entradas que le pertenecen. Una falsificación con firma inválida se detecta así antes de aparecer en el historial.

El aviso menciona una limitación por sí mismo: las entradas que no pertenecen a tu propia cartera siguen sin comprobarse. Los pagos entrantes desde direcciones ajenas, por tanto, siguen sin estar verificados por completo. Para la vía de ataque descrita basta la nueva comprobación, porque esa vía reutiliza necesariamente tus propias entradas.

Replace-by-fee: cuando subir la comisión se convierte en una segunda firma

Replace-by-fee, o RBF, es un procedimiento con el que sustituyes una transacción de bitcoin aún sin confirmar por otra nueva con una comisión más alta. Es una práctica estándar y razonable: quien calculó demasiado justo con el mempool lleno se queda atascado horas. Cómo funciona en la práctica está en nuestra guía sobre transacciones de bitcoin atascadas con RBF y CPFP.

El punto decisivo: subir la comisión no es técnicamente una corrección de la transacción antigua, sino una nueva que hay que firmar otra vez. En la ventana de envío eso parece un trámite. Acabas de comprobar la dirección del destinatario, solo quieres añadir comisión. Si firmas en ese momento una transacción que ha construido un atacante, firmas también su dirección de destinatario.

La vía de ataque: de la difusión suprimida al historial falsificado

El aviso de seguridad describe cinco pasos. Tu cartera envía una transacción, llamémosla tx1, al servidor. El servidor no la propaga, sino que la descarta. Después coloca una segunda transacción en tu historial, tx2. Esta usa las mismas entradas que tx1, pero envía casi todas las salidas a una dirección del atacante.

Las firmas de tx2 son inválidas, porque el atacante no tiene tus claves. Como la versión antigua de Electrum no las comprobaba, mostraba tx2 igualmente como sin confirmar. Tu propia tx1 faltaba en el historial, nunca había llegado a la red. Para ti eso parecía un pago que no sale adelante.

En uno de los casos notificados, el servidor había construido tx2 con una comisión de cero. No es un descuido, sino parte del cebo: una transacción sin comisión no se mueve nunca, y la reacción más inmediata es recurrir a la subida de comisión.

Por qué la falsificación se mostraba siquiera

Un nodo completo de Bitcoin habría descartado tx2 de inmediato, porque comprueba cada firma contra la blockchain. Una cartera ligera, por principio, no lo hace con todo lo que recibe. El ataque aprovechaba esa división del trabajo sin superar ninguna barrera criptográfica. No exigía al servidor ni una clave válida ni una firma rota, solo la certeza de que nadie vuelve a calcular.

Dos casos notificados, una pérdida: la cronología de la divulgación

Los desarrolladores citan dos avisos independientes. El 11 de octubre de 2026, un usuario relató que, tras enviar, en su historial figuraba otra transacción mientras la suya nunca llegó a la red de Bitcoin. La vía a través de la subida de comisión aún no se había identificado en ese momento. El 18 de octubre, un segundo usuario notificó una pérdida después de haber subido la comisión de la transacción ajena.

Cinco días más tarde, el 23 de octubre, se etiquetó la versión 4.8.3 con la corrección. El 24 de octubre siguieron los archivos ejecutables y la divulgación pública. Los desarrolladores no indican el importe de la pérdida y no mencionan ninguna cifra de usuarios afectados más allá de esos dos avisos. Quien lea otra cosa lee una estimación.

Como fuente primaria sirve la portada de electrum.org, que presenta la 4.8.3 como versión actual, junto con las notas de versión. La descripción técnica está en el aviso de seguridad GHSA-6jp4-8v48-cc5v.

Direcciones pulidas hasta cuatro caracteres: el engaño en la ventana de envío

Ambos avisos comparten un detalle que explica por qué una revisión visual rápida no bastó. Los atacantes habían generado su dirección de destinatario hasta que sus últimos cuatro caracteres coincidían con los de la dirección de destino real. Ese procedimiento se llama vanity grinding: se prueban pares de claves hasta que la dirección correspondiente lleva el patrón deseado.

Cuatro caracteres coincidentes al final son baratos de generar y dan justo en el punto que muchos usuarios miran. Quien comprueba una dirección de bitcoin en la práctica rara vez revisa todos los caracteres, sino el principio y el final. Esa costumbre era precisamente el objetivo.

Quién no estuvo afectado: el servidor propio y el papel de la cartera de hardware

Un grupo quedó fuera. Quien conecta su cartera Electrum con un servidor propio o de confianza por otras razones no estuvo expuesto al ataque, porque sin servidor malicioso falta el primer paso. En su configuración por defecto, Electrum se conecta a servidores públicos que puede operar cualquiera, y ese es el caso normal con esta cartera.

Una cartera de hardware ayuda aquí solo de forma limitada, y merece la pena conocer la diferencia. Protege la clave privada frente al ordenador, no frente a una dirección de destinatario equivocada en la ventana de envío. Si tu dispositivo muestra dirección e importe en su propia pantalla y los comparas ahí, intercepta el engaño. Si te fías de lo que muestra el ordenador, la cartera de hardware firma igualmente la transacción manipulada. Qué dispositivos muestran dirección e importe en una pantalla propia está en nuestra comparativa de carteras de hardware.

Autocustodia en Europa: la responsabilidad se queda en el tenedor

Si custodias tus bitcoin tú mismo, cargas con el riesgo en solitario. Esta forma de custodia no entra en el reglamento europeo MiCA, que regula a los proveedores de servicios, no a particulares con sus propias claves. No hay garantía de depósitos, ni devolución del cargo, ni proveedor que compense un descubierto. Una transacción de bitcoin firmada y confirmada es definitiva.

En la práctica eso significa: la protección está en el software que ejecutas y en el cuidado al firmar. La lección de este caso es incómoda, porque afecta a los dos lados: la comprobación antes de firmar no sustituye a un software actualizado, y un software actualizado no sustituye a la comprobación.

Qué más trae Electrum 4.8.3: DNSSEC, BOLT11 y descriptores

Las notas de versión de la 4.8.3 presentan la corrección de seguridad como el único punto con indicación de gravedad, pero enumeran junto a ella una serie de cambios adicionales. Se incorpora mempool.space como fuente de tipos de cambio, y se añade un anclaje de confianza para la validación DNSSEC. El módulo de tipos de cambio se ha reelaborado, y las peticiones de red ya no pasan por la biblioteca Qt.

En el apartado de transacciones y gestión de claves, las notas citan comprobaciones más estrictas al leer descriptores y rutas BIP32, así como varias correcciones al firmar. Para la función Lightning se enumeran una comprobación más estricta de las facturas BOLT11 y la corrección de una condición de carrera en las copias de seguridad de canales. Se trata, por tanto, de una versión de seguridad con un paquete de mantenimiento más amplio, y no de un simple parche de emergencia.

Número de versión y fuente de descarga: electrum.org y la firma GPG

La versión en uso aparece en Electrum en la entrada de menú con la información del programa, en el escritorio normalmente en Ayuda. Si ahí figura un número inferior a 4.8.3, el fallo afecta a tu instalación. En la versión de Android desde Google Play o F-Droid, la página de la tienda correspondiente indica el número de versión.

Para obtenerlo hay una advertencia que Electrum coloca en primer plano en su propia portada: no descargues el software desde ninguna fuente que no sea electrum.org. Los paquetes falsificados de Electrum son una vía de ataque propia y más antigua. Los archivos ejecutables se compilan de forma reproducible y están firmados de manera independiente por varias personas, cuyas firmas GPG puedes comprobar antes de instalar. En una cartera que confía en servidores externos, esa comprobación es la ganancia de seguridad más barata que puedes conseguir.

Tu semilla no se ve afectada por una actualización, que no exige volver a configurar la cartera. Aun así, debería estar respaldada y accesible antes de cualquier intervención en la instalación.

Solución intermedia sin actualizar: comparar la dirección antes de cada firma

El aviso de seguridad propone una solución intermedia para este caso. Antes de cada firma, comprueba la dirección del destinatario y el importe, y hazlo en una subida de comisión con el mismo rigor que en el primer envío. No tomes la dirección por sus últimos caracteres, sino completa, o compárala en la pantalla de un dispositivo aparte.

Ya conoces una segunda señal de alarma: si tras el envío aparece en el historial una transacción que no conoces, o falta la tuya, no es un error de visualización que se arregle con una comisión más alta. En esa situación, subir la comisión es justo el gesto equivocado.

Actualización de Electrum: sin la 4.8.3 decide el servidor

1. Revisar la versión y actualizar. Si en tu cartera figura un número inferior a 4.8.3, consigue la 4.8.3 exclusivamente en electrum.org y comprueba la firma GPG. Hasta entonces, ninguna subida de comisión en una transacción que no hayas creado tú. Quien quiera cambiar de cartera de todos modos puede revisar las alternativas en la comparativa de carteras de software.
2. Comparar cada dirección completa. Los últimos cuatro caracteres no son prueba de nada, en ambos casos estaban reproducidos con exactitud. Si tienes un dispositivo con pantalla propia, el control se hace ahí, y qué dispositivos lo permiten lo muestra la comparativa de carteras de hardware.
3. Revisar la conexión al servidor y las alternativas. Quien usa un servidor propio o de confianza no estuvo afectado por este ataque. Qué software de cartera permite siquiera qué elección de servidor lo muestra la comparativa de carteras de software.

(25 de octubre de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)