Electrum-wallet vóór versie 4.8.3 kwetsbaar: wat je nu kunt doen

Wie bitcoin in Electrum bewaart, doet er goed aan vandaag het versienummer van zijn wallet na te kijken. Elke versie vóór 4.8.3 bevat een lek waarmee een kwaadaardige server je ertoe kan brengen een betaling aan een aanvaller te ondertekenen. De ontwikkelaars hebben het op 23 oktober 2026 gedicht en een dag later openbaar gemaakt. In hun beveiligingsadvies staat de zin die dit geval onderscheidt van een theoretische zwakke plek: sommige servers voeren deze aanval al uit.

Het lek is ingeschaald met ernstniveau hoog, een CVE-nummer heeft het niet. Opmerkelijk is niet de techniek, maar de hefboom: het ontfutselt je sleutels niet en breekt geen versleuteling. Het wacht tot je een vastgelopen transactie versnelt, een van de meest voorkomende handelingen in het dagelijkse bitcoingebruik.

Wat Electrum 4.8.3 verhelpt: handtekeningen voor eigen inputs worden gecontroleerd

Electrum is een lichte wallet, een zogeheten light client. De term beschrijft een wallet die geen volledige kopie van de bitcoin-blockchain bijhoudt, maar bij een server van derden navraagt welke transacties bij zijn adressen horen. Dat maakt hem snel en zuinig, en het verschuift een deel van het vertrouwen naar die server.

Precies daar zette de aanval in. Tot versie 4.8.3 nam Electrum onbevestigde transacties op in de lokale historie zonder hun handtekeningen te controleren. De fix draait dat om: voordat een onbevestigde transactie in de historie belandt, controleert de wallet de handtekeningen van de inputs die van hemzelf zijn. Een vervalsing met een ongeldige handtekening valt daarmee op voordat ze in het overzicht verschijnt.

Eén beperking noemt het advies zelf: inputs die niet bij de eigen wallet horen, blijven ongecontroleerd. Inkomende betalingen van vreemde adressen zijn dus nog steeds niet volledig geverifieerd. Voor de beschreven aanvalsroute volstaat de nieuwe controle, omdat die per se de eigen inputs hergebruikt.

Replace-by-fee: wanneer de verhoging van de transactiekosten een tweede handtekening wordt

Replace-by-fee, kortweg RBF, is een methode waarmee je een nog onbevestigde bitcointransactie vervangt door een nieuwe met hogere kosten. Dat is standaard en zinvol: wie bij een volle mempool te krap heeft gerekend, zit anders uren vast. Hoe dat in de praktijk gaat, beschrijven we in onze handleiding over vastgelopen bitcointransacties met RBF en CPFP.

Het beslissende punt: een kostenverhoging is technisch geen correctie van de oude transactie, maar een nieuwe die opnieuw moet worden ondertekend. In het verzendscherm lijkt dat een formaliteit. Je hebt het ontvangstadres net nog gecontroleerd, je wilt alleen de kosten verhogen. Onderteken je op dat moment een transactie die een aanvaller heeft gebouwd, dan onderteken je zijn ontvangstadres mee.

De aanvalsroute: van onderdrukte broadcast naar vervalste historie

Het beveiligingsadvies beschrijft vijf stappen. Je wallet stuurt een transactie, laten we haar tx1 noemen, naar de server. De server verspreidt haar niet verder, maar gooit haar weg. Daarna zet hij een tweede transactie in je historie, tx2. Die gebruikt dezelfde inputs als tx1, maar stuurt bijna alle outputs naar een adres van de aanvaller.

De handtekeningen van tx2 zijn ongeldig, want de aanvaller bezit je sleutels niet. Omdat de oude Electrum-versie ze niet controleerde, toonde die tx2 toch als onbevestigd. Je eigen tx1 ontbrak in het overzicht, ze was nooit in het netwerk aangekomen. Voor jou zag dat eruit als een betaling die niet doorkomt.

In een van de gemelde gevallen had de server tx2 met kosten van nul gebouwd. Dat is geen vergissing, maar onderdeel van het lokaas: een transactie zonder kosten beweegt nooit, en de voor de hand liggende reactie daarop is naar de kostenverhoging grijpen.

Waarom de vervalsing überhaupt werd getoond

Een volwaardige bitcoin-node had tx2 meteen verworpen, omdat die elke handtekening tegen de blockchain controleert. Een lichte wallet doet dat uit principe niet voor alles wat hij binnenkrijgt. De aanval maakte gebruik van die taakverdeling, zonder een cryptografische drempel te nemen. De aanval vroeg van de server geen geldige sleutel en geen gebroken handtekening, alleen de zekerheid dat niemand narekent.

Twee gemelde gevallen, één verlies: de tijdlijn van de openbaarmaking

De ontwikkelaars noemen twee onafhankelijke meldingen. Op 11 oktober 2026 beschreef een gebruiker dat er na het verzenden een andere transactie in zijn historie stond en zijn eigen transactie het bitcoinnetwerk nooit bereikte. De route via de kostenverhoging was op dat moment nog niet herkend. Op 18 oktober meldde een tweede gebruiker een verlies, nadat hij de kosten van de vreemde transactie had verhoogd.

Vijf dagen later, op 23 oktober, was versie 4.8.3 met de fix getagd. Op 24 oktober volgden de kant-en-klare programmabestanden en de openbaarmaking. Over de hoogte van het verlies doen de ontwikkelaars geen uitspraak, en een aantal getroffen gebruikers buiten deze twee meldingen noemen ze niet. Wie iets anders leest, leest een schatting.

Als primaire bron dient de startpagina van electrum.org, die 4.8.3 als actuele versie vermeldt, inclusief de release notes. De technische beschrijving staat in het beveiligingsadvies GHSA-6jp4-8v48-cc5v.

Adressen geslepen op vier tekens: de misleiding in het verzendscherm

Beide meldingen hebben een detail gemeen dat verklaart waarom een snelle visuele controle niet volstond. De aanvallers hadden hun ontvangstadres net zo lang laten genereren tot de laatste vier tekens overeenkwamen met die van het echte doeladres. Die methode heet vanity grinding: je probeert sleutelparen tot het bijbehorende adres een gewenst patroon draagt.

Vier overeenkomende tekens aan het eind zijn goedkoop te maken en raken precies de plek waar veel gebruikers naar kijken. Wie een bitcoinadres controleert, kijkt in de praktijk zelden naar alle tekens, maar naar het begin en het eind. Precies die gewoonte was het doelwit.

Wie niet getroffen was: eigen server en de rol van de hardware wallet

Eén groep bleef buiten schot. Wie zijn Electrum-wallet verbindt met een zelf beheerde of op een andere manier betrouwbare server, stond niet bloot aan de aanval, want zonder kwaadaardige server ontbreekt de eerste stap. Electrum verbindt standaard met openbare servers die iedereen kan draaien, en dat is bij deze wallet de normale situatie.

Een hardware wallet helpt hier maar beperkt, en het loont het verschil te kennen. Hij beschermt de private key tegen de computer, niet tegen een verkeerd ontvangstadres in het verzendscherm. Toont je apparaat adres en bedrag op zijn eigen scherm en vergelijk je ze daar, dan vangt het de misleiding op. Vertrouw je op de weergave op de computer, dan ondertekent de hardware wallet de gemanipuleerde transactie net zo goed. Welke apparaten adres en bedrag op een eigen scherm tonen, staat in onze vergelijking van hardware wallets.

Self-custody in de EU: de aansprakelijkheid blijft bij de houder

Bewaar je je bitcoin zelf, dan draag je het risico alleen. Die vorm van bewaring valt niet onder de Europese cryptoverordening MiCA, die dienstverleners reguleert, niet particulieren met eigen sleutels. Er is geen depositogarantie, geen terugboeking en geen aanbieder die een tekort aanvult. Een ondertekende en bevestigde bitcointransactie is definitief.

In de praktijk betekent dat: de bescherming zit in de software die je draait en in de zorgvuldigheid bij het ondertekenen. De les uit dit geval is ongemakkelijk, omdat ze beide kanten raakt: de controle vóór het ondertekenen vervangt geen actuele software, en actuele software vervangt de controle niet.

Wat Electrum 4.8.3 verder bevat: DNSSEC, BOLT11 en descriptors

De release notes van 4.8.3 vermelden de beveiligingscorrectie als enige punt met een ernstniveau, maar sommen daarnaast een reeks andere wijzigingen op. Nieuw opgenomen is mempool.space als bron voor wisselkoersen, daarbij komt een vertrouwensanker voor de DNSSEC-controle. De module voor wisselkoersen is herzien, en netwerkverzoeken lopen niet meer via de Qt-bibliotheek.

Op het gebied van transacties en sleutelbeheer noemen de notes strengere controles bij het inlezen van descriptors en BIP32-paden, en meerdere correcties bij het ondertekenen. Voor de Lightning-functie staan een strengere controle van BOLT11-facturen en een opgeloste race condition bij kanaalback-ups vermeld. Het gaat dus om een beveiligingsversie met een groter onderhoudspakket, niet om een pure noodpatch.

Versienummer en downloadbron: electrum.org en de GPG-handtekening

De draaiende versie staat in Electrum onder het menu-item met de programma-informatie, op de desktop meestal onder Help. Staat daar een nummer lager dan 4.8.3, dan geldt het lek voor jouw installatie. Bij de Android-versie uit Google Play of F-Droid geeft de betreffende storepagina het versienummer.

Bij het downloaden geldt een waarschuwing die Electrum zelf op zijn startpagina vooropzet: download de software van geen andere bron dan electrum.org. Vervalste Electrum-pakketten zijn een eigen, oudere aanvalsroute. De programmabestanden zijn reproduceerbaar gebouwd en door meerdere personen onafhankelijk ondertekend; hun GPG-handtekeningen kun je vóór de installatie controleren. Bij een wallet die servers van derden vertrouwt, is die controle de goedkoopste veiligheidswinst die je kunt hebben.

Je seed blijft bij een update onaangeroerd, een nieuwe inrichting van de wallet is niet nodig. Toch hoort hij vóór elke ingreep aan de installatie veilig opgeslagen en bereikbaar te zijn.

Tussenoplossing zonder update: adres vergelijken vóór elke handtekening

Het beveiligingsadvies noemt voor dit geval een tussenoplossing. Controleer vóór elke handtekening het ontvangstadres en het bedrag, en wel bij een kostenverhoging net zo grondig als bij de eerste verzending. Beoordeel het adres daarbij niet op de laatste tekens, maar volledig, of vergelijk het op het scherm van een apart apparaat.

Een tweede waarschuwingssignaal ken je nu: verschijnt na het verzenden een transactie in het overzicht die je niet kent, of ontbreekt je eigen, dan is dat geen weergavefout die je met hogere kosten verhelpt. In die situatie is een kostenverhoging precies de verkeerde greep.

Electrum-update: zonder 4.8.3 bepaalt de server wat je ziet

1. Versie nakijken en bijwerken. Staat er een nummer onder 4.8.3 in je wallet, haal 4.8.3 dan uitsluitend van electrum.org en controleer de GPG-handtekening. Tot die tijd geen kostenverhoging op een transactie die je niet zelf hebt aangemaakt. Wie toch al van wallet wil wisselen, bekijkt de alternatieven in ons overzicht van software wallets.
2. Elk adres volledig vergelijken. De laatste vier tekens zijn geen bewijs, ze waren in beide gevallen exact nagebouwd. Heb je een apparaat met een eigen scherm, doe de controle dan daar; welke apparaten dat kunnen, laat de vergelijking van hardware wallets zien.
3. Serververbinding en alternatieven controleren. Wie een eigen of betrouwbare server gebruikt, was niet getroffen door deze aanval. Welke walletsoftware welke serverkeuze überhaupt toestaat, laat ons overzicht van software wallets zien.

(Per 25 oktober 2026. Dit artikel is geen beleggingsadvies. Koersen en tarieven veranderen; controleer de voorwaarden bij de aanbieder voordat je koopt.)