Sommeren 2026 fikk Trezor-brukere en påminnelse om at en hardware-lommebok bare er så sikker som firmwaren som kjører på den. En sårbarhet kalt CVE-2026-65058 gjorde det mulig for en ondsinnet vertsapplikasjon å endre innholdet i en Ethereum-transaksjon etter at brukeren hadde bekreftet den på skjermen. Feilen rammet Trezor Safe 3, Safe 5 og Safe 7, og den brøt akkurat det prinsippet hardware-lommebøker selger seg inn på: at det du ser på skjermen, er det du signerer. Denne guiden viser deg, steg for steg, hvordan du selv tester om enheten din er sårbar, hvordan du oppdaterer riktig, og hvordan du bygger et lite prosjekt som lar deg verifisere Ethereum-signering fra en Trezor på egen hånd.

  1. Bakgrunn: dette gjorde CVE-2026-65058 med Ethereum-signeringen
  2. What-You-See-Is-What-You-Sign: prinsippet feilen brøt
  3. Hvorfor dette angår norske og nordiske Trezor-brukere
  4. Forutsetninger: verktøy og versjoner du trenger
  5. Trezor Safe 3, Safe 5 og Safe 7: hva betyr modellvalget for testen
  6. Steg 1-2: sjekk enhet og oppdater til riktig firmware
  7. Steg 3-4: sett opp Trezor Suite og et Ethereum-testnett
  8. Steg 5: deploy en enkel test-smartkontrakt på Sepolia
  9. Steg 6-7: bygg et signeringsskript med ethers.js og Trezor Connect
  10. Steg 8: verifiser confirmation-binding med et dekodingsskript
  11. Steg 9-10: simuler et host-angrep og bekreft at patchen stopper det
  12. Steg 11: automatiser firmwareovervåking
  13. Steg 12: herding — Bitcoin-only firmware og fysisk sikkerhet
  14. Komplett testprosjekt: mappestruktur
  15. Andre sikkerhetshull Trezor har rettet i 2026
  16. Vanlige fallgruver
  17. Feilsøking: 8 vanlige problemer og løsninger
  18. Avanserte tips for videre sikkerhet
  19. Ofte stilte spørsmål
    1. Er min Trezor fortsatt sårbar for CVE-2026-65058?
    2. Påvirket sårbarheten også Bitcoin-signering?
    3. Trenger jeg å flytte midlene mine hvis jeg har brukt en sårbar firmwareversjon?
    4. Kan jeg bruke samme testoppsett på Ledger-enheter?
    5. Hvor ofte bør jeg kjøre denne testen på nytt?
    6. Er Bitcoin-only firmware bedre for sikkerheten min?
    7. Hvem oppdaget CVE-2026-65058?
    8. Må jeg installere universell firmware for å teste Ethereum-signering?

Du trenger ingen forkunnskaper utover litt erfaring med terminalen og JavaScript. Alt du bygger underveis kjører mot Sepolia-testnettet, så du risikerer ingen ekte midler mens du lærer.

Guiden dekker hele løpet fra å identifisere firmwareversjonen din, via å bygge et lite Node.js-prosjekt som snakker direkte med enheten, til å simulere selve angrepsscenarioet på en trygg testkontrakt. Underveis lærer du hvordan Ethereum-signering på en hardware-lommebok faktisk fungerer under panseret, ikke bare hvordan du klikker “bekreft”. Det gjør deg i stand til å vurdere fremtidige sikkerhetsvarsler selv, i stedet for å måtte stole blindt på produsentens egne forsikringer.

Bakgrunn: dette gjorde CVE-2026-65058 med Ethereum-signeringen

Når 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å i at enheten bare viste den første biten med kalldata til brukeren for bekreftelse, mens den fortsatte å hasje inn resten av bitene uten noe tilsvarende varsel. Signaturen som til slutt ble produsert, dekket altså langt mer data enn det brukeren faktisk fikk se og godkjenne.

SentinelOne beskriver feilen som en “confirmation-binding”-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å skjermen mens den faktiske signaturen dekket en helt annen mottaker, et annet beløp eller andre ABI-kodede parametere. Trezor selv beskriver sårbarheten på sitt sikkerhetsportal som en feil i SLIP-24-grenen for verifiserte swap-transaksjoner, der en beskyttelse mot ekstra kalldata ikke var aktiv i produksjonsfirmware.

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å GitHub. Fiksen endrer core/src/apps/ethereum/layout.py slik at kalldata bekreftes underveis i hasjingen, ikke bare i det første steget. Dermed blir de bytene som vises på skjermen, alltid de samme bytene som til slutt signeres.

What-You-See-Is-What-You-Sign: prinsippet feilen brøt

Hardware-lommebøker bygger på et enkelt løfte som ofte forkortes WYSIWYS: det du ser på skjermen, er det du signerer. Løftet 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ære 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.

For enkle overføringer er dette prinsippet lett å håndheve. Mottaker og beløp passer på en liten skjerm uten problemer. Kontraktskall er vanskeligere, siden kalldata ofte er hundrevis av byte kodet i hexadesimal form, umulig å lese for et menneske uten videre tolkning. Trezor og andre produsenter løser dette ved å 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å dataene, men signerte alt som kom etterpå uten å knytte de to sammen kryptografisk på riktig måte.

Det tekniske begrepet SentinelOne bruker, confirmation-binding, beskriver akkurat dette gapet. En sikker implementasjon må garantere at hasjen som til slutt signeres er beregnet over nøyaktig de samme bytene brukeren fikk presentert, verken mer eller mindre. Når 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å å sammenligne rå byte-for-byte data, ikke bare å se at “en dialog dukket opp”.

Hvorfor dette angår norske og nordiske Trezor-brukere

Hardware-lommebøker har blitt standardanbefalingen for alle som oppbevarer krypto over lengre tid i Norden, nettopp fordi de flytter signeringsnøkkelen bort fra en internettkoblet PC eller mobil. Poenget forsvinner delvis hvis selve signeringsflyten kan manipuleres av en kompromittert klient på den samme PC-en. Mange nordiske brukere kobler Trezor-en sin til DeFi-protokoller, NFT-markedsplasser og bro-tjenester på Ethereum, altså nøyaktig de kontraktsinteraksjonene som CVE-2026-65058 rammet.

Sårbarheten krevde riktignok en kompromittert vert, ikke bare fysisk tilgang til enheten. Det gjør 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 å skape frykt, men å gi deg et konkret verktøy for å teste at oppdateringen faktisk virker hos deg, i stedet for bare å stole på at “det er fikset nå”.

Det er også en praktisk grunn til at nordiske brukere spesielt bør ta eierskap til denne typen verifisering selv. Norge, Sverige, Danmark og Finland ligger høyt på både 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 å bare la kryptoen ligge urørt. Hver ekstra kontraktsinteraksjon er en ny mulighet for et signeringsavvik å slippe gjennom ubemerket, og da er det bedre å ha et testoppsett liggende klart enn å stole på at man ville lagt merke til noe unormalt med det blotte øyet.

Forutsetninger: verktøy og versjoner du trenger

Sett av 45-60 minutter til hele oppsettet. Du trenger følgende verktøy installert før du starter:

VerktøyVersjon brukt i denne guidenFormål Trezor Safe 3, 5 eller 7 Firmware 2.12.4 (utgitt 19. august 2026) eller nyere Enheten som skal testes Trezor Suite Nyeste stabile versjon fra trezor.io Firmwareoppdatering og enhetsstyring trezorctl (python-trezor) Nyeste versjon via pip Kommandolinjeverktøy for å lese firmwaredetaljer Node.js 20 LTS eller nyere Kjøre testskript ethers.js v6 Bygge og sende Ethereum-transaksjoner @trezor/connect Nyeste versjon fra npm Kommunisere med Trezor fra JavaScript Sepolia-testnett – Testmiljø uten ekte midler

Du trenger også litt Sepolia-ETH fra en faucet for å betale gebyr på testkontrakten. Bruk aldri hovedlommeboken din eller ekte midler til denne testen. Hele poenget er å øve på en isolert transaksjon der du uansett ikke taper noe hvis noe går galt.

Trezor Safe 3, Safe 5 og Safe 7: hva betyr modellvalget for testen

Alle tre modellene ble rammet av CVE-2026-65058, og alle tre kan testes med nøyaktig samme prosjekt i denne guiden, siden @trezor/connect abstraherer bort de fleste maskinvareforskjellene. Det er likevel greit å vite hva som faktisk skiller dem, spesielt fordi skjermstørrelse påvirker hvor mye av kalldataene du realistisk kan lese før du bekrefter.

ModellSkjermSikkerhetsarkitekturRelevans for denne testen Trezor Safe 3 0,96″ monokrom OLED, 128×64 piksler, to knapper Ett EAL6+ Secure Element, ekstern ARM Cortex M4-mikrokontroller på 180MHz Minst skjermplass, viktigst å lese kalldata-oppsummeringen nøye Trezor Safe 5 1,54″ fargeskjerm, 240×240 piksler, touch med haptisk tilbakemelding NDA-fritt EAL6+ Secure Element, Gorilla Glass 3-overflate Bedre lesbarhet for lengre kalldata-strenger Trezor Safe 7 2,5″ fargeskjerm, 520×380 piksler, touch To Secure Elements pluss egen MCU (“tre lag maskinvaresikkerhet”), kvantesikkerhetsklar arkitektur Best egnet til å vise fullstendige, komplekse kontraktskall

Safe 7 skiller seg mest ut arkitektonisk, med to separate Secure Elements og trådløs Bluetooth 5.0-tilkobling i tillegg til USB-C, samt et LiFePO4-batteri på 3,2V og 330mAh som lades trådløst via Qi2. Trezor markedsfører den som sin første 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ører en fikset firmwareversjon, siden confirmation-binding-feilen lå i den delte Ethereum-signeringskoden som alle tre modellene baserer seg på.

Steg 1-2: sjekk enhet og oppdater til riktig firmware

Det første du skal gjøre er å finne ut nøyaktig hvilken firmwareversjon enheten din kjører nå. Koble Trezor-en til med USB-C-kabelen som fulgte med, og kjør følgende kommando i terminalen:

pip install trezor
trezorctl device features | grep -i version

Et typisk svar ser slik ut:

major_version: 2
minor_version: 12
patch_version: 2
model: T2B1

Hvis patch_version viser 2 eller lavere på 2.12-grenen, kjører du en versjon som ble sluppet før eller rett rundt CVE-fiksen, og du bør 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 å være helt sikker på at du har med fiksen fra commit 70c9b0c07748, oppdater til minst 2.12.4.

Åpne Trezor Suite, koble til enheten, og klikk på varselet om tilgjengelig firmwareoppdatering. Bekreft handlingen på selve enhetens skjerm, ikke bare i appen. Vent til Suite viser “Firmware er oppdatert” før du kobler fra kabelen.

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årbarhet. Derfor er det verdt å kjenne changelog-siden fra trinn 1, slik at du selv kan bekrefte at versjonen du havner på 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 “Legg til firmware fra fil” i Suite sine avanserte innstillinger.

Steg 3-4: sett opp Trezor Suite og et Ethereum-testnett

Med oppdatert firmware på plass, gå inn i Trezor Suite og aktiver testnett-visning under innstillinger. Legg til en Ethereum Sepolia-konto. Suite genererer en ny adresse basert på samme seed som resten av lommeboken, men på en egen avledningssti, så du blander aldri test-midler med ekte midler.

Gå 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ørsel, mer enn nok til de transaksjonene du skal gjøre i denne guiden.

Grunnen til at du bygger et eget skript i stedet for bare å bruke MetaMask direkte, er kontroll. Når du selv konstruerer transaksjonsobjektet i kode, ser du nøyaktig hvilke felter som sendes til enheten, i motsetning til en nettleserlommebok som skjuler mye av byggeprosessen bak et grensesnitt. Det gjør det lettere å både forstå hva som skjer og å bevisst introdusere avvik senere når du skal simulere angrepsscenarioet.

Installer deretter Node.js-avhengighetene du trenger for resten av prosjektet:

mkdir trezor-eth-signeringstest && cd trezor-eth-signeringstest
npm init -y
npm install ethers@6 @trezor/connect

Steg 5: deploy en enkel test-smartkontrakt på Sepolia

For å teste kontraktssignering trenger du en kontrakt å 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ålet er å teste signeringsflyten, ikke kontraktslogikken.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract SigningTestbed {
uint256 public storedValue;
address public lastCaller;

event ValueSet(address indexed caller, uint256 value);

function setValue(uint256 _value) external {
storedValue = _value;
lastCaller = msg.sender;
emit ValueSet(msg.sender, _value);
}
}

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 å bruke en egen testkontrakt fremfor en ekte DeFi-protokoll er at du vet nøyaktig hva kalldataene skal inneholde, og dermed lett kan oppdage avvik.

Du kan gjøre kontrakten litt mer realistisk ved å legge til en funksjon som tar imot flere argumenter, for eksempel en adresse og et beløp i tillegg til verdien. Det speiler bedre hvordan ekte kontraktskall til en DEX eller en utlånsprotokoll 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.

Steg 6-7: bygg et signeringsskript med ethers.js og Trezor Connect

Nå bygger du selve testskriptet. Det konstruerer en transaksjon som kaller setValue på testkontrakten, sender kalldataene til Trezor via @trezor/connect, og logger både hva som ble sendt til enheten og hva den faktiske signaturen til slutt dekket.

import { ethers } from «ethers»;
import TrezorConnect from «@trezor/connect»;

const CONTRACT_ADDRESS = «0xDinTestkontraktAdresseHer»;
const provider = new ethers.JsonRpcProvider(«https://rpc.sepolia.org»);

async function signAndSend() {
await TrezorConnect.init({
manifest: { email: «[email protected]«, appUrl: «https://example.com» },
});

const iface = new ethers.Interface([
«function setValue(uint256 _value)»,
]);
const calldata = iface.encodeFunctionData(«setValue», [42]);

const nonce = await provider.getTransactionCount(
«0xDinTestAdresseHer»,
«pending»
);
const feeData = await provider.getFeeData();

const tx = {
to: CONTRACT_ADDRESS,
value: «0x0»,
data: calldata,
chainId: 11155111, // Sepolia
nonce: «0x» + nonce.toString(16),
gasLimit: «0x186a0»,
maxFeePerGas: feeData.maxFeePerGas.toString(16),
maxPriorityFeePerGas: feeData.maxPriorityFeePerGas.toString(16),
};

console.log(«Kalldata sendt til enheten:», calldata);

const result = await TrezorConnect.ethereumSignTransaction({
path: «m/44’/1’/0’/0/0»,
transaction: tx,
});

console.log(«Signatur mottatt:», result.payload);
}

signAndSend();

Kjør skriptet med node signer.js. På Trezor-skjermen skal du nå se en bekreftelsesdialog som viser mottakeradresse, verdi og en tolkning av funksjonskallet setValue(42). Bekreft transaksjonen fysisk på enheten.

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å avledningsnivå er en ekstra sikkerhetsmekanisme i seg selv: selv om noe skulle gå galt i testskriptet ditt, kan det i praksis aldri berøre nøklene som styrer hovedlommeboken din, fordi de ligger på en helt annen gren av samme seed.

Steg 8: verifiser confirmation-binding med et dekodingsskript

Dette er kjernen i testen. Du skal bevise for deg selv at kalldataene enheten viste på skjermen er nøyaktig de samme bytene som endte opp i den signerte transaksjonen, ikke bare den første biten av dem. Lag en fil som dekoder den signerte, serialiserte transaksjonen og sammenligner kalldataene med det du sendte inn.

import { ethers } from «ethers»;

function verifiserCalldata(sentCalldata, signedRawTx) {
const parsed = ethers.Transaction.from(signedRawTx);
const signedCalldata = parsed.data;

console.log(«Sendt kalldata: «, sentCalldata);
console.log(«Signert kalldata: «, signedCalldata);

if (sentCalldata.toLowerCase() !== signedCalldata.toLowerCase()) {
console.error(
«AVVIK: Signaturen dekker andre kalldata enn det som ble vist!»
);
process.exit(1);
}

console.log(«OK: Vist og signert kalldata er identiske byte for byte.»);
}

Kjør denne funksjonen etter hver signering. Forventet resultat på en riktig oppdatert enhet er:

Sendt kalldata: 0x7b8d56e3000000000000000000000000000000000000000000000000000000000000002a
Signert kalldata: 0x7b8d56e3000000000000000000000000000000000000000000000000000000000000002a
OK: Vist og signert kalldata er identiske byte for byte.

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øyaktig dette scenarioet CVE-2026-65058 gjorde mulig før fiksen.

Du kan gjøre denne sjekken enda strengere ved å dekode kalldataene på nytt med samme ABI-interface du brukte til å bygge dem, og sammenligne de tolkede argumentene (ikke bare den rå hex-strengen) mot det du opprinnelig sendte inn. Det fanger opp tilfeller der noen har manipulert dataene på en måte som fortsatt gir gyldig hex, men med et annet meningsinnhold, for eksempel ved å bytte om rekkefølgen på argumenter i en funksjon med flere parametere av samme type.

Steg 9-10: simuler et host-angrep og bekreft at patchen stopper det

For virkelig å forstå hva som ble fikset, kan du simulere angrepsscenarioet på en trygg måte. Endre testskriptet slik at det bygger kalldata for setValue(1), viser denne verdien i loggen (simulerer det brukeren “ville sett”), men i en egen test-gren bytter det ut kalldataene med setValue(999999) rett før de sendes til TrezorConnect.ethereumSignTransaction.

const visningsKalldata = iface.encodeFunctionData(«setValue», [1]);
const faktiskKalldata = iface.encodeFunctionData(«setValue», [999999]);

console.log(«Det brukeren tror hen signerer:», visningsKalldata);

const tx = {
to: CONTRACT_ADDRESS,
value: «0x0»,
data: faktiskKalldata, // Simulerer manipulasjon
chainId: 11155111,
nonce: «0x» + nonce.toString(16),
gasLimit: «0x186a0»,
maxFeePerGas: feeData.maxFeePerGas.toString(16),
maxPriorityFeePerGas: feeData.maxPriorityFeePerGas.toString(16),
};

På en enhet med oppdatert firmware (2.12.4 eller nyere) skal skjermen vise nøyaktig setValue(999999), altså de reelle kalldataene, uansett hva loggen din later som brukeren “tror”. Det er bevis på at confirmation-binding-fiksen virker: enheten kan ikke lures til å signere noe annet enn det den faktisk viser. Dette er en test du gjør for å bekrefte oppførsel, ikke et reelt angrep mot noen andre, og du kjører det utelukkende mot din egen testkontrakt på Sepolia.

Det er verdt å presisere hva denne simuleringen faktisk beviser, og hva den ikke beviser. Den beviser at kalldataene som vises på skjermen alltid samsvarer med det som signeres, uavhengig av hva et testskript “later som” på 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ør én gang og glemmer.

Steg 11: automatiser firmwareovervåking

Siden Trezor har sluppet flere sikkerhetsoppdateringer gjennom hele 2026, er det verdt å sette opp et lite vaktskript som varsler deg når det kommer en ny release. Dette scriptet henter changelog-siden og sammenligner nyeste versjon med den du sist bekreftet.

#!/bin/bash
SISTE_KJENTE=»2.12.4″
SIDE=$(curl -s «https://trezor.io/other/product-updates/trezor-firmware-changelog-all-versions-and-release-dates»)
NYESTE=$(echo «$SIDE» | grep -oP ‘\d+\.\d+\.\d+’ | head -1)

if [ «$NYESTE» != «$SISTE_KJENTE» ]; then
echo «Ny firmwareversjon tilgjengelig: $NYESTE (du har $SISTE_KJENTE)»
else
echo «Du kjører nyeste kjente versjon: $SISTE_KJENTE»
fi

Legg skriptet inn i crontab slik at det kjører ukentlig, for eksempel hver mandag klokken 09:00. Da får du et varsel i terminalloggen din i stedet for å stole på at du husker å sjekke selv.

crontab -e
# Legg til denne linjen:
0 9 * * 1 /sti/til/check-firmware.sh >> /sti/til/firmware.log 2>&1

Vil du ha et tydeligere varsel enn en loggfil, kan du utvide skriptet til å sende en e-post eller en push-melding når det oppdager en ny versjon, i stedet for bare å skrive til terminalen. Poenget er ikke verktøyet i seg selv, men at du får et signal du faktisk legger merke til, uavhengig av om du husker å sjekke Trezor Suite manuelt den uken.

Steg 12: herding — Bitcoin-only firmware og fysisk sikkerhet

Hvis du primært oppbevarer Bitcoin og bare av og til trenger Ethereum-funksjonalitet, bør du vurdere hvor mye angrepsflate du faktisk trenger. Trezor Safe 3 og Safe 5 tilbyr en egen Bitcoin-only firmware som fjerner all støtte for Ethereum og andre altcoins fra enheten. Færre signeringsflyter betyr færre steder en fremtidig feil kan gjemme seg. Bytt til denne firmwarevarianten via Trezor Suite hvis Ethereum-signering ikke er noe du bruker jevnlig.

Uansett hvilken firmwarevariant du velger, er det verdt å huske at alle Trezor-enheter bruker et sertifisert EAL6+ Secure Element sammen med en ekstern mikrokontroller. Signeringslogikken for enkelte operasjoner kjører delvis utenfor selve det sertifiserte elementet, noe som gjør fysisk sikkerhet like viktig som firmwareoppdateringer. Oppbevar enheten et sted uvedkommende ikke har tilgang til, bruk PIN og eventuelt passordfrase, og unngå å la enheten ligge ubevoktet på reise.

PIN-koden på Trezor Safe 7 kan være opptil 50 sifre, langt mer enn de fire til ni sifrene mange brukere fortsatt nøyer seg med. En lengre PIN koster deg noen ekstra sekunder ved hver innlogging, men gjør et brute force-forsøk mot enheten praktisk talt håpløst 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 å tømme lommeboken.

Til slutt, hold et øye med hvilke tredjeparts dApp-tilkoblinger du godkjenner. CVE-2026-65058 krevde nettopp en kompromittert vert for å kunne utnyttes, noe som betyr at den beste beskyttelsen utover oppdatert firmware er sunn skepsis til hvilke nettsider og wallet-connect-forespørsler du kobler enheten din til i utgangspunktet.

Komplett testprosjekt: mappestruktur

Når du har fulgt alle stegene over, bør prosjektmappen din se omtrent slik ut. Dette gir deg et gjenbrukbart oppsett du kan kjøre igjen etter hver fremtidige firmwareoppdatering.

trezor-eth-signeringstest/
├── package.json
├── contracts/
│ └── SigningTestbed.sol
├── scripts/
│ ├── signer.js # Steg 6-7: bygger og sender transaksjonen
│ ├── verify-calldata.js # Steg 8: sammenligner vist vs. signert data
│ └── simulate-attack.js # Steg 9-10: tester confirmation-binding
├── monitor/
│ └── check-firmware.sh # Steg 11: ukentlig firmwaresjekk
└── README.md

README-filen bør inneholde adressen til testkontrakten din, hvilken avledningssti du brukte, og datoen for siste vellykkede test. Da har du et konkret loggpunkt å vise til neste gang du oppdaterer firmware.

Legg gjerne til noen faste npm-skript i package.json, slik at hele testrutinen kan kjøres med én kommando i stedet for at du må huske rekkefølgen på filene selv:

{
«scripts»: {
«sign»: «node scripts/signer.js»,
«verify»: «node scripts/verify-calldata.js»,
«simulate»: «node scripts/simulate-attack.js»,
«test:full»: «npm run sign && npm run verify && npm run simulate»
}
}

Med dette oppsettet kjører du hele verifiseringsløpet med npm run test:full etter hver firmwareoppdatering, uten å måtte huske de enkelte trinnene manuelt hver gang.

Andre sikkerhetshull Trezor har rettet i 2026

CVE-2026-65058 var ikke den eneste sårbarheten Trezors sikkerhetsportal offentliggjorde i 2026. Selskapet driver et løpende program der forskere rapporterer funn som blir undersøkt og rettet før de publiseres. Tabellen under viser et utvalg av sårbarhetene som ble løst i samme periode.

SårbarhetDato rapportert/løstKort beskrivelse Ethereum SLIP-24 calldata-bekreftelse (CVE-2026-65058) 16. mai 2026 Bare første kalldata-bit ble vist, resten signert usett Solana token-overføring, mottaker-spoofing via Address Lookup Table 1. juni 2026 Mottakeradresse kunne fremstå annerledes enn den reelle CoinJoin-koordineringsgebyr ikke vist ved autorisasjon 3. juni 2026 Gebyrtaket ble ikke tydelig presentert for brukeren Solana signeringsvisning, forbedring 12. juni 2026 Uklar visning av signerte Solana-detaljer Solana kontoopprettelse, bekreftelse ufullstendig 14. juni 2026 Ikke all relevant informasjon vist ved kontoopprettelse Desktop-oppdatering kunne installeres før signaturverifisering var fullført 16. juni 2026 Rekkefølgefeil i oppdateringsprosessen for Trezor Suite THP-paring kunne fullføres uten paringskode 22. juni 2026 Svakhet i parringsprotokollen mellom enhet og vert

Mønsteret er tydelig: de fleste feilene handler om avstanden mellom det som faktisk signeres eller autoriseres, og det brukeren får se på skjermen. Det underbygger hvorfor testen du nettopp har bygget er verdt å gjenta etter hver fremtidige firmwareoppdatering, ikke bare denne ene gangen.

Trezor publiserer disse funnene åpent på sitt sikkerhetsportal i stedet for å tie dem i hjel, med status merket “løst” for hver enkelt sak sammen med rapporteringsdato. Den samme åpenheten gjelder GitHub-repoet, der du selv kan lese commit-historikken og se nøyaktig hvilke linjer kode som ble endret for å lukke CVE-2026-65058. Denne graden av innsyn er en av grunnene til at det i det hele tatt er mulig å bygge en uavhengig verifiseringstest slik du har gjort i denne guiden, i stedet for å måtte stole blindt på produsentens egne påstander.

Vanlige fallgruver

  • Å stole på Trezor Suite-versjonen alene. Suite-versjonen sier ingenting om hvilken firmware selve enheten kjører. Sjekk alltid firmwareversjonen direkte på enheten eller via trezorctl.
  • Å teste med ekte midler. Bruk alltid Sepolia eller et annet testnett når du utforsker signeringsatferd du ikke er hundre prosent sikker på virker som forventet.
  • Å bekrefte transaksjoner uten å lese skjermen på enheten. Hele poenget med en hardware-lommebok forsvinner hvis du klikker “bekreft” på reflex uten å sjekke adresse og beløp.
  • Å blande avledningsstier mellom test og produksjon. Bruk en tydelig egen sti for testkontoer, slik at du aldri ved et uhell sender en testtransaksjon fra hovedlommeboken.
  • Å anta at universell firmware er tryggere fordi den støtter flere mynter. Flere støttede signeringsflyter betyr flere steder en fremtidig feil kan oppstå. Bitcoin-only er et reelt herdingsvalg, ikke en begrensning.
  • Å ignorere varsler fra Trezor Suite om ny firmware. Flere av 2026-rettelsene kom med bare uker eller dager mellom rapportering og patch. Den beskyttelsen hjelper deg først når du faktisk installerer den.
  • Å bruke offentlig wifi eller en delt maskin til firmwareoppdateringer. Selve oppdateringspakken er signert og verifisert av enheten, men en kompromittert vertsmaskin kan likevel skape forvirring eller avbrudd midt i prosessen. Oppdater fra en maskin du stoler på.
  • Å glemme å teste etter en fremtidig firmwareoppdatering. En ny versjon kan i teorien introdusere en ny regresjon selv om den fikser en annen sårbarhet. Gjenta testsuiten hver gang, ikke bare første gang.

Felles for de fleste av disse fallgruvene er at de handler om vaner, ikke om tekniske ferdigheter. Å bygge testprosjektet krever litt innsats første gang, men å faktisk bruke det konsekvent etter hver oppdatering er den delen mange hopper over i praksis. Sett derfor av tid til å gjøre testrutinen til en fast vane, ikke bare en engangsøvelse du gjorde mens artikkelen var fersk.

Feilsøking: 8 vanlige problemer og løsninger

De fleste problemene du støter på underveis handler om tilkobling, timing eller små feil i hvordan kalldata bygges, ikke om selve sikkerhetslogikken. Tabellen under dekker de vanligste tilfellene som dukker opp første gang noen setter opp dette prosjektet.

ProblemSannsynlig årsakLøsning trezorctl finner ikke enheten Manglende USB-tilgang eller udev-regler (Linux) Installer udev-reglene fra python-trezor sitt GitHub-repo, koble til på nytt Firmwareoppdatering henger på “Installerer” USB-kabelen leverer for lite strøm eller data er ustabil Bruk kabelen som fulgte med enheten, koble direkte til datamaskinen, ikke via hub TrezorConnect.init() feiler med manifest-feil Manifest-objektet mangler gyldig e-post eller URL Fyll inn et gyldig e-postfelt og en faktisk URL, selv i test Signeringsforespørselen timer ut Enheten venter på fysisk bekreftelse som ikke blir gitt innen tidsfristen Trykk bekreft på enheten raskere, eller øk timeout i skriptet Sepolia RPC svarer med feil eller er nede Offentlig RPC-endepunkt er overbelastet Bytt til en alternativ Sepolia RPC-leverandør eller kjør egen node Kalldata i skjermen matcher ikke det du forventet Feil i ABI-encoding eller feil funksjonssignatur i skriptet Dobbeltsjekk interface-definisjonen mot kontraktens faktiske funksjon verify-calldata.js rapporterer avvik selv med korrekt firmware Feil i egen sammenligningslogikk, for eksempel store/små bokstaver i hex Normaliser begge strenger til små bokstaver før sammenligning trezorctl viser feil modellnavn Flere Trezor-enheter tilkoblet samtidig Koble fra alle andre enheter og prøv igjen med kun én tilkoblet

Avanserte tips for videre sikkerhet

Når grunnoppsettet fungerer, kan du utvide testprosjektet videre. Legg til flere testkontrakter med mer kompleks ABI-koding, inkludert nøstede structs og dynamiske arrays, siden dette er datatyper der visningslogikk historisk har vært vanskeligere å få riktig. Test også EIP-1559-transaksjoner spesifikt, siden det var en av de to signeringsflytene som CVE-2026-65058 rammet direkte.

Vurder å sette opp testen som en del av en CI-pipeline hvis du utvikler en wallet-integrasjon selv. Da kjøres confirmation-binding-sjekken automatisk hver gang du endrer kode som bygger transaksjoner, i stedet for at noen må huske å teste det manuelt. En praktisk fallgruve her er at CI-servere sjelden har en fysisk Trezor koblet til, så du må enten kjøre denne delen av testsuiten lokalt før merge, eller sette opp en dedikert testmaskin med en enhet reservert kun til dette formålet.

Hvis du jobber i et team, er det verdt å dele testprosjektet som et internt verktøy 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ør det langt enklere å oppdage om en ny firmwareversjon faktisk endrer oppførsel fra forrige gang dere testet.

Til slutt, sett en fast rutine: hver gang Trezor slipper ny firmware, kjør hele testsuiten din på nytt før du stoler på enheten til nye kontraktsinteraksjoner. Det tar under fem minutter når prosjektet først er bygget, og det er langt billigere enn å oppdage et avvik etter at en ekte transaksjon er sendt.

Byggeklossene i denne guiden er ikke unike for Trezor. Prinsippet, å sammenligne det som vises på 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ørst forstått og bygget denne testen for Ethereum-signering, er det et lite steg videre til å teste tilsvarende for Solana-transaksjoner eller for autorisasjonsmeldinger i andre protokoller du bruker.

Kilder: Trezors sikkerhetsportal, SentinelOnes CVE-database, Trezors firmware-changelog, Trezor Safe 3 spesifikasjoner og ethers.js v6-dokumentasjonen.

Ofte stilte spørsmål

Er min Trezor fortsatt sårbar for CVE-2026-65058?

Ikke hvis du kjører firmware 2.12.4 eller nyere på 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åvirket sårbarheten også Bitcoin-signering?

Nei. Ifølge Trezors egen beskrivelse og SentinelOnes tekniske analyse var feilen isolert til Ethereum-signeringsflytene sign_tx og sign_tx_eip1559, altså kontraktsinteraksjoner på Ethereum, ikke Bitcoin-transaksjoner.

Trenger jeg å flytte midlene mine hvis jeg har brukt en sårbar firmwareversjon?

Sårbarheten krevde en kompromittert vertsapplikasjon som aktivt utnyttet feilen under en signering, den ga ikke en angriper direkte tilgang til seed eller nøkler i etterkant. Har du bekreftet transaksjoner som faktisk gikk gjennom med forventet mottaker og beløp, er det ingen automatisk grunn til å flytte midler. Er du usikker på om en tidligere transaksjon var korrekt, bør du sjekke den historiske transaksjonen på en blokkutforsker som Etherscan, og sammenligne mottaker og beløp mot det du selv husker å ha godkjent.

Kan jeg bruke samme testoppsett på Ledger-enheter?

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, å sammenligne vist kalldata med signert kalldata, kan gjenbrukes uansett produsent.

Hvor ofte bør jeg kjøre denne testen på nytt?

Etter hver firmwareoppdatering, og gjerne som en fast vane et par ganger i året selv uten oppdateringer. Vaktskriptet fra steg 11 hjelper deg å huske når en ny versjon er tilgjengelig.

Er Bitcoin-only firmware bedre for sikkerheten min?

Hvis du ikke trenger Ethereum eller andre altcoins på enheten, reduserer Bitcoin-only firmware angrepsflaten ved å fjerne de signeringsflytene som ikke gjelder Bitcoin. Det er ikke en universell løsning 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 å miste tilgang til midlene dine, siden seed-en forblir den samme uavhengig av hvilken firmwarevariant enheten kjører.

Hvem oppdaget CVE-2026-65058?

Ifølge Trezors sikkerhetsportal ble sårbarheten rapportert av en forsker med brukernavnet LoopGhost 16. mai 2026, gjennom selskapets program for ansvarlig rapportering av sårbarheter.

Må jeg installere universell firmware for å teste Ethereum-signering?

Ja. Bitcoin-only firmware støtter ikke Ethereum-signeringsflytene i det hele tatt, så du må kjøre universell firmware på enheten mens du gjennomfører testene i denne guiden. Bytt tilbake til Bitcoin-only etterpå hvis det er det du normalt bruker.