Ledger-bugg kunde visa en transaktion och signera en annan

En sårbarhet i Ledgers Ethereum-app kunde i vissa så kallade clear-signing-flöden göra att enheten visade en legitim transaktion medan den i slutänden signerade en annan, skadlig begäran. Det hotade själva poängen med att kontrollera transaktionsdetaljerna på hårdvaruplånbokens skärm innan ett godkännande. 39

Ledger uppger att företagets säkerhetsteam Donjon upptäckte och åtgärdade felet innan TestMachine offentliggjorde sina resultat. Uppdateringen ingick i Ethereum-appens version 1.22.2, som släpptes den 12 augusti 2026. TestMachine började publicera sin beskrivning av problemet den 21 augusti. 569

Så kunde signeringsfelet utnyttjas

APDU-kommandon är de meddelanden som skickas mellan en ansluten dator eller dApp och Ledger-appen. Vid en normal clear-signing-process tar enheten emot transaktionsdata, visar viktiga detaljer för granskning och väntar på användarens godkännande.

Enligt den rapporterade forskningen kunde en skadlig webbplats eller dApp med WebHID-åtkomst skicka ett andra APDU-kommando medan den första transaktionen fortfarande granskades. Då uppstod en kapplöpning mellan två konkurrerande signeringsbegäranden. Det sårbara flödet band inte alltid den transaktion som visades på skärmen till en enda, oföränderlig signeringssession, vilket öppnade för så kallad signatur- eller transaktionssubstitution. 3715

I praktiken kunde användaren alltså se en harmlös åtgärd och godkänna den, medan enheten i stället signerade en skadlig token-godkännande, överföring eller annan manipulerad begäran. Det handlade därför inte bara om att en transaktion kunde misslyckas – utan om att den kontrollmekanism användaren förlitar sig på kunde sättas ur spel. 110

Vad version 1.22.2 ändrade

Ledger-uppdateringen åtgärdade det sårbara signeringsflödet. Teknisk rapportering om kodändringarna beskriver att version 1.22.2 hindrar en ny signeringssession från att ersätta en som redan granskas. Den avvisar också ett godkännande när applikationens tillstånd inte längre överensstämmer med den aktiva begäran. 10

Ledgers teknikchef Charles Guillemet har sagt att Donjon hittade sårbarheten med hjälp av AI-stödda verktyg för att upptäcka säkerhetsbrister och att korrigeringen distribuerades den 12 augusti. Rapporter beskriver versionsinformationen som en kort notis om säkerhetsproblem, snarare än en detaljerad offentlig säkerhetsvarning. 356

För användarna är skillnaden viktig. En uppdatering kan skydda signeringen framåt, men en knapphändig ändringslogg ger begränsad information om vad som faktiskt ändrats och om någon omedelbar åtgärd behövdes.

TestMachine och Azimuth offentliggjorde problemet

TestMachine uppgav att företagets AI-agent Azimuth hittade felet under en autonom skanning och att teamet validerade beteendet på en Ledger Flex. I inlägg som publicerades mellan den 21 och 23 augusti beskrev TestMachine hur en skadlig dApp kunde tävla in med ett APDU-kommando under transaktionsgranskningen. Företaget framställde problemet som något som berörde alla Ledger-enheter som kör Ethereum-appen. 4715

Avslöjandet riktade därmed uppmärksamhet mot en sårbarhet som Ledger säger redan hade åtgärdats. TestMachine uppgav också att företaget avstod från en bounty, medan Ledger ifrågasatte hur kontakten och informationsdelningen hade gått till. 1612

Tvisten om vem som upptäckte felet först

Oenigheten gäller främst den privata upptäckts- och rapporteringstidslinjen – inte att en korrigering har släppts.

Ledgers version, framförd av Guillemet, är att Donjon upptäckte felet, åtgärdade det och distribuerade korrigeringen ungefär två veckor innan TestMachine gick ut offentligt. Han kritiserade därefter offentliggörandet för att ha skapat onödig oro och framhöll att sårbarheten redan var hanterad. 6712

TestMachine hävdar i stället att Azimuth självständigt hittade och validerade problemet, och att Ledgers tysta uppdatering inte gav användarna en meningsfull varning om risken. Företagets offentliga inlägg betonade angreppsscenariot och den breda omfattningen av dess påstående. 715

Den tillgängliga rapporteringen stöder datumet för uppdateringen den 12 augusti och TestMachines offentliga inlägg den 21–23 augusti. Den fastställer däremot inte oberoende de exakta datumen för den privata upptäckten, kommunikationen mellan parterna eller hela händelseförloppet. Dessa delar bör därför betraktas som konkurrerande uppgifter, inte som slutgiltigt klarlagda fakta. 56912

Vilka Ledger-enheter kan ha berörts?

TestMachines breda påstående byggde på att Ethereum-appen och dess signeringskod delas mellan flera enheter. Den rapporterade praktiska valideringen gjordes dock på en Ledger Flex. Bland moderna produktfamiljer som kan dela relevant kod nämndes Nano S Plus, Nano X, Stax och Flex. 2720

Det är inte samma sak som ett fullständigt, oberoende bevis på att angreppet fungerar på varje Ledger-modell. Den 24 augusti var formuleringen ”alla Ledger” fortfarande ett forskarpåstående, inte ett komplett demonstrerat resultat för varje enhetsserie. Användare bör skilja mellan en potentiellt gemensam mjukvaruväg och ett offentligt reproducerat angrepp på varje enskild modell.

Har någon fått sina pengar stulna?

Den 24 augusti 2026 hade inga oberoende, verifierade stölder som specifikt kopplats till denna sårbarhet rapporterats. Det fanns inte heller någon bekräftad, komplett offentlig demonstration som täckte alla Ledger-enheter som påståtts vara berörda. 25614

Det säger något om det tillgängliga bevisläget vid den tidpunkten – inte att felet aldrig kan ha utnyttjats. Sårbarheten var allvarlig eftersom den kunde ha underminerat den transaktionsgranskning som användare förlitar sig på, även om bekräftade förluster inte hade framkommit i rapporteringen.

Detta bör Ledger-användare göra

Öppna Ledger Live och uppdatera Ethereum-appen till version 1.22.2 eller senare. Håll även Ledgers firmware och installerade appar uppdaterade. För just detta signeringsfel var det Ethereum-appens uppdatering som var den relevanta åtgärden – inte enbart en firmwareuppdatering. 515

Efter uppdateringen bör du fortsätta granska transaktioner på själva enheten. Kontrollera mottagare, belopp och vilken smartkontraktsåtgärd som visas på Ledger-skärmen innan du godkänner. Uppdateringen stänger den rapporterade vägen för att byta signeringssession, men noggrann kontroll av transaktionsdetaljer är fortfarande en central säkerhetsvana.