CVE-2026-56081: Kontokapring i Cap-go før 12.128.2
Cap-go før 12.128.2 lader angribere overtage konti bundet til jeres e-mail, inden den bekræftes. Opdatér til 12.128.2.
Hvad er det?
CVE-2026-56081 er en fejl i godkendelseslogikken i Cap-go, en tjeneste til at udrulle opdateringer til apps bygget med Capacitor-rammeværket over internettet, ofte kaldet OTA-opdateringer (over-the-air). Fejlen gør det muligt for en angriber at registrere og kontrollere en konto med et offers e-mailadresse, før offeret selv har bekræftet adressen. Angriberen aktiverer derefter to-faktor-godkendelse, en ekstra login-bekræftelse med kode, på den forudregistrerede konto og låser den dermed fast til sig selv, mens den rigtige ejer af e-mailen aldrig får adgang.
Hvem rammer det?
Sårbarheden rammer virksomheder og teams, der bruger Cap-go i versioner før 12.128.2 til at administrere og distribuere app-opdateringer. Det gælder både organisationer, der selv driver Cap-go, og medarbejdere, som endnu ikke har oprettet eller bekræftet deres konto i platformen. Særligt udsatte er nyansatte og teams, der er ved at rulle Cap-go ud i organisationen, hvor flere konti endnu ikke er bekræftede.
Hvad kan ske?
En angriber, der kender eller gætter en medarbejders arbejds-e-mail, kan registrere en konto med den adresse, inden medarbejderen selv opretter eller bekræfter sin. Angriberen sætter to-faktor-godkendelse på kontoen og overtager dermed adgangen til organisationens Cap-go-opsætning. Herfra kan angriberen læse og ændre kontodata og indstillinger og i værste fald pålægge hele organisationen politikker, mens den rigtige medarbejder er låst ude. Da Cap-go styrer udrulning af opdateringer til apps, kan en kapret konto potentielt bruges til at påvirke, hvad der ender i slutbrugernes apps.
Hvor alvorligt er det?
CVSS-score er 9,1 ud af 10, hvilket er kritisk. Angrebet kræver ikke login og ingen handling fra offeret: angriberen udnytter fejlen alene ved at registrere en konto over internettet. Fortrolighed og integritet er ramt i højeste grad, fordi angriberen kan læse og ændre kontodata og organisationsindstillinger. Tilgængelighed er ikke direkte påvirket, men den legitime bruger nægtes adgang til sin egen konto. Der er ikke oplysninger om aktiv udnyttelse, men angrebet er enkelt at udføre og kræver kun kendskab til en e-mailadresse.
Hvad gør jeg nu?
Følgende trin lukker hullet og begrænser skaden, hvis det allerede er udnyttet.
- Opdatér Cap-go til version 12.128.2 eller nyere, som lukker fejlen i godkendelseslogikken.
- Gennemgå alle brugerkonti i organisationen for ubekræftede e-mailadresser, og nulstil eller slet dem, der ikke kan forklares.
- Kontrollér, om medarbejderkonti allerede har to-faktor-godkendelse aktiveret af en ukendt part, og kontakt Cap-go support hvis det er tilfældet.
- Skift adgangskoder og gennemgå organisationens medlemsliste og roller for uautoriserede ændringer.
- Kræv e-mailbekræftelse, før en konto kan bruges, hvis platformens konfiguration tillader det.
- Hvis I finder tegn på, at en konto allerede er kapret, eller I er i tvivl om omfanget, bør I hente ekstern hjælp til at undersøge og lukke sagen.
Opdatér inden for få dage
Vi anbefaler, at I opdaterer til Cap-go 12.128.2 hurtigst muligt og samtidig gennemgår, om nogen konti i organisationen står med ubekræftet e-mail eller uventet aktiveret to-faktor-godkendelse. Det er kun forsvarligt at afvente opdateringen, hvis I er helt sikre på, at alle konti i jeres organisation allerede er bekræftede, hvilket i praksis sjældent kan garanteres for en hel medarbejderstab.
Tidslinje
Konkrete eksempler
Nyansat medarbejder i en dansk virksomhed
En dansk virksomhed opretter Cap-go-konti til nye medarbejdere, men en ny udvikler har endnu ikke bekræftet sin arbejds-e-mail. En angriber, der har gættet e-mailformatet ud fra virksomhedens hjemmeside, registrerer en konto med den samme adresse og aktiverer to-faktor-godkendelse. Da udvikleren senere forsøger at logge ind, er kontoen allerede overtaget, og it-afdelingen skal først opdage og oprydde problemet, før udvikleren kan få adgang igen.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er ramt, hvis jeres organisation bruger Cap-go i en version ældre end 12.128.2. Tjek versionsnummeret i jeres administrationspanel, og opdatér hvis det ligger under 12.128.2.
Hvordan tjekker vi, om en konto allerede er kapret?
Gå ind i organisationens brugerliste, og se efter konti med ubekræftet e-mail eller nyligt aktiveret to-faktor-godkendelse, som ingen i jeres it-afdeling kan genkende. Kontakt Cap-go support, hvis I finder mistænkelige konti.
Kan vi vente til weekenden med at opdatere?
Det bør I ikke, hvis jeres organisation har medarbejdere med endnu ubekræftede konti. Sårbarheden kræver ikke login eller brugerhandling, så risikoen findes, så længe I ikke har opdateret.
Skal vi anmelde dette til en myndighed?
Kun hvis I konstaterer, at en konto faktisk er kompromitteret og persondata eller forretningskritiske oplysninger er blevet tilgået. I så fald skal I vurdere anmeldepligt efter databeskyttelsesreglerne.
Hvad er to-faktor-godkendelse, og hvorfor gør det angrebet værre?
To-faktor-godkendelse er en ekstra bekræftelseskode ved login, som normalt gør konti mere sikre. Her bruger angriberen funktionen til at låse den forudregistrerede konto fast til sig selv, så den rigtige ejer ikke kan overtage den igen.
Påvirker fejlen kun nyoprettede konti?
Fejlen opstår, mens en e-mailadresse endnu ikke er bekræftet, så den er mest relevant for nye medarbejdere eller organisationer, der er ved at rulle Cap-go ud. Allerede bekræftede konti er ikke i samme risiko.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
Cap-go before 12.128.2 contains an authentication logic flaw that lets an attacker register and control an account bound to a victim’s email address before that email is verified. By enabling two-factor authentication on the pre-registered account, the attacker gains control over the account claimed under the victim’s identity, allowing them to read and modify its state and enforce organization-level policies, while the legitimate user is denied access to the account tied to their own email.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.