El aviso de seguridad de Electrum en GitHub indica que el proyecto publicó el 24 de octubre de 2026 la alerta GHSA-6jp4-8v48-cc5v, clasificó la falla como de severidad alta y la vinculó con al menos un caso de pérdida de fondos reportado por usuarios. Según Electrum, el problema afectaba a las versiones anteriores a la 4.8.3 y se explotaba a través de servidores maliciosos. La importancia práctica es que el ataque no dependía de romper Bitcoin, sino de mostrar en el wallet una transacción no confirmada falsa y aprovechar una acción posterior del usuario. La versión que el proyecto señala como corregida es Electrum 4.8.3.
Electrum dijo que recibió dos reportes de usuarios, el 11 y el 18 de octubre de 2026, y que en el segundo hubo pérdida de fondos después de usar la función para aumentar la comisión. El proyecto también afirmó que algunos servidores ya estaban ejecutando el ataque en el entorno real. Ni el aviso público divulgó el monto robado, ni identificó los servidores maliciosos, ni publicó los txid o las direcciones del atacante.
Qué versiones estaban expuestas y quiénes quedaban fuera
De acuerdo con Electrum en GitHub, la vulnerabilidad alcanza a las versiones anteriores a la 4.8.3. Eso marca una diferencia clara entre el anuncio del problema y la disponibilidad de una corrección: el proyecto etiquetó la versión 4.8.3 el 23 de octubre de 2026, publicó binarios el 24 de octubre y divulgó la falla públicamente ese mismo día. En otras palabras, la actualización de seguridad ya había sido preparada cuando salió el aviso.
El mismo aviso acota quiénes no estaban dentro del riesgo descrito. Según Electrum, los usuarios conectados únicamente a servidores de confianza, incluido un servidor propio, no estaban afectados por este ataque. El punto importa porque la maniobra dependía de que un servidor malicioso pudiera intervenir en lo que el wallet mostraba sobre una transacción reciente.
Cómo funcionaba la trampa con la transacción falsa
Electrum describe el ataque como una secuencia sobre una transacción recién emitida. Según su aviso de seguridad, un servidor malicioso interceptaba esa transacción, la ocultaba y luego mostraba en el historial del wallet una transacción conflictiva inválida que reemplazaba la salida por una dirección del atacante. Para el usuario, el riesgo era que el historial local del monedero mostrara algo que parecía una operación pendiente, aunque en realidad esa versión era falsa.
La segunda parte del engaño aparecía cuando el usuario aplicaba manualmente Replace-by-Fee, o RBF, un mecanismo que reemplaza una transacción no confirmada por otra con mayor comisión para intentar que se procese antes. Electrum dijo que, en esa situación, el cliente podía terminar firmando una transacción válida que sí pagaba al atacante. El problema, tal como lo cuenta el proyecto, no fue una filtración de llaves privadas sino la posibilidad de inducir una firma sobre una versión distinta a la esperada.
El aviso añade un detalle que vuelve más creíble la trampa a simple vista: en ambos reportes, la dirección del atacante había sido generada para coincidir en los últimos cuatro caracteres con la dirección legítima. Por eso, revisar solo el final de una dirección no alcanzaba en estos casos. Si quieres repasar cómo se componen estos destinos de pago, puede servir esta guía sobre cómo funciona una dirección de Bitcoin.
Qué cambió en Electrum 4.8.3
La corrección que Electrum atribuye al commit 90fe308 cambia la forma en que el cliente trata ciertas transacciones no confirmadas. Según el proyecto, el cliente pasa a verificar las firmas de las entradas que pertenecen al propio wallet dentro de transacciones del mempool, la cola de operaciones que aún no entran en un bloque, antes de agregarlas al historial local. Esa validación adicional apunta exactamente al punto que el ataque explotaba: la confianza en lo que el servidor mostraba antes de la confirmación.
Ese detalle técnico importa porque la interfaz del wallet se apoya en ese historial local para mostrar al usuario qué está pasando con su pago. Si una transacción no confirmada falsa logra entrar allí, la siguiente acción del usuario puede construirse sobre una base errónea. Para entender mejor ese estado intermedio de las operaciones, aquí puedes revisar qué es el mempool de transacciones de Bitcoin.
Los límites del parche y la implicancia para usuarios de BTC
El propio aviso también limita el alcance de la solución. Según Electrum, incluso con el parche el cliente solo valida entradas marcadas como propias del wallet y no valida, por ejemplo, transacciones entrantes completas ni todos los padres no confirmados. Eso significa que la actualización corrige el vector descrito por el proyecto, pero no convierte al cliente en un verificador total de todo lo que ocurre antes de la confirmación.
Para usuarios de BTC, la consecuencia demostrable del caso es más concreta que amplia. El riesgo quedó acotado por Electrum a versiones anteriores a 4.8.3 y a la interacción con servidores no confiables, no a una falla general de Bitcoin. Aun así, el patrón descrito por el proyecto deja una advertencia útil: antes de firmar una transacción o usar el aumento manual de comisión, conviene revisar la dirección completa y el monto, porque en los reportes analizados el atacante había preparado una dirección que coincidía en los cuatro caracteres finales con la legítima.
BTC en el mercado de Fluyez
Bitcoin (BTC) cotiza en 80,314.33 USD y sube 0.00 % en las últimas 24 horas, según los datos del propio mercado de Fluyez el 26 de octubre de 2026, 06:01 hora de Lima.
En soles, eso equivale a 275,225.81 PEN por unidad.
El dato verificado
- Precio: 80,314.33 USD
- Variación 24 horas: +0.00 %
- Equivalente: 275,225.81 PEN
- Datos del 26 de octubre de 2026, 06:01 hora de Lima
