{"id":527,"date":"2026-10-06T05:07:07","date_gmt":"2026-10-06T05:07:07","guid":{"rendered":"https:\/\/hoge.gg\/no\/multisig-2026-tillatelsen-er-angrepet\/"},"modified":"2026-10-06T05:07:07","modified_gmt":"2026-10-06T05:07:07","slug":"multisig-2026-tillatelsen-er-angrepet","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/multisig-2026-tillatelsen-er-angrepet\/","title":{"rendered":"Multisig 2026: n\u00e5r selve tillatelsen er angrepet"},"content":{"rendered":"

Base-hvelvet: da en hake i en liste t\u00f8mte hvelvet<\/h2>S\u00f8ndag 4. oktober 2026, klokken 08:52 UTC, fjernet et anonymt hvelv p\u00e5 Base en adresse fra en tillatelsesliste. Ett minutt senere, 08:53 UTC, la den samme multisigen adressen tilbake. Begge transaksjonene bar tre gyldige ECDSA-signaturer fra de samme signat\u00e6rene, og ingenting ved dem s\u00e5 unormalt ut for kjeden. Rundt 70 sekunder etter at kontrakten var tilbake p\u00e5 lista, l\u00e5nte den 1 783,067 aBaswstETH mot hvelvets Aave v3-posisjon og l\u00f8ste tokenene inn til omtrent 1 783 wstETH, verdt rundt 6 millioner dollar (cirka 58 millioner kroner), som forsvant til en angriperadresse. Cryptotimes<\/a> og sikkerhetsselskapet Blockaid dokumenterte at tapet vokste fra et f\u00f8rste anslag p\u00e5 2,02 millioner dollar til rundt 6 millioner i l\u00f8pet av 40 minutter.Ingen n\u00f8kkel ble stj\u00e5let. Ingen smartkontrakt i Aave eller p\u00e5 Base ble brutt. Angrepet var en helt vanlig, gyldig endring av hvem som fikk lov til \u00e5 l\u00e5ne fra hvelvet, utf\u00f8rt gjennom multisigens egne rutiner. Etterp\u00e5 sto fortsatt rundt 31,7 millioner dollar (cirka 300 millioner kroner) igjen i hvelvet, if\u00f8lge mpost<\/a>, og ingen prosjekt har meldt seg som eier. Hvelvet ble kontrollert av en 3-av-7 Safe der alle sju signat\u00e6radressene er ukjente, og multisigen hadde ikke utf\u00f8rt en eneste transaksjon p\u00e5 25 dager f\u00f8r de to endringene kom p\u00e5 rekke og rad under angrepet. News.Bitcoin.com<\/a> kalte det treffende et hvelv styrt av sju mysteriesignat\u00e6rer.To dager tidligere, 2. oktober, hadde noe beslektet skjedd. Angripere tappet rundt 114,09 ETH (cirka 3 millioner kroner) fra to Safe-multisiger, ikke ved \u00e5 lure noen til \u00e5 signere en overf\u00f8ring, men ved \u00e5 utnytte en tredjeparts modul koblet til lommeb\u00f8kene. Begge sakene peker p\u00e5 det samme, og det er temaet for denne artikkelen: i 2026 er det ikke uttaket angriperne er ute etter f\u00f8rst. Det er tillatelsen.

Multisigen br\u00f8t ikke sammen, den adl\u00f8d<\/h2>En multisig er en lommebok der flere av et sett n\u00f8kler m\u00e5 godkjenne f\u00f8r noe skjer, for eksempel tre av fem. Logikken er enkel: \u00e9n kompromittert n\u00f8kkel skal ikke v\u00e6re nok. Mot rent n\u00f8kkeltyveri virker modellen godt. Problemet er at en multisig ikke bare godkjenner overf\u00f8ringer. Den godkjenner ogs\u00e5 endringer i sine egne regler: hvem som er eier, hvilke moduler som er aktive, hvilke kontrakter som st\u00e5r p\u00e5 en l\u00e5netillatelse, og hvilken implementasjon en proxy-kontrakt peker p\u00e5. Alle disse er like gyldige multisig-handlinger som et uttak, men de har en helt annen rekkevidde.Forskjellen er lett \u00e5 overse og dyr \u00e5 l\u00e6re. En overf\u00f8ring t\u00f8mmer hvelvet \u00e9n gang. En tillatelsesendring gir angriperen en st\u00e5ende n\u00f8kkel. N\u00e5r en ondsinnet kontrakt f\u00f8rst st\u00e5r p\u00e5 l\u00e5netillatelsen, slik i Base-hvelvet, kan den komme tilbake og l\u00e5ne igjen. N\u00e5r en modul f\u00f8rst er aktivert, kan den flytte midler uten \u00e5 g\u00e5 gjennom m-av-n p\u00e5 nytt. N\u00e5r eierskapet f\u00f8rst er overf\u00f8rt, slik i flere av fjor\u00e5rets saker, eier angriperen multisigen. Signat\u00e6rene i Base-hvelvet gjorde ingen feil i kryptografien; de autoriserte n\u00f8yaktig det angrepet trengte, og trodde det var rutine.Derfor er den viktigste, og minst l\u00e6rte, l\u00e6rdommen fra 2026-sakene denne: en privilegert endring m\u00e5 styres like strengt som et milliarduttak. Samme seremoni, samme ventetid, samme verifisering utenfor signeringskanalen. De fleste team gj\u00f8r ikke det. De behandler en modulaktivering eller en justering av en allowlist som teknisk vedlikehold, noe en eller to personer ordner raskt, mens de omgir et stort uttak med kontroller. Angriperne har lagt merke til det. Som Ledgers teknologidirekt\u00f8r Charles Guillemet har advart om etter \u00e5rets hendelser, er \u00abMultisig is not automatically the right answer\u00bb<\/a>; flere n\u00f8kler hjelper ikke hvis det angriperen er ute etter, er en gyldig endring av reglene.M\u00f8nsteret er ikke anekdotisk. I halv\u00e5rsrapporten for 2026 teller TRM Labs<\/a> 207 hendelser med tap p\u00e5 rundt 972 millioner dollar (cirka 9,3 milliarder kroner) i f\u00f8rste halv\u00e5r, et rekordh\u00f8yt antall hendelser selv om totalbel\u00f8pet falt 57 prosent fra 2,3 milliarder dollar \u00e5ret f\u00f8r. Det interessante er fordelingen. Rene smartkontraktsfeil sto for 125 av de 207 hendelsene, alts\u00e5 flertallet av angrepene, men bare en liten andel av verdien. Kompromittering av infrastruktur, n\u00f8kler og drift sto for rundt 15 prosent av hendelsene, men hele 76 prosent av verdien. Medianen l\u00e5 p\u00e5 rundt 219 000 dollar, mens gjennomsnittet var 4,7 millioner; noen f\u00e5 store tyverier drar snittet opp.Oversatt til vanlig spr\u00e5k: koden holder stort sett. Det som svikter, er lagene rundt n\u00f8klene, og stadig oftere handler det om hvem som har lov til hva. September 2026 ble \u00e5rets verste m\u00e5ned med rundt 766 millioner dollar tapt (cirka 7,4 milliarder kroner) if\u00f8lge Shattered<\/a>, drevet av Bitget-tyveriet 24. september og Liquid Network-tappingen 6. september. Oktober \u00e5pnet med Loop-modulen og Base-hvelvet. Felles for dem alle er at angriperne ikke lette etter en matematisk svakhet, men etter en fullmakt de kunne vri om.

Syv saker, og hva signat\u00e6rene egentlig skrev under p\u00e5<\/h2>Ser man 2026-sakene, og de ferskeste fra 2024 og 2025, gjennom tillatelseslinsen i stedet for som en liste over tapte bel\u00f8p, blir m\u00f8nsteret tydelig. I nesten alle tilfellene autoriserte signat\u00e6rene ikke et uttak, men en endring i hvem eller hva som hadde makt over hvelvet. Tabellen under sorterer sakene etter nettopp det: ikke hvor mye som forsvant, men hva signat\u00e6rene faktisk skrev under p\u00e5.
Sak<\/th>Dato<\/th>Tap<\/th>Hva signat\u00e6rene faktisk autoriserte<\/th><\/tr><\/thead>
Bybit<\/td>feb. 2025<\/td>~1,5 mrd. USD<\/td>Bytte av Safe-implementasjonen via delegatecall, forkledd som en rutineoverf\u00f8ring (blindsignert)<\/td><\/tr>
Radiant Capital<\/td>okt. 2024<\/td>~50 mill. USD<\/td>transferOwnership p\u00e5 en kjernekontrakt, mens skjermen viste en legitim handling<\/td><\/tr>
UXLINK<\/td>sep. 2025<\/td>~28 mill. USD<\/td>Delegatecall som fjernet admin og la angriperen til som eier, fulgt av mint av billioner token<\/td><\/tr>
Drift Protocol<\/td>apr. 2026<\/td>~285 mill. USD<\/td>Forh\u00e5ndssignerte durable-nonce-transaksjoner som stille overf\u00f8rte admin-kontroll<\/td><\/tr>
Humanity Protocol<\/td>jun. 2026<\/td>~36 mill. USD<\/td>Eierskapsoverf\u00f8ring og en ubegrenset mint-funksjon p\u00e5 tvers av to kjeder<\/td><\/tr>
Aave Loop-modul<\/td>2. okt. 2026<\/td>~114 ETH<\/td>En aktivert tredjepartsmodul som kunne flytte midler uten ny m-av-n<\/td><\/tr>
Base-hvelvet<\/td>4. okt. 2026<\/td>~6 mill. USD<\/td>Kontrakt lagt til l\u00e5netillatelsen, s\u00e5 fjernet og lagt tilbake p\u00e5 ett minutt<\/td><\/tr><\/tbody><\/table><\/figure>Noen av disse er verdt et n\u00e6rmere blikk. I Bybit-saken<\/a>, det st\u00f8rste kryptotyveriet noensinne med rundt 1,5 milliarder dollar (cirka 14,4 milliarder kroner), s\u00e5 signat\u00e6rene en helt vanlig overf\u00f8ring p\u00e5 skjermen mens de i virkeligheten godkjente en transaksjon som byttet ut hvelvets egen logikk. I Radiant Capital<\/a> kalte angriperen transferOwnership p\u00e5 en kjernekontrakt etter at malware p\u00e5 utviklernes maskiner hadde f\u00e5tt b\u00e5de simuleringer og skjermbilder til \u00e5 se riktige ut. I UXLINK<\/a> brukte angriperen en delegatecall til \u00e5 fjerne admin og legge seg selv til som eier, og kunne deretter prege billioner nye token. I alle tre var selve tyveriet nesten en ettertanke; det avgj\u00f8rende \u00f8yeblikket var da fullmakten skiftet hender.Drift Protocol, det st\u00f8rste DeFi-tyveriet i 2026 med rundt 285 millioner dollar (cirka 2,7 milliarder kroner), er det reneste eksempelet p\u00e5 hvorfor dette er en governance-feil og ikke en kodefeil. Vi har g\u00e5tt grundig gjennom saken i gjennomgangen av Halborn og angrepene som omg\u00e5r revisjonen<\/a>: angriperne brukte m\u00e5neder p\u00e5 \u00e5 sosialmanipulere Drifts Security Council til \u00e5 forh\u00e5ndssignere s\u00e5kalte durable-nonce-transaksjoner, en legitim Solana-funksjon der en transaksjon kan signeres \u00e9n gang og utf\u00f8res senere uten \u00e5 utl\u00f8pe. Da r\u00e5det kort tid f\u00f8r angrepet byttet til en ny terskel uten timelock, forsvant deteksjonsvinduet, og de forh\u00e5ndssignerte fullmaktene kunne l\u00f8ses ut p\u00e5 kommando. Ingen revisjon fanger det, for koden var aldri problemet.

Loop-modulen: n\u00e5r en tredjeparts modul blir en st\u00e5ende n\u00f8kkel<\/h2>Safe lar deg utvide en multisig med moduler, sm\u00e5 kontrakter som f\u00e5r lov til \u00e5 utf\u00f8re bestemte handlinger uten \u00e5 g\u00e5 gjennom hele m-av-n hver gang. Det er praktisk for automatisering, men det flytter grensen for tilliten din: n\u00e5r en modul f\u00f8rst er aktivert, er modulens egen tilgangskontroll din tilgangskontroll. Det var akkurat her det gikk galt 2. oktober 2026.If\u00f8lge sikkerhetsselskapet SlowMist, gjengitt av mpost<\/a>, ble rundt 114,09 ETH tappet fra to Safe-lommeb\u00f8ker via Loop Safe Module, en tredjeparts adapter (FlashLoopAdapter) bygget opp\u00e5 Aave v3. Feilen l\u00e5 i tilgangskontrollen: modulens funksjoner sjekket bare om den som kalte, hadde modulen aktivert, ikke hvem kalleren egentlig var. Angriperen satte opp en falsk Safe som var hardkodet til \u00e5 svare at modulen var aktivert, forfalsket p\u00e5 den m\u00e5ten Safe-autentiseringen, og styrte deretter modulen med sin egen calldata til \u00e5 trekke ut pantet. Kjernen i Aave ble aldri r\u00f8rt.Aave-grunnlegger Stani Kulechov var rask til \u00e5 trekke den grensen tydelig. Til ChainCatcher<\/a> sa han at \u00abThe contract with the vulnerability is not the Aave v3 contract, but rather a third-party external adapter built on top of Aave, which does not affect Aave v3 itself\u00bb. Det er en viktig presisering, men ogs\u00e5 selve poenget for en multisig-eier: Aave var trygt, og likevel forsvant pengene, fordi lommeboken hadde delegert makt til en modul hvis forfatter og kode n\u00e5 var den reelle grensen. En modul du aktiverer, er en n\u00f8kkel du gir bort, helt til du aktivt fjerner den.

Kjenn signat\u00e6rene dine, og hva du ber dem om<\/h2>Ethereum-grunnlegger Vitalik Buterin har pekt p\u00e5 det som egentlig er det f\u00f8rste sp\u00f8rsm\u00e5let for enhver multisig. Han har skrevet<\/a> at \u00abTwo key questions in using multi-sig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them?\u00bb. Begge delene handler om tillatelser f\u00f8r de handler om teknikk: hvem du gir en n\u00f8kkel, og hva de har f\u00e5tt beskjed om \u00e5 gj\u00f8re med den.Base-hvelvet er motsatsen til begge svarene. Sju signat\u00e6rer, ingen kjent identitet, ingen forvalter, ingen regulator \u00e5 g\u00e5 til. Da tre av dem signerte endringen i l\u00e5netillatelsen, fantes det ingen uavhengig part som kunne stanse den, og i etterkant ingen \u00e5 stille til ansvar. Anonyme signat\u00e6rer kan v\u00e6re akseptabelt for et lite, gjennomsiktig eksperiment, men for et hvelv som holder verdier i millionklassen, fjerner det den siste bremsen: muligheten til \u00e5 ringe et menneske og sp\u00f8rre \u00abautoriserte du virkelig dette?\u00bb.Praksisen her er todelt. For det f\u00f8rste: velg signat\u00e6rer du kan n\u00e5, med minst \u00e9n ekstern part som ikke sitter i samme organisasjon eller samme rom, slik at en intern kompromittering eller et internt komplott ikke rekker hele terskelen. For det andre: gi dem en instruks som gjelder tillatelser spesifikt, ikke bare uttak. En signat\u00e6r som vet at en ny modul eller en endring i allowlisten alltid skal bekreftes i en videosamtale og aldri hastes gjennom, er en langt bedre forsvarslinje enn en som bare teller nuller i et bel\u00f8p. Det menneskelige laget er uansett det siste; som vi har sett i dekningen av fysisk tvang mot kryptoeiere<\/a>, er en signat\u00e6r ogs\u00e5 et menneske som kan presses, s\u00e5 instruksen m\u00e5 t\u00e5le at noen pr\u00f8ver \u00e5 omg\u00e5 den.

En tillatelsesendring er et uttak<\/h2>Den enkeltpraksisen som ville ha stanset flest av sakene over, er ogs\u00e5 den billigste: behandle enhver privilegert operasjon som om den var et uttak p\u00e5 st\u00f8rrelse med hele hvelvet, for i praksis er det ofte nettopp det den er. SEAL, sikkerhetskollektivet bak de \u00e5pne retningslinjene for multisig<\/a>, lister opp en egen kontroll de kaller \u00abOut-of-Band Verification for Admin Changes\u00bb: endringer i eierskap, moduler, terskel eller tillatelser skal bekreftes utenfor signeringskanalen, for eksempel i en videosamtale kombinert med en signert melding, f\u00f8r de utf\u00f8res.Poenget med \u00e5 verifisere utenfor kanalen er at angriperen ofte kontrollerer selve kanalen. Var skjermen manipulert (Bybit), var utviklermaskinen infisert (Radiant), eller var en signat\u00e6r sosialmanipulert (Drift), s\u00e5 er den eneste p\u00e5liteligheten en uavhengig bekreftelse gjennom et helt annet medium. Tabellen under kobler de vanligste privilegerte operasjonene til rekkevidden deres og til kontrollen som b\u00f8r v\u00e6re obligatorisk f\u00f8r de utf\u00f8res.
Privilegert operasjon<\/th>Rekkevidde om misbrukt<\/th>Obligatorisk kontroll<\/th><\/tr><\/thead>
Vanlig overf\u00f8ring<\/td>T\u00f8mmer ett bel\u00f8p \u00e9n gang<\/td>Terskel, simulering, bel\u00f8psgrense<\/td><\/tr>
Legge til eller bytte eier<\/td>Angriperen overtar multisigen<\/td>Timelock, veto-quorum, bekreftelse utenfor kanalen<\/td><\/tr>
Aktivere en modul<\/td>St\u00e5ende makt til \u00e5 flytte midler uten m-av-n<\/td>Kodegjennomgang av modulen, timelock, overv\u00e5king<\/td><\/tr>
Endre allowlist eller whitelist<\/td>Ny l\u00e5ntaker eller mottaker kan komme tilbake<\/td>Bekreftelse utenfor kanalen, timelock, varsling<\/td><\/tr>
Oppgradere proxy eller implementasjon<\/td>Bytter ut hele lommebokens logikk<\/td>Timelock, uavhengig verifisering av ny kode<\/td><\/tr>
Fjerne eller senke en timelock<\/td>Fjerner deteksjonsvinduet for alt annet<\/td>Behandles som den mest kritiske endringen av alle<\/td><\/tr><\/tbody><\/table><\/figure>Den siste raden er verdt \u00e5 dvele ved. I Drift fjernet r\u00e5det timelocken selv, kort f\u00f8r angrepet, og \u00e5pnet dermed d\u00f8ren for de forh\u00e5ndssignerte fullmaktene. En endring som svekker et forsvar, b\u00f8r alltid regnes som farligere enn endringen den skal muliggj\u00f8re, ikke mindre farlig fordi den bare r\u00f8rer ved innstillinger.

Revider modulene, vaktene og fullmaktene dine<\/h2>Hvis en tillatelse er en n\u00f8kkel, m\u00e5 du vite n\u00f8yaktig hvor mange n\u00f8kler som finnes. De fleste team kan liste opp signat\u00e6rene sine, men langt f\u00e6rre kan p\u00e5 st\u00e5ende fot svare p\u00e5 hvilke moduler som er aktive p\u00e5 Safe-en, hvilke kontrakter som st\u00e5r p\u00e5 allowlisten, hvem som er satt opp som guard, og hvilken implementasjon proxy-en peker p\u00e5. Hver av dem er en inngang. En tillatelsesflate du ikke har oversikt over, kan du heller ikke forsvare.Praksisen er en jevnlig revisjon av tillatelsesflaten, ikke bare av koden. F\u00f8r hvert kvartal, og etter enhver endring: list opp alle aktive moduler og hvem som skrev dem, alle adresser p\u00e5 enhver allowlist, alle eiere og terskelen, alle guards, og tidspunktet for siste endring i hver. Fjern det som ikke lenger brukes. En modul som ble st\u00e5ende igjen fra et pilotprosjekt i fjor, er en \u00e5pen d\u00f8r ingen lenger vokter. Dette er den samme disiplinen vi etterlyste i omtalen av Bitget og revisjonsparadokset<\/a>: en ren revisjon av koden sier ingenting om hvem som har f\u00e5tt st\u00e5ende fullmakter utenfor den.Base-hvelvet gir en siste, konkret ledetr\u00e5d: multisigen hadde ligget stille i 25 dager f\u00f8r de to tillatelsesendringene plutselig kom. En Safe som er dvask i ukevis og s\u00e5 gj\u00f8r to raske administrative grep p\u00e5 rad, er i seg selv et varsel. Det b\u00f8r utl\u00f8se en alarm, ikke bare en loggf\u00f8ring, og det bringer oss til neste sp\u00f8rsm\u00e5l: hvem som skal varsles, og hvor h\u00f8y terskelen egentlig b\u00f8r v\u00e6re.

Terskel og signat\u00e6rmangfold: flere er ikke tryggere<\/h2>Det er en utbredt misforst\u00e5else at flere signat\u00e6rer alltid betyr mer sikkerhet. SEAL-retningslinjene setter noen gulv som er verdt \u00e5 f\u00f8lge: minst tre signat\u00e6rer, en terskel p\u00e5 minst 50 prosent, og sju eller flere signat\u00e6rer for multisiger som holder verdier over \u00e9n million dollar (rundt ti millioner kroner). Men de advarer ogs\u00e5 mot N-av-N, der alle m\u00e5 signere, fordi en eneste utilgjengelig eller kompromittert n\u00f8kkel da enten l\u00e5ser hvelvet eller stanser all drift. Poenget er balanse, ikke maksimal spredning.Mangfold betyr mer enn antall. SEAL anbefaler ulike maskinvarelommeb\u00f8ker fra ulike produsenter (s\u00e5 en enkelt firmware-feil ikke rammer alle), geografisk spredning av signat\u00e6rene, minst \u00e9n ekstern signat\u00e6r, og en dedikert signeringsadresse per multisig i stedet for \u00e5 gjenbruke den samme n\u00f8kkelen flere steder. Humanity Protocol er motsatsen: terskler p\u00e5 to kjeder s\u00e5 nominelt uavhengige ut, men flere av n\u00f8klene var sikkerhetskopiert til den samme b\u00e6rbare datamaskinen, s\u00e5 \u00e9n enkelt enhet br\u00f8t begge tersklene samtidig.
Verdi i hvelvet<\/th>Foresl\u00e5tt oppsett<\/th>Merknad<\/th><\/tr><\/thead>
Lite team eller hobby<\/td>2 av 3<\/td>T\u00e5ler tap av \u00e9n n\u00f8kkel uten \u00e5 l\u00e5se hvelvet<\/td><\/tr>
Betydelig eller i drift<\/td>3 av 5<\/td>Terskel minst 50 prosent, unng\u00e5 N-av-N<\/td><\/tr>
H\u00f8y verdi<\/td>4 av 7<\/td>Rom for geografisk og organisatorisk spredning<\/td><\/tr>
Over ~1 mill. USD<\/td>7+ signat\u00e6rer<\/td>SEAL-gulv, med minst \u00e9n ekstern signat\u00e6r<\/td><\/tr>
Alle niv\u00e5er<\/td>Ulike HW-modeller og produsenter<\/td>Hindrer at \u00e9n firmware-feil rammer alle<\/td><\/tr><\/tbody><\/table><\/figure>Men merk hva tabellen ikke l\u00f8ser. Alle sakene i denne artikkelen skjedde i multisiger som i praksis fulgte tersklene over. En 3-av-7 stanser ikke et angrep der tre gyldige signaturer er akkurat det angriperen har skaffet seg, enten gjennom kompromitterte enheter, sosial manipulasjon eller en manipulert skjerm. Terskel og mangfold er n\u00f8dvendige gulv, men de beskytter mot tapte og stj\u00e5lne n\u00f8kler, ikke mot en signat\u00e6r som blir lurt til \u00e5 godkjenne feil ting. For det trengs det neste laget: \u00e5 faktisk lese det du signerer.

Les det du signerer, og grensen for clear signing<\/h2>Blindsignering, alts\u00e5 \u00e5 godkjenne en transaksjon lommeboken bare viser som en uleselig streng med hex, er den r\u00f8de tr\u00e5den gjennom de dyreste sakene. Svaret bransjen samlet seg om i 2026, er clear signing. 12. mai 2026 lanserte Ethereum Foundation en felles Clear Signing-standard<\/a> under initiativet Trillion Dollar Security, med ERC-7730 (et JSON-format som lar en lommebok vise en transaksjon i lesbar tekst), et offentlig register og et attestasjonssystem. Begrunnelsen formulerte stiftelsen slik: \u00abApproving a transaction is meant to be the last line of defense … When it is done blindly, that defense does not hold\u00bb, og m\u00e5let er at \u00abWhat You See Is What You Sign (WYSIWYS) must be our goal, and Clear Signing must be the default\u00bb.ERC-7730 er fortsatt p\u00e5 utkaststadiet, men aktivt i bruk, og er if\u00f8lge EIP-registeret<\/a> opprinnelig foresl\u00e5tt av Ledger med bidrag fra blant andre MetaMask og Trezor. For en multisig betyr det at en signat\u00e6r kan se at en transaksjon kaller addOwnerWithThreshold eller enableModule, og mot hvilken adresse, i stedet for en ugjennomtrengelig datablokk. Det er et stort steg, og det ville ha hjulpet mot Bybit-typen angrep der skjermen l\u00f8y.Men clear signing har en grense som er direkte relevant for tillatelsesangrep. Standarden kan vise deg sant at du er i ferd med \u00e5 aktivere en modul eller legge en kontrakt til en allowlist. Den kan ikke fortelle deg om den modulen eller den kontrakten er trygg. I Base-hvelvet var transaksjonen som la kontrakten til lista, antakelig helt lesbar; problemet var ikke at signat\u00e6rene ikke s\u00e5 hva de godkjente, men at det de godkjente, var farlig. Clear signing l\u00f8ser blindsignering. Det l\u00f8ser ikke sp\u00f8rsm\u00e5let om du burde ha signert i det hele tatt, og derfor er menneskelig instruks og verifisering utenfor kanalen fortsatt uunnv\u00e6rlig.

Timelocks, simulering og overv\u00e5king<\/h2>Hvis en tillatelsesendring er det farligste en multisig gj\u00f8r, trenger du tid til \u00e5 oppdage den f\u00f8r den f\u00e5r virke. En timelock, en obligatorisk forsinkelse mellom at en transaksjon er godkjent og at den kan utf\u00f8res, er det enkleste verkt\u00f8yet for nettopp det. SEAL anbefaler obligatoriske timelocks, og gjerne et eget veto-quorum som kan kansellere en mistenkelig transaksjon i ventetiden. Forsinkelsen er ikke til bry; den er deteksjonsvinduet. Drift viste hva som skjer n\u00e5r det vinduet lukkes: uten timelock var det ingenting mellom den forh\u00e5ndssignerte fullmakten og uttaket.Simulering h\u00f8rer med, men med et forbehold. \u00c5 simulere en transaksjon f\u00f8r den utf\u00f8res, for eksempel gjennom verkt\u00f8y som Tenderly, viser hva den faktisk vil gj\u00f8re mot kjeden. Det fanger mange feil. Men i Radiant var nettopp utviklermaskinene kompromittert, s\u00e5 simuleringen viste et rent resultat mens den virkelige transaksjonen var en annen. L\u00e6rdommen er at simulering m\u00e5 skje p\u00e5 en ren, uavhengig enhet for \u00e5 bety noe, og at den utfyller, ikke erstatter, en uavhengig rekompilering av transaksjonens hash p\u00e5 en separat maskin.Overv\u00e5king er det siste leddet, og det er her tillatelsesflaten fortjener spesiell oppmerksomhet. De fleste team varsler p\u00e5 store overf\u00f8ringer. Langt f\u00e6rre varsler automatisk p\u00e5 en ny eier, en aktivert modul, en endret allowlist eller en senket timelock. Det b\u00f8r snus: enhver endring i hvem som har makt, b\u00f8r utl\u00f8se et varsel til alle signat\u00e6rer umiddelbart, uavhengig av bel\u00f8p. Hadde Base-hvelvet hatt et slikt varsel, ville de to endringene klokken 08:52 og 08:53 v\u00e6rt en alarm, ikke en oppdagelse 28 minutter senere.

Isoler n\u00f8klene, roter signat\u00e6rene, \u00f8v p\u00e5 krisen<\/h2>Selve signeringen b\u00f8r skje p\u00e5 en dedikert, helst luftgappet enhet som ikke brukes til noe annet. Jo mer en maskin gj\u00f8r, desto st\u00f8rre er angrepsflaten; en b\u00e6rbar PC full av nettlesere, utvidelser og nedlastede PDF-er er ikke et signeringsmilj\u00f8. Radiant og Humanity er begge p\u00e5minnelser om at n\u00e5r signeringsmaskinen eller n\u00f8kkelkopien deler plass med resten av arbeidslivet, flytter angriperen inn der. En n\u00f8kkel som bare lever p\u00e5 en isolert enhet, og en sikkerhetskopi som ikke ligger i samme sky som alt annet, fjerner de vanligste inngangene.Signat\u00e6rlisten er ikke statisk. Folk slutter, bytter rolle, mister en enhet eller blir kompromittert. SEAL anbefaler jevnlige gjennomganger av tilgang og rask offboarding n\u00e5r noen g\u00e5r, med en langt strammere frist for signat\u00e6rer i kritiske roller. Hver gang listen endres, er det i seg selv en privilegert operasjon, s\u00e5 den h\u00f8rer hjemme under de samme kontrollene som resten: timelock, bekreftelse utenfor kanalen og varsling. Rotasjon er bra, men selve rotasjonen er ogs\u00e5 en tillatelsesendring.Til slutt: en katastrofeplan som er \u00f8vd p\u00e5, ikke bare skrevet. Hva gj\u00f8r dere hvis en n\u00f8kkel mistes midt i en transaksjon, hvis en signat\u00e6r ikke er \u00e5 f\u00e5 tak i, eller hvis dere mistenker at en terskel er kompromittert akkurat n\u00e5? SEAL legger vekt p\u00e5 dokumenterte kommunikasjonskanaler og regelmessige \u00f8velser nettopp fordi flere av de virkelige sakene startet med en forvekslet eller forfalsket kanal, ikke i selve signeringen. Avgrenset tilgang og tidsbegrensede fullmakter, som vi beskrev i regnskapet for EIP-7702 halvannet \u00e5r etter Pectra<\/a>, peker samme vei: makt b\u00f8r v\u00e6re s\u00e5 snevert avgrenset og s\u00e5 lett \u00e5 trekke tilbake som mulig.

Multisig eller MPC, og Bitget-speilet<\/h2>Et naturlig sp\u00f8rsm\u00e5l er om en annen arkitektur hadde hjulpet. Alternativet til multisig er ofte MPC (multi-party computation), der \u00e9n n\u00f8kkel deles i hemmelige andeler som aldri settes sammen, og signeringen koordineres utenfor kjeden. Safe oppsummerer forskjellen presist: \u00abMultisig externalizes trust into verifiable code. MPC internalizes trust into systems and infrastructure that cannot be fully verified on-chain\u00bb<\/a>. Multisigens styrke er at hver godkjenning er synlig og etterpr\u00f8vbar p\u00e5 kjeden; svakheten er at feilen flytter til godkjenningsskjermen. MPC gir f\u00e6rre synlige ledd og raskere drift, men du m\u00e5 stole p\u00e5 en infrastruktur du ikke kan revidere fullt ut. Fireblocks<\/a> beskriver sin egen modell som at den fulle n\u00f8kkelen \u00abnever created, never stored, and never assembled at any point\u00bb.Bitget-tyveriet 24. september 2026 er speilet som viser at ingen av modellene er magi. Her forsvant rundt 387,5 millioner dollar (cirka 3,7 milliarder kroner), \u00e5rets st\u00f8rste kryptotyveri, if\u00f8lge Fortune<\/a>. Administrerende direkt\u00f8r Gracy Chen opplyste at ingen privat n\u00f8kkel ble stj\u00e5let og ingen kundeuttak forfalsket; angriperne kompromitterte i stedet et backend-system i Bitgets infrastruktur, matet det med forfalskede transaksjonsdata, og lot b\u00f8rsens egen automatiske autorisasjon frigi midlene. Det er i bunn og grunn den samme feilen som i en multisig, bare flyttet til et sted ingen signat\u00e6r kunne se: autorisasjonen var gyldig, men det som ble autorisert, var angriperens.I praksis konvergerer bransjen mot en kombinasjon: MPC for den daglige driften, multisig for governance og de store beslutningene, slik at ingen enkelt lag er b\u00e5de raskt og uetterpr\u00f8vbart. Men uansett modell er konklusjonen den samme som resten av denne artikkelen. Det avgj\u00f8rende er ikke om n\u00f8kkelen er delt i kontrakter eller i kryptografiske andeler, men hvor godt du styrer hvem og hva som f\u00e5r lov til \u00e5 bruke den.

Det norske bildet: Finanstilsynet, MiCA og de anonyme signat\u00e6rene<\/h2>For norske lesere avhenger svaret p\u00e5 \u00abhvem kan jeg g\u00e5 til?\u00bb helt av hvem som holder n\u00f8klene. Siden 1. juli 2025 gjelder kryptoeiendelsloven, som innf\u00f8rer MiCA i norsk rett gjennom E\u00d8S-avtalen, og Finanstilsynet<\/a> f\u00f8rer tilsyn med tilbydere av kryptoeiendelstjenester (CASP-er). En CASP som oppbevarer kundenes midler, er underlagt MiCA artikkel 75: klientmidler skal holdes rettslig atskilt fra tilbyderens eget bo, kreditorer har ikke tilgang ved konkurs, og tilbyderen er ansvarlig for tap av kundenes eiendeler eller tilgangsmidler, begrenset til markedsverdien p\u00e5 tapstidspunktet. I tillegg stiller DORA krav til operasjonell IKT-robusthet, inkludert tredjepartsrisiko, noe som er h\u00f8yst relevant n\u00e5r feilen ligger i en modul eller et backend-system.Base-hvelvet faller p\u00e5 utsiden av alt dette. En anonym DeFi-multisig uten en identifiserbar tilbyder er ikke en CASP; det finnes ingen regulator \u00e5 klage til, ingen segregeringsregel, ingen ansvarsgrense. De sju ukjente signat\u00e6rene er bokstavelig talt det eneste forsvaret, og n\u00e5r noe g\u00e5r galt, er det ingen \u00e5 stille til ansvar. Det er grensen vi har beskrevet i gjennomgangen av smartkontoens juss<\/a>: i det \u00f8yeblikket en tjeneste tar kontroll over tilgangsmidlene dine, flytter du inn under MiCA og Finanstilsynets paraply, mens ekte selvforvaring og anonyme hvelv blir liggende utenfor, med alt ansvaret p\u00e5 deg selv.Praktisk betyr det to ting for en norsk bruker eller et norsk selskap. Velger du en regulert CASP, har du et rettslig sikkerhetsnett, men du gir fra deg teknisk kontroll. Styrer du en egen multisig, beholder du kontrollen, men da er beste praksis i denne artikkelen hele forsvaret ditt. Tap p\u00e5 selvforvarte midler er din risiko alene; ved tyveri g\u00e5r veien til politiet og eventuelt \u00d8kokrim, og et eventuelt tap m\u00e5 uansett h\u00e5ndteres i skattemeldingen til Skatteetaten. Ingen regulator henter tilbake en fullmakt du selv signerte bort.

Sjekkliste: slik styrer du tillatelsesflaten<\/h2>Oppsummert, som en liste du kan g\u00e5 gjennom f\u00f8r neste administrative transaksjon:
  • Behandle enhver tillatelsesendring (eier, modul, allowlist, terskel, proxy) som et uttak p\u00e5 st\u00f8rrelse med hele hvelvet.<\/li>
  • Krev bekreftelse utenfor signeringskanalen, for eksempel en videosamtale og en signert melding, for alle administrative endringer.<\/li>
  • Legg en obligatorisk timelock p\u00e5 privilegerte operasjoner, og et veto-quorum som kan kansellere i ventetiden.<\/li>
  • F\u00f8r et oppdatert register over alle aktive moduler, guards, eiere og allowlist-adresser, og fjern det som ikke lenger brukes.<\/li>
  • Varsle automatisk p\u00e5 enhver endring i hvem som har makt, uavhengig av bel\u00f8p, ikke bare p\u00e5 store overf\u00f8ringer.<\/li>
  • Velg minst tre signat\u00e6rer, terskel p\u00e5 minst 50 prosent, sju eller flere for verdier over rundt ti millioner kroner, og unng\u00e5 N-av-N.<\/li>
  • Spre signat\u00e6rene p\u00e5 ulike maskinvaremodeller, ulike produsenter og ulike steder, med minst \u00e9n ekstern part.<\/li>
  • Signer p\u00e5 en dedikert, luftgappet enhet, og verifiser transaksjonens hash uavhengig p\u00e5 en ren maskin.<\/li>
  • Bruk clear signing der det finnes, men husk at det viser hva du signerer, ikke om kontrakten eller modulen er trygg.<\/li>
  • Gjennomg\u00e5 tilgang jevnlig, offboard raskt, og \u00f8v p\u00e5 en skriftlig katastrofeplan minst \u00e9n gang i \u00e5ret.<\/li><\/ul>

    Ofte stilte sp\u00f8rsm\u00e5l<\/h2>

    Hva er en multisig-lommebok?<\/h3>En multisig er en lommebok der flere av et sett n\u00f8kler m\u00e5 godkjenne en transaksjon f\u00f8r den utf\u00f8res, for eksempel tre av fem. Hensikten er at \u00e9n enkelt kompromittert n\u00f8kkel ikke skal v\u00e6re nok til \u00e5 flytte midler. Modellen beskytter godt mot rent n\u00f8kkeltyveri, men ikke mot at nok signat\u00e6rer blir lurt til \u00e5 godkjenne feil ting.

    Hvorfor er en tillatelsesendring farligere enn en vanlig overf\u00f8ring?<\/h3>En overf\u00f8ring t\u00f8mmer hvelvet \u00e9n gang, mens en tillatelsesendring, som en ny eier, en aktivert modul eller en endret allowlist, gir angriperen en st\u00e5ende mulighet til \u00e5 komme tilbake. I Base-hvelvet i oktober 2026 holdt tre gyldige signaturer til \u00e5 legge en ondsinnet kontrakt p\u00e5 l\u00e5nelista, som deretter kunne l\u00e5ne mot hvelvets posisjon. Derfor b\u00f8r enhver privilegert endring styres like strengt som et stort uttak.

    Stopper flere signat\u00e6rer et multisig-angrep?<\/h3>Ikke n\u00f8dvendigvis. Alle de store sakene i 2026 skjedde i multisiger som fulgte anbefalte terskler, fordi angriperen hadde skaffet seg akkurat de signaturene som trengtes gjennom kompromitterte enheter, sosial manipulasjon eller en manipulert skjerm. Terskel og mangfold beskytter mot tapte og stj\u00e5lne n\u00f8kler, ikke mot en signat\u00e6r som godkjenner feil ting.

    Hva er clear signing, og l\u00f8ser det blindsignering?<\/h3>Clear signing, standardisert gjennom ERC-7730 og Ethereum Foundations Clear Signing-initiativ fra mai 2026, lar lommeboken vise en transaksjon i lesbar tekst i stedet for en uleselig datablokk. Det l\u00f8ser blindsignering, der signat\u00e6ren ikke ser hva som faktisk godkjennes. Men det kan ikke fortelle deg om kontrakten eller modulen du godkjenner, er trygg, s\u00e5 menneskelig verifisering er fortsatt n\u00f8dvendig.

    Er en DeFi-multisig beskyttet av Finanstilsynet og MiCA?<\/h3>Nei, ikke hvis den er et rent selvforvart eller anonymt hvelv uten en identifiserbar tilbyder. Finanstilsynet f\u00f8rer tilsyn med registrerte CASP-er, som er underlagt MiCA artikkel 75 om segregering og ansvar, men en anonym DeFi-multisig er ingen CASP og faller utenfor. Da er dine egne rutiner hele forsvaret, og tap m\u00e5 h\u00e5ndteres i skattemeldingen til Skatteetaten.