Ledger-bug kunne vise én transaksjon og signere en annen

En sårbarhet i enkelte «clear signing»-forløp i Ledgers Ethereum-app kunne ha latt en ondsinnet dApp bytte ut transaksjonsdata mens brukeren fortsatt kontrollerte den opprinnelige transaksjonen. I det mest alvorlige scenariet ville Ledger-skjermen fortsatt vist legitime detaljer, selv om enheten signerte en annen forespørsel. 39

Ledger opplyser at selskapets sikkerhetsteam Donjon fant og rettet feilen før TestMachine offentliggjorde funnene. Oppdateringen kom i Ethereum-appversjon 1.22.2 den 12. august 2026, mens TestMachine begynte å publisere materialet sitt 21. august. 569

Slik kunne angrepet fungere

Problemet gjaldt APDU-kommandoer – meldingene som utveksles mellom en tilkoblet datamaskin eller dApp og Ethereum-appen på Ledger-enheten. I en vanlig «clear signing»-prosess mottar enheten transaksjonsdata, viser viktige detaljer på skjermen og venter på at brukeren skal godkjenne.

Ifølge den rapporterte analysen kunne en ondsinnet nettside eller dApp med WebHID-tilgang sende en ny APDU-kommando mens den første transaksjonen fortsatt var til gjennomgang. Dermed oppsto et kappløp mellom to signeringsforespørsler. Den sårbare prosessen bandt ikke alltid transaksjonen som ble vist på enheten, til én uforanderlig signeringsøkt. Det åpnet for såkalt signatur- eller transaksjonssubstitusjon. 3715

Faren var ikke bare at en transaksjon kunne mislykkes. En bruker kunne se en tilsynelatende ufarlig handling og godkjenne den, mens enheten i praksis signerte en skadelig token-godkjenning, overføring eller annen transaksjon. Det ville undergravd selve hensikten med clear signing: at brukeren skal kunne kontrollere transaksjonsdetaljene på en fysisk sikkerhetsenhet før godkjenning. 110

Hva versjon 1.22.2 endret

Ledger-oppdateringen rettet den sårbare delen av signeringsprosessen. Teknisk omtale av kodeendringene viser at versjon 1.22.2 hindrer en ny signeringsøkt i å erstatte en økt som allerede er under gjennomgang. Den avviser også en godkjennings-tilbakemelding dersom appens tilstand ikke lenger samsvarer med den aktive forespørselen. 10

Ledgers teknologidirektør Charles Guillemet har sagt at Donjon fant sårbarheten ved hjelp av KI-assisterte verktøy for sårbarhetsdeteksjon, og at løsningen ble rullet ut 12. august. Omtalen av utgivelsen beskrev endringen som en kort sikkerhetsrettelse, ikke som en detaljert offentlig sikkerhetsmelding. 356

Dette er viktig for brukerne: En oppdatert app kan beskytte signeringsprosessen fremover, men en knapp endringslogg gir lite informasjon om hva som faktisk ble endret eller om brukerne måtte foreta seg noe umiddelbart.

TestMachine og Azimuths offentliggjøring

TestMachine sa at KI-agenten Azimuth fant feilen under en autonom skanning, og at selskapet validerte oppførselen på en Ledger Flex. I innlegg publisert fra 21. til 23. august beskrev TestMachine hvordan en ondsinnet dApp kunne sende en konkurrerende APDU-kommando mens brukeren kontrollerte transaksjonen. Selskapet framstilte problemet som relevant for alle Ledger-enheter som kjører Ethereum-appen. 4715

Offentliggjøringen rettet oppmerksomheten mot en sårbarhet Ledger sier allerede var rettet. TestMachine opplyste også at selskapet takket nei til en belønning, mens Ledger bestridte hvordan kontakten og offentliggjøringen hadde foregått. 1612

Uenigheten om hvem som fant feilen først

Striden handler først og fremst om den private oppdagelses- og varslingstidslinjen – ikke om at en oppdatering ble publisert.

Ledgers versjon, slik Guillemet har framstilt den, er at Donjon fant feilen, rettet den og publiserte korrigeringen omtrent to uker før TestMachine gikk ut offentlig. Han kritiserte den påfølgende offentliggjøringen for å ha skapt unødig panikk og viste til at sårbarheten allerede var håndtert. 6712

TestMachine sier på sin side at Azimuth fant og validerte problemet uavhengig, og at Ledgers stille oppdatering ikke ga brukerne en reell advarsel om risikoen. Selskapets offentlige innlegg la vekt på angrepsscenarioet og den påståtte bredden i problemet. 715

Den tilgjengelige omtalen støtter datoen for oppdateringen, 12. august, og datoene for TestMachines offentlige innlegg, 21.–23. august. Den fastslår imidlertid ikke uavhengig de nøyaktige datoene for private funn, kommunikasjonen mellom partene eller hele hendelsesforløpet. Disse detaljene bør derfor behandles som konkurrerende versjoner, ikke som endelig avklarte fakta. 56912

Hvilke Ledger-enheter kan ha vært berørt?

TestMachines brede påstand bygger på at flere Ledger-enheter deler Ethereum-appens signeringskode, men den rapporterte praktiske valideringen ble gjort på en Ledger Flex. Omtaler har pekt på moderne enhetsfamilier som kan dele relevant kode, blant annet Nano S Plus, Nano X, Stax og Flex. 2720

Det er likevel ikke det samme som et fullstendig, uavhengig dokumentert bevis på at angrepet fungerer på hver eneste Ledger-modell. Per 24. august var formuleringen «alle Ledger-enheter» fortsatt en påstand fra forskerne, ikke et fullstendig demonstrert resultat på tvers av alle enhetslinjer. Brukere bør skille mellom en mulig felles programvarebane og et offentlig gjenskapt angrep på hver enkelt modell.

Ble noen midler stjålet?

Per 24. august 2026 var det ikke rapportert om uavhengig bekreftede tyverier som spesifikt kunne knyttes til denne sårbarheten. Det forelå heller ingen bekreftet, komplett offentlig demonstrasjon som dekket alle Ledger-enhetene det ble hevdet at var berørt. 25614

Dette sier noe om dokumentasjonen som var tilgjengelig på det tidspunktet – ikke at feilen aldri kan ha blitt utnyttet. Sårbarheten var alvorlig fordi den kunne ha satt transaksjonskontrollen brukerne stoler på, ut av spill, selv om det ikke var kommet fram bekreftede tap i den tilgjengelige rapporteringen.

Dette bør Ledger-brukere gjøre

Åpne Ledger Live og oppdater Ethereum-appen til versjon 1.22.2 eller nyere. Hold også Ledger-enhetens fastvare og de installerte appene oppdatert. For denne konkrete feilen var det Ethereum-appens oppdatering som var det relevante tiltaket – ikke bare en fastvareoppdatering. 515

Også etter oppdateringen bør brukerne kontrollere transaksjoner på selve enheten før de godkjenner: Sjekk mottaker, beløp og hva smartkontrakten faktisk ber om. Oppdateringen skal stenge den rapporterte veien for å bytte signeringsøkt, men grundig kontroll på enhetens skjerm er fortsatt en sentral sikkerhetsrutine.