Angrebene knækker ikke selve kryptografien bag WebAuthn eller FIDO2. I stedet udnytter de svagheder i Chromes cloudbaserede autentificering og i processen, hvor en enhed tilknyttes igen . Alle tre angreb forudsætter, at Windows-computeren allerede er kompromitteret af malware.

Tre angreb – tre forskellige svagheder

Pass-ta-key: Den grundlæggende variant

I den første variant udtrækker malware Chromes TPM-indpakkede enhedsidentitetsnøgle fra den lokale fil passkey_enclave_state. Nøglen bruges derefter via legitime Windows CNG-API'er til at signere angriberens egne forespørgsler.

Resultatet er en gyldig WebAuthn-godkendelse, uden at offeret ser en anmodning om fingeraftryk, pinkode eller anden brugerinteraktion. Angrebet virker dog kun mod tjenester, der ikke kontrollerer bit'et for User Verified (UV) i autentificeringsdataene .

Det udnytter: at cloud-autentificeringen stoler på en lokalt gemt enhedsidentitetsnøgle, samt at nogle websteder ikke håndhæver brugerbekræftelse.

Silver Pass-ta-key: Omgår også brugerbekræftelse

Silver-varianten sletter eller ugyldiggør den lokale passkey_enclave_state-fil, så Chrome tvinges til at tilknytte enheden på ny. Under denne gentilmelding opretter Chrome kortvarigt UV-nøglen i et forsinket forløb. I dette tidsrum kan angriberen registrere sin egen UV-nøgle.

Googles cloud-autentificering validerer ikke attesteringen af den nye nøgle. Derfor får godkendelser, der er signeret med angriberens nøgle, UV-flaget sat til 1 – også på websteder, der kræver brugerbekræftelse. Angriberen får dermed en varig adgang fra sin egen computer, og offerets enhed behøver ikke længere være online .

Det udnytter: manglende attestationskontrol ved gentilmelding af en enhed og muligheden for at slette enclave-statusfilen uden beskyttelse.

Golden Pass-ta-key: Den kritiske variant

Den alvorligste variant starter på samme måde med en ny tilknytning af enheden. Derefter dumper malware Chromes proceshukommelse for at finde Security Domain Secret (SDS).

SDS er en 32 byte lang symmetrisk nøgle, der krypterer alle synkroniserede adgangsnøgler på brugerens Google-konto. Med SDS kan en angriber dekryptere både eksisterende og fremtidige synkroniserede private adgangsnøgler. Det kan i praksis give fuld kontrol over alle tjenester, der er beskyttet af disse nøgler .

Google skrev tidligere SDS i klartekst i Chromes output fra chrome://device-log/FIDO. Denne logning er siden blevet fjernet efter Unit 42's rapportering, men problemet med, at hemmeligheden kan være tilgængelig i Chromes hukommelse, består fortsat .

Det udnytter: at SDS ligger i klartekst i Chromes proceshukommelse under tilknytningsforløbet.

Hvilke websteder var berørt?

Den grundlæggende Pass-ta-key-teknik kan ramme alle tjenester, der ikke kontrollerer UV-flaget. Unit 42 identificerede eBay som et eksempel på et websted, der ikke håndhævede kontrollen. eBay har siden rettet problemet .

Forskerne bemærkede, at et overraskende stort antal websteder angiver userVerification: "required", når en adgangsnøgle oprettes, men aldrig kontrollerer det UV-bit, der returneres ved login .

Hvad betyder en stjålet SDS-hovednøgle?

SDS fungerer som hovednøglen til alle synkroniserede adgangsnøgler på Google-kontoen. Hvis den bliver stjålet:

• kan alle eksisterende synkroniserede private adgangsnøgler dekrypteres, og nye nøgler, der senere synkroniseres, kan også læses
• kan angriberen logge ind på alle konti, der er beskyttet med de pågældende adgangsnøgler – herunder Gmail – uden yderligere handling fra offeret
• kan adgangen til Gmail bruges til at nulstille adgangskoder til andre konti, så konsekvenserne rækker langt ud over de tjenester, der direkte bruger adgangsnøglerne
• findes der ingen indbygget funktion til at rotere SDS; Google tilbyder ikke brugerne en måde at oprette en ny SDS på

Sådan kan risikoen begrænses

På baggrund af Unit 42's resultater er de vigtigste anbefalinger:

• Registrér mindst én fysisk sikkerhedsnøgle, for eksempel en YubiKey, ud over den synkroniserede adgangsnøgle. Enhedsbundne legitimationsoplysninger synkroniseres ikke til skyen, gemmes ikke i Chromes enclave-status og kan ikke læses fra proceshukommelsen .
• Aktivér Googles Advanced Protection Program, hvis kontoen tilhører en bruger med høj risiko, som eksempelvis en journalist, leder, aktivist eller administrator. Programmet kræver sikkerhedsnøgler eller enhedsbundne adgangsnøgler og styrker mulighederne for kontogendannelse .
• Gennemgå enhedslisten på Google-kontoen hver måned, og fjern ukendte sessioner .
• Betragt en infektion med infostealer-malware som en fuld nulstilling af legitimationsoplysninger. Når kontoen er sikret, bør computeren genopbygges, og alle adgangsnøgler registreres igen fra en ren enhed .
• Tjenesteudbydere skal kontrollere UV-flaget på serversiden og bruge userVerification: "required" – ikke "preferred" – ved følsomme handlinger .

Status lige nu

På offentliggørelsestidspunktet, den 3. august 2026, var der ikke tildelt et CVE-nummer, og Google havde ikke offentligt bekræftet, om Silver- eller Golden-angrebsvejene ville blive rettet direkte .

Angrebene knækker ikke selve kryptografien bag WebAuthn eller FIDO2. I stedet udnytter de svagheder i Chromes cloudbaserede autentificering og i processen, hvor en enhed tilknyttes igen . Alle tre angreb forudsætter, at Windows-computeren allerede er kompromitteret af malware.

Tre angreb – tre forskellige svagheder

Pass-ta-key: Den grundlæggende variant

I den første variant udtrækker malware Chromes TPM-indpakkede enhedsidentitetsnøgle fra den lokale fil passkey_enclave_state. Nøglen bruges derefter via legitime Windows CNG-API'er til at signere angriberens egne forespørgsler.

Resultatet er en gyldig WebAuthn-godkendelse, uden at offeret ser en anmodning om fingeraftryk, pinkode eller anden brugerinteraktion. Angrebet virker dog kun mod tjenester, der ikke kontrollerer bit'et for User Verified (UV) i autentificeringsdataene .

Det udnytter: at cloud-autentificeringen stoler på en lokalt gemt enhedsidentitetsnøgle, samt at nogle websteder ikke håndhæver brugerbekræftelse.

Silver Pass-ta-key: Omgår også brugerbekræftelse

Silver-varianten sletter eller ugyldiggør den lokale passkey_enclave_state-fil, så Chrome tvinges til at tilknytte enheden på ny. Under denne gentilmelding opretter Chrome kortvarigt UV-nøglen i et forsinket forløb. I dette tidsrum kan angriberen registrere sin egen UV-nøgle.

Googles cloud-autentificering validerer ikke attesteringen af den nye nøgle. Derfor får godkendelser, der er signeret med angriberens nøgle, UV-flaget sat til 1 – også på websteder, der kræver brugerbekræftelse. Angriberen får dermed en varig adgang fra sin egen computer, og offerets enhed behøver ikke længere være online .

Det udnytter: manglende attestationskontrol ved gentilmelding af en enhed og muligheden for at slette enclave-statusfilen uden beskyttelse.

Golden Pass-ta-key: Den kritiske variant

Den alvorligste variant starter på samme måde med en ny tilknytning af enheden. Derefter dumper malware Chromes proceshukommelse for at finde Security Domain Secret (SDS).

SDS er en 32 byte lang symmetrisk nøgle, der krypterer alle synkroniserede adgangsnøgler på brugerens Google-konto. Med SDS kan en angriber dekryptere både eksisterende og fremtidige synkroniserede private adgangsnøgler. Det kan i praksis give fuld kontrol over alle tjenester, der er beskyttet af disse nøgler .

Google skrev tidligere SDS i klartekst i Chromes output fra chrome://device-log/FIDO. Denne logning er siden blevet fjernet efter Unit 42's rapportering, men problemet med, at hemmeligheden kan være tilgængelig i Chromes hukommelse, består fortsat .

Det udnytter: at SDS ligger i klartekst i Chromes proceshukommelse under tilknytningsforløbet.

Hvilke websteder var berørt?

Den grundlæggende Pass-ta-key-teknik kan ramme alle tjenester, der ikke kontrollerer UV-flaget. Unit 42 identificerede eBay som et eksempel på et websted, der ikke håndhævede kontrollen. eBay har siden rettet problemet .

Forskerne bemærkede, at et overraskende stort antal websteder angiver userVerification: "required", når en adgangsnøgle oprettes, men aldrig kontrollerer det UV-bit, der returneres ved login .

Hvad betyder en stjålet SDS-hovednøgle?

SDS fungerer som hovednøglen til alle synkroniserede adgangsnøgler på Google-kontoen. Hvis den bliver stjålet:

• kan alle eksisterende synkroniserede private adgangsnøgler dekrypteres, og nye nøgler, der senere synkroniseres, kan også læses
• kan angriberen logge ind på alle konti, der er beskyttet med de pågældende adgangsnøgler – herunder Gmail – uden yderligere handling fra offeret
• kan adgangen til Gmail bruges til at nulstille adgangskoder til andre konti, så konsekvenserne rækker langt ud over de tjenester, der direkte bruger adgangsnøglerne
• findes der ingen indbygget funktion til at rotere SDS; Google tilbyder ikke brugerne en måde at oprette en ny SDS på

Sådan kan risikoen begrænses

På baggrund af Unit 42's resultater er de vigtigste anbefalinger:

• Registrér mindst én fysisk sikkerhedsnøgle, for eksempel en YubiKey, ud over den synkroniserede adgangsnøgle. Enhedsbundne legitimationsoplysninger synkroniseres ikke til skyen, gemmes ikke i Chromes enclave-status og kan ikke læses fra proceshukommelsen .
• Aktivér Googles Advanced Protection Program, hvis kontoen tilhører en bruger med høj risiko, som eksempelvis en journalist, leder, aktivist eller administrator. Programmet kræver sikkerhedsnøgler eller enhedsbundne adgangsnøgler og styrker mulighederne for kontogendannelse .
• Gennemgå enhedslisten på Google-kontoen hver måned, og fjern ukendte sessioner .
• Betragt en infektion med infostealer-malware som en fuld nulstilling af legitimationsoplysninger. Når kontoen er sikret, bør computeren genopbygges, og alle adgangsnøgler registreres igen fra en ren enhed .
• Tjenesteudbydere skal kontrollere UV-flaget på serversiden og bruge userVerification: "required" – ikke "preferred" – ved følsomme handlinger .

Status lige nu

På offentliggørelsestidspunktet, den 3. august 2026, var der ikke tildelt et CVE-nummer, og Google havde ikke offentligt bekræftet, om Silver- eller Golden-angrebsvejene ville blive rettet direkte .