Cursor lagrer ikke API-nøkler i beskyttet lagring, noe som betyr at alle utvidelser kan få tilgang til dem. Cursor visste om denne sårbarheten, men fikset den ikke.

Kortfattet sammendrag

LayerXs sikkerhetsforskere har funnet ut at enhver utvidelse av det populære AI-utviklingsverktøyet Cursor kan få tilgang til utviklerens API-nøkler og økttokener, noe som fører til fullstendig kompromittering av legitimasjon, uten behov for brukerinteraksjon eller aktivitet i det hele tatt. 

LayerX oppdaget at siden Cursor ikke lagrer nøkler i beskyttet lagring, noen Cursor-utvidelsen kan utføre denne tilgangen. Som et resultat er alle Cursor-brukere sårbare for API-nøkkeltyveri av uvedkommende Cursor-utvidelser.

Utnyttelse av denne sårbarheten kan føre til eksponering av økttokener og API-nøkler, uautorisert tilgang til Cursor-backend-tjenester og datatyveri via brukeridentifikasjon.

LayerX rapporterte denne sårbarheten til Cursor. Cursor svarte at de kjenner igjen problemet, men at det er brukerens ansvar å definere sin egen tillitsgrense. Til dags dato har ikke dette problemet blitt løst av Cursor.

 

Markør-API-nøkler lagres i en åpen, lokal database

Cursor, et populært AI-drevet utviklingsmiljø, inneholder en svært alvorlig sårbarhet for tilgangskontroll (CVSS 8.2) som tillater at alle installerte utvidelser får tilgang til sensitive legitimasjonsopplysninger som er lagret lokalt.

I motsetning til standard sikkerhetspraksis der hemmeligheter som API-nøkler og økttokener lagres i beskyttet lagring (f.eks. OS-nøkkelringer), lagrer Cursor disse påloggingsinformasjonene i en lokal SQLite-database:

` ~/Bibliotek/Programstøtte/Markør/Bruker/globalStorage/state.vscdb `

Det er kritisk at Cursor ikke håndhever tilgangskontrollgrenser mellom utvidelser og denne databasen. Som et resultat kan enhver utvidelse – uavhengig av deklarerte tillatelsene – lese direkte fra den og trekke ut sensitive data.

Dette skaper et kraftig angrepsprinsipp: en ondsinnet eller kompromittert Cursor-utvidelse kan stille stramme API-nøkler og økttokener, noe som muliggjør kontoovertakelse, datatilgang og økonomisk misbruk.

 

Impact

Denne sårbarheten muliggjør fullstendig kompromittering av legitimasjon uten brukermedvirkning (utover å installere en utvidelse), noe som fører til:

  • Eksponering av økttokener og API-nøkler
  • Uautorisert tilgang til Cursor-backend-tjenester
  • Kompromittering av tredjepartsintegrasjoner (f.eks. OpenAI, Anthropic, Google)
  • Brukeridentifikasjon og datatilgang

Nedstrømsrisiko (eksempel: Tyveri av OpenAI API-nøkkel)

Hvis en angriper får tak i et offers OpenAI API-nøkkel, kan de:

  • Utfør API-kall fakturert til offeret → økonomisk tap
  • Tilgangsforespørsler, fullføringer og metadata → dataeksponering
  • Misbruk API-et for ytterligere angrep eller automatisering
  • Potensielt utlede sensitiv informasjon fra tidligere interaksjoner

Fordi disse nøklene ofte gir bred tilgang, strekker virkningen seg utover selve Cursor til brukerens bredere AI- og utviklingsøkosystem.

 

Teknisk oversikt

La oss se på et realistisk angrepsscenario fra angriperens perspektiv.

Figur 1. Utnyttelsesflyt

Trinn 1: Klargjøring av den skadelige utvidelsen

En angriper lager en tilsynelatende godartet Cursor-utvidelse – kanskje et produktivitetsverktøy, tema eller hjelpeverktøy. Den ber ikke om noen mistenkelige tillatelser og ser ut til å være trygg å installere.

Fra brukerens perspektiv ser ingenting uvanlig ut.

Trinn 2: Brukeren installerer utvidelsen

En utvikler installerer utvidelsen fra en markedsplass eller et GitHub-repositorium.

Det finnes:

  • Ingen advarsel
  • Ingen tillatelsesforespørsel relatert til tilgang til legitimasjon
  • Ingen indikasjon på risiko

På dette tidspunktet har angriperen kodekjøring i Cursor-utvidelsesmiljøet.

Trinn 3: Tilgang til sensitiv lagring

Markøren lagrer sensitive data i en lokal SQLite-database nevnt ovenfor. Denne databasen inneholder:

  • Økttokener
  • API-nøkler (f.eks. OpenAI)
  • Andre autentiseringsartefakter

På grunn av manglende håndheving av tilgangskontroll kan utvidelsen åpne og spørre denne databasen direkte. Ingen spesielle rettigheter kreves.

Trinn 4: Uttrekk av legitimasjon

Utvidelsen analyserer databasen og trekker ut:

  • API-nøkler
  • Økttokener
  • Muligens hurtigbufret konfigurasjon eller metadata

Figur 2. Eksempel på databasespørring fra PoC-utvidelse

Fordi dataene er lagret i klartekst (eller ikke tilstrekkelig beskyttet), er utvinningen enkel.

Trinn 5: Stille utrenskning

Utvidelsen sender de stjålne legitimasjonene til en angriperkontrollert server, noe som kan gjøres med en enkel henting. Dette skjer stille:

  • Ingen brukerinteraksjon kreves
  • Ingen synlige endringer i brukergrensesnittet
  • Ingen varsler

Trinn 6: Etterutnyttelse

Angriperen har nå gyldige legitimasjonsopplysninger.

Hvorfor dette er høy alvorlighetsgrad

Denne sårbarheten er spesielt farlig fordi:

  • Ingen tillatelser kreves
  • Ingen brukermedvirkning kreves etter installasjon 
  • Lav angrepskompleksitet
  • Høy konfidensialitetspåvirkning

For å fremheve hvor lett dette kan utnyttes, har vi laget en PoC-utvidelse og en demovideo:

 

Tidslinje for offentliggjøring:

Selv om rapporten viser at utvidelser kan få tilgang til den lokale SQLite-databasen som inneholder påloggingsinformasjon, er denne tilgangen begrenset til den lokale maskinen der brukeren allerede har installert og gitt tillatelser til utvidelsen. Dette representerer den samme tillitsgrensen som alle andre lokale applikasjoner – ondsinnede utvidelser med tilgang til lokalt filsystem kan potensielt få tilgang til ulike applikasjonsdatalagre.

  • Rett statusIkke løst. Tirsdag 28. april 2026 

Anbefalt utbedring

For å løse dette problemet på riktig måte, må markøren:

  • Håndhev streng isolasjon mellom utvidelser og lagring av sensitiv legitimasjon.
  • Sensitive påloggingsinformasjoner bør håndteres via et sikkert, kryptert lagringslag eller en nøkkelring på systemnivå (f.eks. macOS-nøkkelring, Windows Credential Manager).