Cuatro caracteres bastaron para que una víctima firmara un pago hacia una dirección que no era la suya. Electrum, el monedero de Bitcoin creado en 2011, publicó el 24 de octubre de 2026 la versión 4.8.3 para cerrar un fallo de seguridad que, según su propio aviso de seguridad en GitHub, algunos servidores ya estaban explotando contra usuarios reales. El boletín no lo suaviza: «some servers are performing this attack in the wild» (hay servidores ejecutando este ataque en la red). De los dos usuarios que lo reportaron, uno confirmó la pérdida de fondos.
La mecánica: confiar en el servidor para lo no confirmado
Electrum es un monedero ligero. No descarga la cadena completa de Bitcoin; pregunta a un servidor qué transacciones existen y, por un diseño documentado, confía en ese servidor para las transacciones no confirmadas, las que aún viven en la mempool. El atacante explota exactamente ese punto de confianza.
El flujo del ataque, tal como lo describe el aviso, tiene cinco pasos. Primero, el usuario emite una transacción real; el servidor malicioso se la traga y no la propaga a la red. Segundo, el servidor inyecta en el historial de la cartera una transacción conflictiva y falsa que reemplaza la salida original por una dirección controlada por el atacante. Tercero, esa transacción falsa lleva firmas inválidas, pero el cliente ligero no las comprueba porque ese es, justamente, el diseño de un cliente ligero. Cuarto, el monedero muestra la transacción falsa como pendiente y la real ni siquiera aparece: «The wallet will display tx2 as an unconfirmed transaction – tx1 will not be displayed.» Quinto, si el usuario sube la comisión de esa transacción falsa mediante replace-by-fee (RBF), el monedero la firma con una comisión mayor y paga al atacante.
El aviso añade un detalle que explica por qué el segundo caso acabó en pérdida: el servidor construyó la transacción falsa con comisión cero, presumiblemente para empujar a la víctima a subirla. El ataque no toca las claves privadas. Toca la pantalla: lo que el usuario ve antes de firmar.
Dos informes y una pérdida real
La cronología del aviso es corta y concreta. El 11 de octubre llegó el primer reporte privado, de un usuario identificado como dannydeezy, que notó que su historial mostraba una transacción distinta a la que acababa de emitir. El 18 de octubre llegó el segundo, de Raju-K12, que subió la comisión y perdió dinero. El 23 de octubre se etiquetó la versión 4.8.3 con el parche; el 24 se publicaron los binarios y se hizo la divulgación pública. Entre el primer aviso y el parche pasaron trece días.
El primer caso es el que desmonta la idea de que esto solo le pasa a quien no presta atención. Era una cartera multifirma 2-de-3 legacy P2SH, con dos Trezor como firmantes, 31 inputs y una sola salida. El usuario verificó las salidas en ambos Trezor antes de emitir. Aun así, el historial mostró después el importe completo hacia una dirección desconocida; la entrada cambió luego a «Local» y nada llegó a la mempool. La transacción falsa copiaba los mismos inputs, la versión y el locktime de la real, con scriptSigs idénticos byte a byte en los 31 inputs. La víctima hizo la comprobación correcta en el momento equivocado: el ataque ocurre después de emitir, no antes.
Quince años confiando en el servidor
Electrum existe desde noviembre de 2011, cuando Thomas Voegtlin lo creó para no obligar a cada usuario a descargar la cadena completa de Bitcoin. Ese diseño —preguntar a un servidor el estado de la red y confiar en él para lo no confirmado— no es un accidente ni un descuido reciente: es lo que permite que el monedero abra en segundos y funcione en hardware modesto. La documentación oficial del proyecto admite abiertamente, desde hace años, que el servidor principal es una fuente de confianza para las transacciones de la mempool.
La historia también pesa. Entre diciembre de 2018 y 2019, atacantes operaron servidores falsos que mostraban mensajes de «actualización» fraudulentos para robar fondos de usuarios desprevenidos, una campaña que empujó al proyecto a endurecer sus advertencias. El fallo de 2026 es distinto: no engaña a la víctima para que descargue software falso, sino que corrompe lo que la cartera muestra en pantalla. Pero comparte la misma raíz. Un monedero ligero siempre depende de la honestidad del servidor que le responde, y esa dependencia es el precio de no descargar cientos de gigabytes de cadena.
Por qué cuatro caracteres no protegen nada
En ambos casos, la dirección del atacante estaba pulida para coincidir con la legítima en sus últimos cuatro caracteres. El aviso lo anota así: «both reported the attacker’s output address in tx2 was grinded to match the last four chars of the legit address from tx1.» El informe del primer usuario lo resume en una línea: «Real destination ends …GyQ3; fake destination ends …GyQ3.»
Mucha gente comprueba solo el primer o el último tramo de una dirección antes de firmar. La aritmética dice cuánto vale esa costumbre. Una dirección legacy usa Base58, un alfabeto de 58 símbolos: igualar los últimos cuatro caracteres exige recorrer 58 a la cuarta, es decir, 11.316.496 combinaciones. Una dirección SegWit bech32 usa un alfabeto de 32 símbolos: 32 a la cuarta son 1.048.576 combinaciones. Son cifras que un generador de direcciones vanity moderno procesa en cuestión de minutos, no de años. Comprobar cuatro caracteres no es una verificación; es una ilusión de verificación. Y en el caso de la multifirma, ni siquiera la comprobación en dos Trezor sirvió, porque la transacción falsa se inyectó después de la firma correcta.
Lo que corrige 4.8.3 y lo que deja abierto
El parche, contenido en el commit 90fe308, hace una sola cosa bien delimitada: «the client now verifies the signatures of wallet.is_mine inputs for mempool txs (before adding them to its local history).» En la práctica, el cliente comprueba las firmas de los inputs que pertenecen a la propia cartera antes de aceptar una transacción no confirmada en su historial local. Eso rompe el quinto paso del ataque: la transacción falsa ya no se muestra como firmable.
El aviso es igual de explícito sobre lo que el parche no cubre. El cliente sigue validando solo los inputs propios; las transacciones entrantes no se validan, porque un cliente ligero no dispone de un motor de consenso ni de un intérprete de scripts completo, y validarlas obligaría a recorrer recursivamente los padres no confirmados hasta llegar a transacciones minadas. Y añade el límite práctico: «Clients that connect to servers they trust (e.g. run their own) are not affected.» Quien opera su propio servidor Electrum nunca estuvo expuesto.
El contraargumento y lo que toca vigilar
Conviene no sobredimensionar el caso. No es una fuga de claves privadas ni un fallo en la criptografía. Requiere dos condiciones encadenadas: un servidor malicioso en la ruta del usuario y una víctima que suba la comisión manualmente con RBF. Un usuario que solo emite pagos y no los toca después no firma la transacción falsa. La mitigación temporal, sin actualizar, es la que propone el propio proyecto: verificar dirección de destino e importe en cada firma, incluida cualquier subida de comisión.
Lo que queda por ver es el alcance del mismo modelo en otros monederos. Electrum documenta desde hace años que el servidor principal es de confianza para las transacciones no confirmadas; el ataque no inventó esa confianza, la explotó. El proyecto dijo que publicará más detalles técnicos del fallo más adelante. La señal a vigilar no es un precio: es si otros clientes ligeros —los que también descargan solo un resumen de la cadena— revisan ahora qué hacen con las transacciones no confirmadas antes de mostrarlas.
Para quien use Electrum hoy, la instrucción no admite atajos. Actualizar a 4.8.3 descargando el software únicamente desde electrum.org y verificando la firma GPG del paquete; o, si la actualización no puede hacerse de inmediato, revisar dirección de destino e importe en cada firma, incluida cualquier subida de comisión. Quien quiera eliminar el riesgo de raíz puede operar su propio servidor Electrum: el aviso lo señala como la condición que deja al usuario fuera del alcance del ataque. En el ecosistema de carteras frías y calientes, la lección de Electrum es que el riesgo de un monedero ligero no está en las llaves, sino en lo que la pantalla te deja creer que estás firmando. Quien busque alternativas de autocustodia puede repasar la lista de los mejores monederos de Bitcoin, pero el mensaje de fondo es el mismo: actualiza y verifica cada firma.
Divulgación: este artículo no constituye asesoramiento de inversión. El contenido y los materiales de esta página tienen fines exclusivamente educativos.
