Sommeren 2026 fikk Trezor-brukere en p\u00e5minnelse om at en hardware-lommebok bare er s\u00e5 sikker som firmwaren som kj\u00f8rer p\u00e5 den. En s\u00e5rbarhet kalt CVE-2026-65058 gjorde det mulig for en ondsinnet vertsapplikasjon \u00e5 endre innholdet i en Ethereum-transaksjon etter at brukeren hadde bekreftet den p\u00e5 skjermen. Feilen rammet Trezor Safe 3, Safe 5 og Safe 7, og den br\u00f8t akkurat det prinsippet hardware-lommeb\u00f8ker selger seg inn p\u00e5: at det du ser p\u00e5 skjermen, er det du signerer. Denne guiden viser deg, steg for steg, hvordan du selv tester om enheten din er s\u00e5rbar, hvordan du oppdaterer riktig, og hvordan du bygger et lite prosjekt som lar deg verifisere Ethereum-signering fra en Trezor p\u00e5 egen h\u00e5nd.<\/p>\n
Du trenger ingen forkunnskaper utover litt erfaring med terminalen og JavaScript. Alt du bygger underveis kj\u00f8rer mot Sepolia-testnettet, s\u00e5 du risikerer ingen ekte midler mens du l\u00e6rer.<\/p>\n
Guiden dekker hele l\u00f8pet fra \u00e5 identifisere firmwareversjonen din, via \u00e5 bygge et lite Node.js-prosjekt som snakker direkte med enheten, til \u00e5 simulere selve angrepsscenarioet p\u00e5 en trygg testkontrakt. Underveis l\u00e6rer du hvordan Ethereum-signering p\u00e5 en hardware-lommebok faktisk fungerer under panseret, ikke bare hvordan du klikker \u201cbekreft\u201d. Det gj\u00f8r deg i stand til \u00e5 vurdere fremtidige sikkerhetsvarsler selv, i stedet for \u00e5 m\u00e5tte stole blindt p\u00e5 produsentens egne forsikringer.<\/p>\n
Bakgrunn: dette gjorde CVE-2026-65058 med Ethereum-signeringen<\/p>\n
N\u00e5r en Trezor signerer en Ethereum-kontraktstransaksjon, sendes kalldataene fra verten (Trezor Suite, MetaMask eller en annen klient) til enheten i flere biter. Hver bit hasjes inn i transaksjonsdigesten som til slutt signeres. Problemet l\u00e5 i at enheten bare viste den f\u00f8rste biten med kalldata til brukeren for bekreftelse, mens den fortsatte \u00e5 hasje inn resten av bitene uten noe tilsvarende varsel. Signaturen som til slutt ble produsert, dekket alts\u00e5 langt mer data enn det brukeren faktisk fikk se og godkjenne.<\/p>\n
SentinelOne beskriver feilen som en \u201cconfirmation-binding\u201d-svakhet i signeringsflytene sign_tx og sign_tx_eip1559, klassifisert under CWE-358 (Improperly Implemented Security Check for Standard). En angriper med kontroll over vertsapplikasjonen, for eksempel en kompromittert lommebok-klient eller en ondsinnet dApp-kobling, kunne vise en ufarlig transaksjon p\u00e5 skjermen mens den faktiske signaturen dekket en helt annen mottaker, et annet bel\u00f8p eller andre ABI-kodede parametere. Trezor selv beskriver s\u00e5rbarheten p\u00e5 sitt sikkerhetsportal som en feil i SLIP-24-grenen for verifiserte swap-transaksjoner, der en beskyttelse mot ekstra kalldata ikke var aktiv i produksjonsfirmware.<\/p>\n
Feilen ble rapportert 16. mai 2026 av en forsker med brukernavnet LoopGhost, publisert til NVD 21. juli 2026, og rettet i commit 70c9b0c07748 i trezor-firmware-repoet p\u00e5 GitHub. Fiksen endrer core\/src\/apps\/ethereum\/layout.py slik at kalldata bekreftes underveis i hasjingen, ikke bare i det f\u00f8rste steget. Dermed blir de bytene som vises p\u00e5 skjermen, alltid de samme bytene som til slutt signeres.<\/p>\n
What-You-See-Is-What-You-Sign: prinsippet feilen br\u00f8t<\/p>\n
Hardware-lommeb\u00f8ker bygger p\u00e5 et enkelt l\u00f8fte som ofte forkortes WYSIWYS: det du ser p\u00e5 skjermen, er det du signerer. L\u00f8ftet finnes fordi datamaskinen eller mobilen som snakker med enheten aldri kan stoles fullt ut. Nettleseren kan ha en ondsinnet utvidelse, en dApp kan ha byttet ut RPC-endepunktet sitt, eller selve wallet-klienten kan v\u00e6re kompromittert. Hardware-lommeboken er det siste sikkerhetslaget, det stedet der brukeren fysisk kan se etter og godkjenne hva som faktisk skjer, uavhengig av hva verten sier.<\/p>\n
For enkle overf\u00f8ringer er dette prinsippet lett \u00e5 h\u00e5ndheve. Mottaker og bel\u00f8p passer p\u00e5 en liten skjerm uten problemer. Kontraktskall er vanskeligere, siden kalldata ofte er hundrevis av byte kodet i hexadesimal form, umulig \u00e5 lese for et menneske uten videre tolkning. Trezor og andre produsenter l\u00f8ser dette ved \u00e5 tolke funksjonssignaturer der det er mulig, og vise en forkortet oppsummering av parameterne. Feilen i CVE-2026-65058 oppsto nettopp i grenseflaten mellom denne tolkningen og selve signeringen: enheten viste en oppsummering av starten p\u00e5 dataene, men signerte alt som kom etterp\u00e5 uten \u00e5 knytte de to sammen kryptografisk p\u00e5 riktig m\u00e5te.<\/p>\n
Det tekniske begrepet SentinelOne bruker, confirmation-binding, beskriver akkurat dette gapet. En sikker implementasjon m\u00e5 garantere at hasjen som til slutt signeres er beregnet over n\u00f8yaktig de samme bytene brukeren fikk presentert, verken mer eller mindre. N\u00e5r den garantien mangler, spiller det ingen rolle hvor pen eller tillitvekkende bekreftelsesskjermen ser ut. Dette er grunnen til at testen du bygger i denne guiden fokuserer p\u00e5 \u00e5 sammenligne r\u00e5 byte-for-byte data, ikke bare \u00e5 se at \u201cen dialog dukket opp\u201d.<\/p>\n
Hvorfor dette ang\u00e5r norske og nordiske Trezor-brukere<\/p>\n
Hardware-lommeb\u00f8ker har blitt standardanbefalingen for alle som oppbevarer krypto over lengre tid i Norden, nettopp fordi de flytter signeringsn\u00f8kkelen bort fra en internettkoblet PC eller mobil. Poenget forsvinner delvis hvis selve signeringsflyten kan manipuleres av en kompromittert klient p\u00e5 den samme PC-en. Mange nordiske brukere kobler Trezor-en sin til DeFi-protokoller, NFT-markedsplasser og bro-tjenester p\u00e5 Ethereum, alts\u00e5 n\u00f8yaktig de kontraktsinteraksjonene som CVE-2026-65058 rammet.<\/p>\n
S\u00e5rbarheten krevde riktignok en kompromittert vert, ikke bare fysisk tilgang til enheten. Det gj\u00f8r den mer relevant for folk som bruker mange forskjellige nettsider og wallet-connect-integrasjoner, og mindre relevant for noen som kun sender BTC fra en isolert maskin. Poenget med denne guiden er ikke \u00e5 skape frykt, men \u00e5 gi deg et konkret verkt\u00f8y for \u00e5 teste at oppdateringen faktisk virker hos deg, i stedet for bare \u00e5 stole p\u00e5 at \u201cdet er fikset n\u00e5\u201d.<\/p>\n
Det er ogs\u00e5 en praktisk grunn til at nordiske brukere spesielt b\u00f8r ta eierskap til denne typen verifisering selv. Norge, Sverige, Danmark og Finland ligger h\u00f8yt p\u00e5 b\u00e5de kryptoadopsjon og teknologisk selvhjulpenhet sammenlignet med resten av Europa, noe som betyr at mange her kombinerer en hardware-lommebok med aktiv bruk av DeFi-protokoller, layer 2-broer og NFT-markedsplasser i stedet for \u00e5 bare la kryptoen ligge ur\u00f8rt. Hver ekstra kontraktsinteraksjon er en ny mulighet for et signeringsavvik \u00e5 slippe gjennom ubemerket, og da er det bedre \u00e5 ha et testoppsett liggende klart enn \u00e5 stole p\u00e5 at man ville lagt merke til noe unormalt med det blotte \u00f8yet.<\/p>\n
Forutsetninger: verkt\u00f8y og versjoner du trenger<\/p>\n
Sett av 45-60 minutter til hele oppsettet. Du trenger f\u00f8lgende verkt\u00f8y installert f\u00f8r du starter:<\/p>\n
Du trenger ogs\u00e5 litt Sepolia-ETH fra en faucet for \u00e5 betale gebyr p\u00e5 testkontrakten. Bruk aldri hovedlommeboken din eller ekte midler til denne testen. Hele poenget er \u00e5 \u00f8ve p\u00e5 en isolert transaksjon der du uansett ikke taper noe hvis noe g\u00e5r galt.<\/p>\n
Trezor Safe 3, Safe 5 og Safe 7: hva betyr modellvalget for testen<\/p>\n
Alle tre modellene ble rammet av CVE-2026-65058, og alle tre kan testes med n\u00f8yaktig samme prosjekt i denne guiden, siden @trezor\/connect abstraherer bort de fleste maskinvareforskjellene. Det er likevel greit \u00e5 vite hva som faktisk skiller dem, spesielt fordi skjermst\u00f8rrelse p\u00e5virker hvor mye av kalldataene du realistisk kan lese f\u00f8r du bekrefter.<\/p>\n
Safe 7 skiller seg mest ut arkitektonisk, med to separate Secure Elements og tr\u00e5dl\u00f8s Bluetooth 5.0-tilkobling i tillegg til USB-C, samt et LiFePO4-batteri p\u00e5 3,2V og 330mAh som lades tr\u00e5dl\u00f8st via Qi2. Trezor markedsf\u00f8rer den som sin f\u00f8rste enhet bygget med en arkitektur klargjort for fremtidige kvantesikre oppdateringer. For denne guiden spiller det likevel mindre rolle hvilken modell du bruker enn at du faktisk kj\u00f8rer en fikset firmwareversjon, siden confirmation-binding-feilen l\u00e5 i den delte Ethereum-signeringskoden som alle tre modellene baserer seg p\u00e5.<\/p>\n
Steg 1-2: sjekk enhet og oppdater til riktig firmware<\/p>\n
Det f\u00f8rste du skal gj\u00f8re er \u00e5 finne ut n\u00f8yaktig hvilken firmwareversjon enheten din kj\u00f8rer n\u00e5. Koble Trezor-en til med USB-C-kabelen som fulgte med, og kj\u00f8r f\u00f8lgende kommando i terminalen:<\/p>\n
pip install trezor
\ntrezorctl device features | grep -i version<\/p>\n
Et typisk svar ser slik ut:<\/p>\n
major_version: 2
\nminor_version: 12
\npatch_version: 2
\nmodel: T2B1<\/p>\n
Hvis patch_version viser 2 eller lavere p\u00e5 2.12-grenen, kj\u00f8rer du en versjon som ble sluppet f\u00f8r eller rett rundt CVE-fiksen, og du b\u00f8r oppdatere umiddelbart. Trezors egen changelog viser at 2.12.2 kom 22. juli 2026, dagen etter at CVE-en ble publisert til NVD, mens 2.12.3 og 2.12.4 fulgte 24. juli og 19. august 2026. For \u00e5 v\u00e6re helt sikker p\u00e5 at du har med fiksen fra commit 70c9b0c07748, oppdater til minst 2.12.4.<\/p>\n
\u00c5pne Trezor Suite, koble til enheten, og klikk p\u00e5 varselet om tilgjengelig firmwareoppdatering. Bekreft handlingen p\u00e5 selve enhetens skjerm, ikke bare i appen. Vent til Suite viser \u201cFirmware er oppdatert\u201d f\u00f8r du kobler fra kabelen.<\/p>\n
Legg merke til at Suite som regel bare tilbyr den nyeste tilgjengelige versjonen, ikke et fullstendig historisk oversikt over hvilken versjon som faktisk fikset hvilken s\u00e5rbarhet. Derfor er det verdt \u00e5 kjenne changelog-siden fra trinn 1, slik at du selv kan bekrefte at versjonen du havner p\u00e5 faktisk ligger etter fiksepunktet. Hvis enheten din av en eller annen grunn ikke tilbyr oppdatering automatisk, kan du laste ned firmware-filen direkte fra Trezors GitHub-repo og installere den manuelt via \u201cLegg til firmware fra fil\u201d i Suite sine avanserte innstillinger.<\/p>\n
Steg 3-4: sett opp Trezor Suite og et Ethereum-testnett<\/p>\n
Med oppdatert firmware p\u00e5 plass, g\u00e5 inn i Trezor Suite og aktiver testnett-visning under innstillinger. Legg til en Ethereum Sepolia-konto. Suite genererer en ny adresse basert p\u00e5 samme seed som resten av lommeboken, men p\u00e5 en egen avledningssti, s\u00e5 du blander aldri test-midler med ekte midler.<\/p>\n
G\u00e5 deretter til en Sepolia-faucet og be om testeter til den nye adressen. De fleste fauceter gir mellom 0,05 og 0,5 Sepolia-ETH per foresp\u00f8rsel, mer enn nok til de transaksjonene du skal gj\u00f8re i denne guiden.<\/p>\n
Grunnen til at du bygger et eget skript i stedet for bare \u00e5 bruke MetaMask direkte, er kontroll. N\u00e5r du selv konstruerer transaksjonsobjektet i kode, ser du n\u00f8yaktig hvilke felter som sendes til enheten, i motsetning til en nettleserlommebok som skjuler mye av byggeprosessen bak et grensesnitt. Det gj\u00f8r det lettere \u00e5 b\u00e5de forst\u00e5 hva som skjer og \u00e5 bevisst introdusere avvik senere n\u00e5r du skal simulere angrepsscenarioet.<\/p>\n
Installer deretter Node.js-avhengighetene du trenger for resten av prosjektet:<\/p>\n
mkdir trezor-eth-signeringstest && cd trezor-eth-signeringstest
\nnpm init -y
\nnpm install ethers@6 @trezor\/connect<\/p>\n
Steg 5: deploy en enkel test-smartkontrakt p\u00e5 Sepolia<\/p>\n
For \u00e5 teste kontraktssignering trenger du en kontrakt \u00e5 sende kalldata til. Bruk denne minimale Solidity-kontrakten, som bare lagrer en verdi og logger hvem som satte den. Den er bevisst enkel, siden form\u00e5let er \u00e5 teste signeringsflyten, ikke kontraktslogikken.<\/p>\n
\/\/ SPDX-License-Identifier: MIT
\npragma solidity ^0.8.24;<\/p>\n
contract SigningTestbed {
\n uint256 public storedValue;
\n address public lastCaller;<\/p>\n
event ValueSet(address indexed caller, uint256 value);<\/p>\n
function setValue(uint256 _value) external {
\n storedValue = _value;
\n lastCaller = msg.sender;
\n emit ValueSet(msg.sender, _value);
\n }
\n}<\/p>\n
Deploy kontrakten til Sepolia med Remix eller Hardhat, slik du normalt ville gjort. Noter deg kontraktsadressen, du trenger den i neste steg. Hele poenget med \u00e5 bruke en egen testkontrakt fremfor en ekte DeFi-protokoll er at du vet n\u00f8yaktig hva kalldataene skal inneholde, og dermed lett kan oppdage avvik.<\/p>\n
Du kan gj\u00f8re kontrakten litt mer realistisk ved \u00e5 legge til en funksjon som tar imot flere argumenter, for eksempel en adresse og et bel\u00f8p i tillegg til verdien. Det speiler bedre hvordan ekte kontraktskall til en DEX eller en utl\u00e5nsprotokoll ser ut, med flere ABI-kodede parametere pakket inn i de samme kalldataene. Jo mer kalldataene ligner det du faktisk signerer i hverdagen, desto mer relevant blir testen.<\/p>\n
Steg 6-7: bygg et signeringsskript med ethers.js og Trezor Connect<\/p>\n
N\u00e5 bygger du selve testskriptet. Det konstruerer en transaksjon som kaller setValue p\u00e5 testkontrakten, sender kalldataene til Trezor via @trezor\/connect, og logger b\u00e5de hva som ble sendt til enheten og hva den faktiske signaturen til slutt dekket.<\/p>\n
import { ethers } from «ethers»;
\nimport TrezorConnect from «@trezor\/connect»;<\/p>\n
const CONTRACT_ADDRESS = «0xDinTestkontraktAdresseHer»;
\nconst provider = new ethers.JsonRpcProvider(«https:\/\/rpc.sepolia.org»);<\/p>\n
async function signAndSend() { const iface = new ethers.Interface([ const nonce = await provider.getTransactionCount( const tx = { console.log(«Kalldata sendt til enheten:», calldata);<\/p>\n const result = await TrezorConnect.ethereumSignTransaction({ console.log(«Signatur mottatt:», result.payload); signAndSend();<\/p>\n Kj\u00f8r skriptet med node signer.js. P\u00e5 Trezor-skjermen skal du n\u00e5 se en bekreftelsesdialog som viser mottakeradresse, verdi og en tolkning av funksjonskallet setValue(42). Bekreft transaksjonen fysisk p\u00e5 enheten.<\/p>\n Legg merke til stien m\/44’\/1’\/0’\/0\/0 i koden. Coin type 1 i BIP-44-standarden er reservert for testnett, uavhengig av hvilken kjede det gjelder, mens Ethereum mainnet bruker coin type 60. Denne separasjonen p\u00e5 avledningsniv\u00e5 er en ekstra sikkerhetsmekanisme i seg selv: selv om noe skulle g\u00e5 galt i testskriptet ditt, kan det i praksis aldri ber\u00f8re n\u00f8klene som styrer hovedlommeboken din, fordi de ligger p\u00e5 en helt annen gren av samme seed.<\/p>\n Steg 8: verifiser confirmation-binding med et dekodingsskript<\/p>\n Dette er kjernen i testen. Du skal bevise for deg selv at kalldataene enheten viste p\u00e5 skjermen er n\u00f8yaktig de samme bytene som endte opp i den signerte transaksjonen, ikke bare den f\u00f8rste biten av dem. Lag en fil som dekoder den signerte, serialiserte transaksjonen og sammenligner kalldataene med det du sendte inn.<\/p>\n import { ethers } from «ethers»;<\/p>\n function verifiserCalldata(sentCalldata, signedRawTx) { console.log(«Sendt kalldata: «, sentCalldata); if (sentCalldata.toLowerCase() !== signedCalldata.toLowerCase()) { console.log(«OK: Vist og signert kalldata er identiske byte for byte.»); Kj\u00f8r denne funksjonen etter hver signering. Forventet resultat p\u00e5 en riktig oppdatert enhet er:<\/p>\n Sendt kalldata: 0x7b8d56e3000000000000000000000000000000000000000000000000000000000000002a Hvis de to verdiene noen gang skiller seg, uansett hvor liten forskjellen er, skal du stoppe og ikke sende transaksjonen videre til nettverket. Det er n\u00f8yaktig dette scenarioet CVE-2026-65058 gjorde mulig f\u00f8r fiksen.<\/p>\n Du kan gj\u00f8re denne sjekken enda strengere ved \u00e5 dekode kalldataene p\u00e5 nytt med samme ABI-interface du brukte til \u00e5 bygge dem, og sammenligne de tolkede argumentene (ikke bare den r\u00e5 hex-strengen) mot det du opprinnelig sendte inn. Det fanger opp tilfeller der noen har manipulert dataene p\u00e5 en m\u00e5te som fortsatt gir gyldig hex, men med et annet meningsinnhold, for eksempel ved \u00e5 bytte om rekkef\u00f8lgen p\u00e5 argumenter i en funksjon med flere parametere av samme type.<\/p>\n Steg 9-10: simuler et host-angrep og bekreft at patchen stopper det<\/p>\n For virkelig \u00e5 forst\u00e5 hva som ble fikset, kan du simulere angrepsscenarioet p\u00e5 en trygg m\u00e5te. Endre testskriptet slik at det bygger kalldata for setValue(1), viser denne verdien i loggen (simulerer det brukeren \u201cville sett\u201d), men i en egen test-gren bytter det ut kalldataene med setValue(999999) rett f\u00f8r de sendes til TrezorConnect.ethereumSignTransaction.<\/p>\n const visningsKalldata = iface.encodeFunctionData(«setValue», [1]); console.log(«Det brukeren tror hen signerer:», visningsKalldata);<\/p>\n const tx = { P\u00e5 en enhet med oppdatert firmware (2.12.4 eller nyere) skal skjermen vise n\u00f8yaktig setValue(999999), alts\u00e5 de reelle kalldataene, uansett hva loggen din later som brukeren \u201ctror\u201d. Det er bevis p\u00e5 at confirmation-binding-fiksen virker: enheten kan ikke lures til \u00e5 signere noe annet enn det den faktisk viser. Dette er en test du gj\u00f8r for \u00e5 bekrefte oppf\u00f8rsel, ikke et reelt angrep mot noen andre, og du kj\u00f8rer det utelukkende mot din egen testkontrakt p\u00e5 Sepolia.<\/p>\n Det er verdt \u00e5 presisere hva denne simuleringen faktisk beviser, og hva den ikke beviser. Den beviser at kalldataene som vises p\u00e5 skjermen alltid samsvarer med det som signeres, uavhengig av hva et testskript \u201clater som\u201d p\u00e5 egen logg. Den beviser ikke at Trezor er immun mot alle fremtidige svakheter i visningslogikken, for eksempel feiltolkning av kompliserte ABI-typer eller uklar fremstilling av store tall. Derfor er testen ment som en gjentakbar rutine, ikke en engangsbekreftelse du gj\u00f8r \u00e9n gang og glemmer.<\/p>\n Steg 11: automatiser firmwareoverv\u00e5king<\/p>\n Siden Trezor har sluppet flere sikkerhetsoppdateringer gjennom hele 2026, er det verdt \u00e5 sette opp et lite vaktskript som varsler deg n\u00e5r det kommer en ny release. Dette scriptet henter changelog-siden og sammenligner nyeste versjon med den du sist bekreftet.<\/p>\n #!\/bin\/bash if [ «$NYESTE» != «$SISTE_KJENTE» ]; then Legg skriptet inn i crontab slik at det kj\u00f8rer ukentlig, for eksempel hver mandag klokken 09:00. Da f\u00e5r du et varsel i terminalloggen din i stedet for \u00e5 stole p\u00e5 at du husker \u00e5 sjekke selv.<\/p>\n crontab -e Vil du ha et tydeligere varsel enn en loggfil, kan du utvide skriptet til \u00e5 sende en e-post eller en push-melding n\u00e5r det oppdager en ny versjon, i stedet for bare \u00e5 skrive til terminalen. Poenget er ikke verkt\u00f8yet i seg selv, men at du f\u00e5r et signal du faktisk legger merke til, uavhengig av om du husker \u00e5 sjekke Trezor Suite manuelt den uken.<\/p>\n Steg 12: herding \u2014 Bitcoin-only firmware og fysisk sikkerhet<\/p>\n Hvis du prim\u00e6rt oppbevarer Bitcoin og bare av og til trenger Ethereum-funksjonalitet, b\u00f8r du vurdere hvor mye angrepsflate du faktisk trenger. Trezor Safe 3 og Safe 5 tilbyr en egen Bitcoin-only firmware som fjerner all st\u00f8tte for Ethereum og andre altcoins fra enheten. F\u00e6rre signeringsflyter betyr f\u00e6rre steder en fremtidig feil kan gjemme seg. Bytt til denne firmwarevarianten via Trezor Suite hvis Ethereum-signering ikke er noe du bruker jevnlig.<\/p>\n Uansett hvilken firmwarevariant du velger, er det verdt \u00e5 huske at alle Trezor-enheter bruker et sertifisert EAL6+ Secure Element sammen med en ekstern mikrokontroller. Signeringslogikken for enkelte operasjoner kj\u00f8rer delvis utenfor selve det sertifiserte elementet, noe som gj\u00f8r fysisk sikkerhet like viktig som firmwareoppdateringer. Oppbevar enheten et sted uvedkommende ikke har tilgang til, bruk PIN og eventuelt passordfrase, og unng\u00e5 \u00e5 la enheten ligge ubevoktet p\u00e5 reise.<\/p>\n PIN-koden p\u00e5 Trezor Safe 7 kan v\u00e6re opptil 50 sifre, langt mer enn de fire til ni sifrene mange brukere fortsatt n\u00f8yer seg med. En lengre PIN koster deg noen ekstra sekunder ved hver innlogging, men gj\u00f8r et brute force-fors\u00f8k mot enheten praktisk talt h\u00e5pl\u00f8st innenfor rimelig tid. Kombiner dette med en passordfrase lagret et annet sted enn selve seed-backupen, slik at et fysisk tyveri av bare enheten eller bare backupkortene ikke er nok til \u00e5 t\u00f8mme lommeboken.<\/p>\n Til slutt, hold et \u00f8ye med hvilke tredjeparts dApp-tilkoblinger du godkjenner. CVE-2026-65058 krevde nettopp en kompromittert vert for \u00e5 kunne utnyttes, noe som betyr at den beste beskyttelsen utover oppdatert firmware er sunn skepsis til hvilke nettsider og wallet-connect-foresp\u00f8rsler du kobler enheten din til i utgangspunktet.<\/p>\n Komplett testprosjekt: mappestruktur<\/p>\n N\u00e5r du har fulgt alle stegene over, b\u00f8r prosjektmappen din se omtrent slik ut. Dette gir deg et gjenbrukbart oppsett du kan kj\u00f8re igjen etter hver fremtidige firmwareoppdatering.<\/p>\n trezor-eth-signeringstest\/ README-filen b\u00f8r inneholde adressen til testkontrakten din, hvilken avledningssti du brukte, og datoen for siste vellykkede test. Da har du et konkret loggpunkt \u00e5 vise til neste gang du oppdaterer firmware.<\/p>\n Legg gjerne til noen faste npm-skript i package.json, slik at hele testrutinen kan kj\u00f8res med \u00e9n kommando i stedet for at du m\u00e5 huske rekkef\u00f8lgen p\u00e5 filene selv:<\/p>\n { Med dette oppsettet kj\u00f8rer du hele verifiseringsl\u00f8pet med npm run test:full etter hver firmwareoppdatering, uten \u00e5 m\u00e5tte huske de enkelte trinnene manuelt hver gang.<\/p>\n Andre sikkerhetshull Trezor har rettet i 2026<\/p>\n CVE-2026-65058 var ikke den eneste s\u00e5rbarheten Trezors sikkerhetsportal offentliggjorde i 2026. Selskapet driver et l\u00f8pende program der forskere rapporterer funn som blir unders\u00f8kt og rettet f\u00f8r de publiseres. Tabellen under viser et utvalg av s\u00e5rbarhetene som ble l\u00f8st i samme periode.<\/p>\n M\u00f8nsteret er tydelig: de fleste feilene handler om avstanden mellom det som faktisk signeres eller autoriseres, og det brukeren f\u00e5r se p\u00e5 skjermen. Det underbygger hvorfor testen du nettopp har bygget er verdt \u00e5 gjenta etter hver fremtidige firmwareoppdatering, ikke bare denne ene gangen.<\/p>\n Trezor publiserer disse funnene \u00e5pent p\u00e5 sitt sikkerhetsportal i stedet for \u00e5 tie dem i hjel, med status merket \u201cl\u00f8st\u201d for hver enkelt sak sammen med rapporteringsdato. Den samme \u00e5penheten gjelder GitHub-repoet, der du selv kan lese commit-historikken og se n\u00f8yaktig hvilke linjer kode som ble endret for \u00e5 lukke CVE-2026-65058. Denne graden av innsyn er en av grunnene til at det i det hele tatt er mulig \u00e5 bygge en uavhengig verifiseringstest slik du har gjort i denne guiden, i stedet for \u00e5 m\u00e5tte stole blindt p\u00e5 produsentens egne p\u00e5stander.<\/p>\n Vanlige fallgruver<\/p>\n Felles for de fleste av disse fallgruvene er at de handler om vaner, ikke om tekniske ferdigheter. \u00c5 bygge testprosjektet krever litt innsats f\u00f8rste gang, men \u00e5 faktisk bruke det konsekvent etter hver oppdatering er den delen mange hopper over i praksis. Sett derfor av tid til \u00e5 gj\u00f8re testrutinen til en fast vane, ikke bare en engangs\u00f8velse du gjorde mens artikkelen var fersk.<\/p>\n Feils\u00f8king: 8 vanlige problemer og l\u00f8sninger<\/p>\n De fleste problemene du st\u00f8ter p\u00e5 underveis handler om tilkobling, timing eller sm\u00e5 feil i hvordan kalldata bygges, ikke om selve sikkerhetslogikken. Tabellen under dekker de vanligste tilfellene som dukker opp f\u00f8rste gang noen setter opp dette prosjektet.<\/p>\n Avanserte tips for videre sikkerhet<\/p>\n N\u00e5r grunnoppsettet fungerer, kan du utvide testprosjektet videre. Legg til flere testkontrakter med mer kompleks ABI-koding, inkludert n\u00f8stede structs og dynamiske arrays, siden dette er datatyper der visningslogikk historisk har v\u00e6rt vanskeligere \u00e5 f\u00e5 riktig. Test ogs\u00e5 EIP-1559-transaksjoner spesifikt, siden det var en av de to signeringsflytene som CVE-2026-65058 rammet direkte.<\/p>\n Vurder \u00e5 sette opp testen som en del av en CI-pipeline hvis du utvikler en wallet-integrasjon selv. Da kj\u00f8res confirmation-binding-sjekken automatisk hver gang du endrer kode som bygger transaksjoner, i stedet for at noen m\u00e5 huske \u00e5 teste det manuelt. En praktisk fallgruve her er at CI-servere sjelden har en fysisk Trezor koblet til, s\u00e5 du m\u00e5 enten kj\u00f8re denne delen av testsuiten lokalt f\u00f8r merge, eller sette opp en dedikert testmaskin med en enhet reservert kun til dette form\u00e5let.<\/p>\n Hvis du jobber i et team, er det verdt \u00e5 dele testprosjektet som et internt verkt\u00f8y i stedet for at hver utvikler bygger sin egen variant. Det sikrer at alle bruker samme testkontrakt, samme sjekker og samme forventede resultat, noe som gj\u00f8r det langt enklere \u00e5 oppdage om en ny firmwareversjon faktisk endrer oppf\u00f8rsel fra forrige gang dere testet.<\/p>\n Til slutt, sett en fast rutine: hver gang Trezor slipper ny firmware, kj\u00f8r hele testsuiten din p\u00e5 nytt f\u00f8r du stoler p\u00e5 enheten til nye kontraktsinteraksjoner. Det tar under fem minutter n\u00e5r prosjektet f\u00f8rst er bygget, og det er langt billigere enn \u00e5 oppdage et avvik etter at en ekte transaksjon er sendt.<\/p>\n Byggeklossene i denne guiden er ikke unike for Trezor. Prinsippet, \u00e5 sammenligne det som vises p\u00e5 en tillitsenhet med det som faktisk godkjennes kryptografisk, gjelder for enhver hardware-lommebok, enhver signeringsprotokoll og i prinsippet enhver godkjenningsmekanisme der et menneske skal godkjenne noe en maskin har generert. Har du f\u00f8rst forst\u00e5tt og bygget denne testen for Ethereum-signering, er det et lite steg videre til \u00e5 teste tilsvarende for Solana-transaksjoner eller for autorisasjonsmeldinger i andre protokoller du bruker.<\/p>\n Kilder: Trezors sikkerhetsportal<\/a>, SentinelOnes CVE-database<\/a>, Trezors firmware-changelog<\/a>, Trezor Safe 3 spesifikasjoner<\/a> og ethers.js v6-dokumentasjonen<\/a>.<\/p>\n Ofte stilte sp\u00f8rsm\u00e5l<\/p>\n Er min Trezor fortsatt s\u00e5rbar for CVE-2026-65058?<\/p>\n Ikke hvis du kj\u00f8rer firmware 2.12.4 eller nyere p\u00e5 Safe 3, Safe 5 eller Safe 7. Sjekk versjonen med trezorctl slik beskrevet i steg 1-2, og oppdater via Trezor Suite hvis du er usikker.<\/p>\n P\u00e5virket s\u00e5rbarheten ogs\u00e5 Bitcoin-signering?<\/p>\n Nei. If\u00f8lge Trezors egen beskrivelse og SentinelOnes tekniske analyse var feilen isolert til Ethereum-signeringsflytene sign_tx og sign_tx_eip1559, alts\u00e5 kontraktsinteraksjoner p\u00e5 Ethereum, ikke Bitcoin-transaksjoner.<\/p>\n Trenger jeg \u00e5 flytte midlene mine hvis jeg har brukt en s\u00e5rbar firmwareversjon?<\/p>\n S\u00e5rbarheten krevde en kompromittert vertsapplikasjon som aktivt utnyttet feilen under en signering, den ga ikke en angriper direkte tilgang til seed eller n\u00f8kler i etterkant. Har du bekreftet transaksjoner som faktisk gikk gjennom med forventet mottaker og bel\u00f8p, er det ingen automatisk grunn til \u00e5 flytte midler. Er du usikker p\u00e5 om en tidligere transaksjon var korrekt, b\u00f8r du sjekke den historiske transaksjonen p\u00e5 en blokkutforsker som Etherscan, og sammenligne mottaker og bel\u00f8p mot det du selv husker \u00e5 ha godkjent.<\/p>\n Kan jeg bruke samme testoppsett p\u00e5 Ledger-enheter?<\/p>\n Ikke direkte. Denne guiden bruker @trezor\/connect, som er spesifikt for Trezor-enheter. Ledger har et eget SDK med annen API-struktur, men selve prinsippet, \u00e5 sammenligne vist kalldata med signert kalldata, kan gjenbrukes uansett produsent.<\/p>\n Hvor ofte b\u00f8r jeg kj\u00f8re denne testen p\u00e5 nytt?<\/p>\n Etter hver firmwareoppdatering, og gjerne som en fast vane et par ganger i \u00e5ret selv uten oppdateringer. Vaktskriptet fra steg 11 hjelper deg \u00e5 huske n\u00e5r en ny versjon er tilgjengelig.<\/p>\n Er Bitcoin-only firmware bedre for sikkerheten min?<\/p>\n Hvis du ikke trenger Ethereum eller andre altcoins p\u00e5 enheten, reduserer Bitcoin-only firmware angrepsflaten ved \u00e5 fjerne de signeringsflytene som ikke gjelder Bitcoin. Det er ikke en universell l\u00f8sning for alle, men et reelt herdingsvalg for brukere med et smalere behov. Husk at du kan bytte tilbake til universell firmware senere hvis behovet ditt endrer seg, uten \u00e5 miste tilgang til midlene dine, siden seed-en forblir den samme uavhengig av hvilken firmwarevariant enheten kj\u00f8rer.<\/p>\n Hvem oppdaget CVE-2026-65058?<\/p>\n If\u00f8lge Trezors sikkerhetsportal ble s\u00e5rbarheten rapportert av en forsker med brukernavnet LoopGhost 16. mai 2026, gjennom selskapets program for ansvarlig rapportering av s\u00e5rbarheter.<\/p>\n M\u00e5 jeg installere universell firmware for \u00e5 teste Ethereum-signering?<\/p>\n Ja. Bitcoin-only firmware st\u00f8tter ikke Ethereum-signeringsflytene i det hele tatt, s\u00e5 du m\u00e5 kj\u00f8re universell firmware p\u00e5 enheten mens du gjennomf\u00f8rer testene i denne guiden. Bytt tilbake til Bitcoin-only etterp\u00e5 hvis det er det du normalt bruker.<\/p>\n","protected":false},"excerpt":{"rendered":"Sommeren 2026 fikk Trezor-brukere en p\u00e5minnelse om at en hardware-lommebok bare er s\u00e5 sikker som firmwaren som kj\u00f8rer…\n","protected":false},"author":2,"featured_media":345270,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_share_on_mastodon":"0"},"categories":[57],"tags":[30,28,29,65,63,64,66,70,69,67,68],"class_list":["post-345269","post","type-post","status-publish","format-standard","has-post-thumbnail","category-vitenskap-og-teknologi","tag-no","tag-norge","tag-norway","tag-science","tag-science-and-technology","tag-scienceandtechnology","tag-technology","tag-teknologi","tag-vitenskap","tag-vitenskap-og-teknologi","tag-vitenskapteknologi"],"share_on_mastodon":{"url":"https:\/\/pubeurope.com\/@no\/117220175068383309","error":""},"_links":{"self":[{"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/posts\/345269","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/comments?post=345269"}],"version-history":[{"count":0,"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/posts\/345269\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/media\/345270"}],"wp:attachment":[{"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/media?parent=345269"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/categories?post=345269"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.europesays.com\/no\/wp-json\/wp\/v2\/tags?post=345269"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\n await TrezorConnect.init({
\n manifest: { email: «[email\u00a0protected]<\/a>«, appUrl: «https:\/\/example.com» },
\n });<\/p>\n
\n «function setValue(uint256 _value)»,
\n ]);
\n const calldata = iface.encodeFunctionData(«setValue», [42]);<\/p>\n
\n «0xDinTestAdresseHer»,
\n «pending»
\n );
\n const feeData = await provider.getFeeData();<\/p>\n
\n to: CONTRACT_ADDRESS,
\n value: «0x0»,
\n data: calldata,
\n chainId: 11155111, \/\/ Sepolia
\n nonce: «0x» + nonce.toString(16),
\n gasLimit: «0x186a0»,
\n maxFeePerGas: feeData.maxFeePerGas.toString(16),
\n maxPriorityFeePerGas: feeData.maxPriorityFeePerGas.toString(16),
\n };<\/p>\n
\n path: «m\/44’\/1’\/0’\/0\/0»,
\n transaction: tx,
\n });<\/p>\n
\n}<\/p>\n
\n const parsed = ethers.Transaction.from(signedRawTx);
\n const signedCalldata = parsed.data;<\/p>\n
\n console.log(«Signert kalldata: «, signedCalldata);<\/p>\n
\n console.error(
\n «AVVIK: Signaturen dekker andre kalldata enn det som ble vist!»
\n );
\n process.exit(1);
\n }<\/p>\n
\n}<\/p>\n
\nSignert kalldata: 0x7b8d56e3000000000000000000000000000000000000000000000000000000000000002a
\nOK: Vist og signert kalldata er identiske byte for byte.<\/p>\n
\nconst faktiskKalldata = iface.encodeFunctionData(«setValue», [999999]);<\/p>\n
\n to: CONTRACT_ADDRESS,
\n value: «0x0»,
\n data: faktiskKalldata, \/\/ Simulerer manipulasjon
\n chainId: 11155111,
\n nonce: «0x» + nonce.toString(16),
\n gasLimit: «0x186a0»,
\n maxFeePerGas: feeData.maxFeePerGas.toString(16),
\n maxPriorityFeePerGas: feeData.maxPriorityFeePerGas.toString(16),
\n};<\/p>\n
\nSISTE_KJENTE=»2.12.4″
\nSIDE=$(curl -s «https:\/\/trezor.io\/other\/product-updates\/trezor-firmware-changelog-all-versions-and-release-dates»)
\nNYESTE=$(echo «$SIDE» | grep -oP ‘\\d+\\.\\d+\\.\\d+’ | head -1)<\/p>\n
\n echo «Ny firmwareversjon tilgjengelig: $NYESTE (du har $SISTE_KJENTE)»
\nelse
\n echo «Du kj\u00f8rer nyeste kjente versjon: $SISTE_KJENTE»
\nfi<\/p>\n
\n# Legg til denne linjen:
\n0 9 * * 1 \/sti\/til\/check-firmware.sh >> \/sti\/til\/firmware.log 2>&1<\/p>\n
\n\u251c\u2500\u2500 package.json
\n\u251c\u2500\u2500 contracts\/
\n\u2502 \u2514\u2500\u2500 SigningTestbed.sol
\n\u251c\u2500\u2500 scripts\/
\n\u2502 \u251c\u2500\u2500 signer.js # Steg 6-7: bygger og sender transaksjonen
\n\u2502 \u251c\u2500\u2500 verify-calldata.js # Steg 8: sammenligner vist vs. signert data
\n\u2502 \u2514\u2500\u2500 simulate-attack.js # Steg 9-10: tester confirmation-binding
\n\u251c\u2500\u2500 monitor\/
\n\u2502 \u2514\u2500\u2500 check-firmware.sh # Steg 11: ukentlig firmwaresjekk
\n\u2514\u2500\u2500 README.md<\/p>\n
\n «scripts»: {
\n «sign»: «node scripts\/signer.js»,
\n «verify»: «node scripts\/verify-calldata.js»,
\n «simulate»: «node scripts\/simulate-attack.js»,
\n «test:full»: «npm run sign && npm run verify && npm run simulate»
\n }
\n}<\/p>\nS\u00e5rbarhetDato rapportert\/l\u00f8stKort beskrivelse<\/tr>\n \n Ethereum SLIP-24 calldata-bekreftelse (CVE-2026-65058)<\/td>\n 16. mai 2026<\/td>\n Bare f\u00f8rste kalldata-bit ble vist, resten signert usett<\/td>\n<\/tr>\n \n Solana token-overf\u00f8ring, mottaker-spoofing via Address Lookup Table<\/td>\n 1. juni 2026<\/td>\n Mottakeradresse kunne fremst\u00e5 annerledes enn den reelle<\/td>\n<\/tr>\n \n CoinJoin-koordineringsgebyr ikke vist ved autorisasjon<\/td>\n 3. juni 2026<\/td>\n Gebyrtaket ble ikke tydelig presentert for brukeren<\/td>\n<\/tr>\n \n Solana signeringsvisning, forbedring<\/td>\n 12. juni 2026<\/td>\n Uklar visning av signerte Solana-detaljer<\/td>\n<\/tr>\n \n Solana kontoopprettelse, bekreftelse ufullstendig<\/td>\n 14. juni 2026<\/td>\n Ikke all relevant informasjon vist ved kontoopprettelse<\/td>\n<\/tr>\n \n Desktop-oppdatering kunne installeres f\u00f8r signaturverifisering var fullf\u00f8rt<\/td>\n 16. juni 2026<\/td>\n Rekkef\u00f8lgefeil i oppdateringsprosessen for Trezor Suite<\/td>\n<\/tr>\n \n THP-paring kunne fullf\u00f8res uten paringskode<\/td>\n 22. juni 2026<\/td>\n Svakhet i parringsprotokollen mellom enhet og vert<\/td>\n<\/tr>\n \n
ProblemSannsynlig \u00e5rsakL\u00f8sning<\/tr>\n \n trezorctl finner ikke enheten<\/td>\n Manglende USB-tilgang eller udev-regler (Linux)<\/td>\n Installer udev-reglene fra python-trezor sitt GitHub-repo, koble til p\u00e5 nytt<\/td>\n<\/tr>\n \n Firmwareoppdatering henger p\u00e5 \u201cInstallerer\u201d<\/td>\n USB-kabelen leverer for lite str\u00f8m eller data er ustabil<\/td>\n Bruk kabelen som fulgte med enheten, koble direkte til datamaskinen, ikke via hub<\/td>\n<\/tr>\n \n TrezorConnect.init() feiler med manifest-feil<\/td>\n Manifest-objektet mangler gyldig e-post eller URL<\/td>\n Fyll inn et gyldig e-postfelt og en faktisk URL, selv i test<\/td>\n<\/tr>\n \n Signeringsforesp\u00f8rselen timer ut<\/td>\n Enheten venter p\u00e5 fysisk bekreftelse som ikke blir gitt innen tidsfristen<\/td>\n Trykk bekreft p\u00e5 enheten raskere, eller \u00f8k timeout i skriptet<\/td>\n<\/tr>\n \n Sepolia RPC svarer med feil eller er nede<\/td>\n Offentlig RPC-endepunkt er overbelastet<\/td>\n Bytt til en alternativ Sepolia RPC-leverand\u00f8r eller kj\u00f8r egen node<\/td>\n<\/tr>\n \n Kalldata i skjermen matcher ikke det du forventet<\/td>\n Feil i ABI-encoding eller feil funksjonssignatur i skriptet<\/td>\n Dobbeltsjekk interface-definisjonen mot kontraktens faktiske funksjon<\/td>\n<\/tr>\n \n verify-calldata.js rapporterer avvik selv med korrekt firmware<\/td>\n Feil i egen sammenligningslogikk, for eksempel store\/sm\u00e5 bokstaver i hex<\/td>\n Normaliser begge strenger til sm\u00e5 bokstaver f\u00f8r sammenligning<\/td>\n<\/tr>\n \n trezorctl viser feil modellnavn<\/td>\n Flere Trezor-enheter tilkoblet samtidig<\/td>\n Koble fra alle andre enheter og pr\u00f8v igjen med kun \u00e9n tilkoblet<\/td>\n<\/tr>\n