Cursor lagrar inte API-nycklar i skyddad lagring, vilket innebär att alla tillägg kan komma åt dem. Cursor kände till den här sårbarheten men åtgärdade den inte.

Sammanfattning

Säkerhetsforskare på LayerX har upptäckt att alla tillägg av det populära AI-utvecklingsverktyget Cursor kan komma åt utvecklarens API-nycklar och sessionstokens, vilket leder till fullständig kompromettering av autentiseringsuppgifter, utan behov av användarinteraktion eller aktivitet alls. 

LayerX upptäckte att eftersom Cursor inte lagrar nycklar i skyddad lagring, vilken som helst Cursor-tillägget kan utföra denna åtkomst. Som ett resultat är alla Cursor-användare sårbara för API-nycklarstöld av otillåtna Cursor-tillägg.

Utnyttjande av denna sårbarhet kan leda till exponering av sessionstokens och API-nycklar, obehörig åtkomst till Cursor-backendtjänster och datastöld via användarimitation.

LayerX rapporterade denna sårbarhet till Cursor. Cursor svarade att de känner igen problemet, men att det är användarens ansvar att definiera sin förtroendegräns. Hittills har problemet inte åtgärdats av Cursor.

 

Markörens API-nycklar lagras i en öppen, lokal databas

Cursor, en populär AI-driven utvecklingsmiljö, innehåller en allvarlig sårbarhet för åtkomstkontroll (CVSS 8.2) som tillåter alla installerade tillägg att komma åt känsliga inloggningsuppgifter som lagras lokalt.

Till skillnad från vanliga säkerhetsrutiner där hemligheter som API-nycklar och sessionstokens lagras i skyddad lagring (t.ex. OS-nyckelringar), lagrar Cursor dessa inloggningsuppgifter i en lokal SQLite-databas:

` ~/Bibliotek/Programsupport/Markör/Användare/globalStorage/state.vscdb `

Viktigt är att Cursor inte tillämpar åtkomstkontrollgränser mellan tillägg och denna databas. Som ett resultat kan alla tillägg – oavsett dess deklarerade behörigheter – läsa direkt från den och extrahera känsliga data.

Detta skapar en kraftfull attackprimitiv: ett skadligt eller komprometterat Cursor-tillägg kan tyst stjäla API-nycklar och sessionstokens, vilket möjliggör kontoövertagande, dataåtkomst och ekonomiskt missbruk.

 

Inverkan

Denna sårbarhet möjliggör fullständig kompromettering av autentiseringsuppgifter utan användarinteraktion (utöver installation av ett tillägg), vilket leder till:

  • Exponering av sessionstokens och API-nycklar
  • Obehörig åtkomst till Cursor backend-tjänster
  • Kompromittering av tredjepartsintegrationer (t.ex. OpenAI, Anthropic, Google)
  • Användarimitation och dataåtkomst

Nedströmsrisk (exempel: OpenAI API-nyckelstöld)

Om en angripare får tag på ett offers OpenAI API-nyckel kan de:

  • Utför API-anrop som faktureras till offret → ekonomisk förlust
  • Åtkomst till uppmaningar, slutföranden och metadata → dataexponering
  • Missbruka API:et för ytterligare attacker eller automatisering
  • Potentiellt härleda känslig information från tidigare interaktioner

Eftersom dessa nycklar ofta ger bred åtkomst sträcker sig effekten bortom själva Cursor till användarens bredare AI- och utvecklingsekosystem.

 

Teknisk översikt

Låt oss gå igenom ett realistiskt attackscenario ur angriparens perspektiv.

Figur 1. Exploateringsflöde

Steg 1: Förbereda den skadliga tillägget

En angripare skapar ett till synes oskyldigt Cursor-tillägg – kanske ett produktivitetsverktyg, tema eller hjälpprogram. Det begär inga misstänkta behörigheter och verkar säkert att installera.

Ur användarens perspektiv ser ingenting ovanligt ut.

Steg 2: Användaren installerar tillägget

En utvecklare installerar tillägget från en marknadsplats eller ett GitHub-arkiv.

Det finns:

  • Ingen varning
  • Ingen behörighetsfråga relaterad till åtkomst till autentiseringsuppgifter
  • Ingen indikation på risk

Vid det här laget har angriparen kodkörning i Cursor-tilläggsmiljön.

Steg 3: Åtkomst till känslig lagring

Cursor lagrar känsliga data i en lokal SQLite-databas som nämnts ovan. Denna databas innehåller:

  • Sessionstokens
  • API-nycklar (t.ex. OpenAI)
  • Andra autentiseringsartefakter

På grund av saknad åtkomstkontroll kan tillägget öppna och fråga den här databasen direkt. Inga särskilda behörigheter krävs.

Steg 4: Extrahering av autentiseringsuppgifter

Tillägget analyserar databasen och extraherar:

  • API-nycklar
  • Sessionstokens
  • Möjligen cachade konfigurationer eller metadata

Figur 2. Exempel på databasfråga från PoC-tillägget

Eftersom informationen lagras i klartext (eller otillräckligt skyddad) är extraheringen enkel.

Steg 5: Tyst exfiltrering

Tillägget skickar de stulna inloggningsuppgifterna till en angriparkontrollerad server, vilket kan göras med en enkel hämtning. Detta sker tyst:

  • Ingen användarinteraktion krävs
  • Inga synliga ändringar i användargränssnittet
  • Inga varningar

Steg 6: Efter exploatering

Angriparen har nu giltiga inloggningsuppgifter.

Varför detta är hög allvarlighetsgrad

Denna sårbarhet är särskilt farlig eftersom:

  • Inga behörigheter krävs
  • Ingen användarinteraktion krävs efter installationen 
  • Låg attackkomplexitet
  • Hög konfidentialitetspåverkan

För att belysa hur lätt detta kan utnyttjas skapade vi en PoC-tillägg och en demovideo:

 

Tidslinje för offentliggörande:

Även om rapporten visar att tillägg kan komma åt den lokala SQLite-databasen som innehåller inloggningsuppgifter, är denna åtkomst begränsad till den lokala datorn där användaren redan har installerat och beviljat behörighet till tillägget. Detta representerar samma förtroendegräns som för alla andra lokala applikationer – skadliga tillägg med lokal filsystemåtkomst kan potentiellt komma åt olika applikationsdatalager.

  • Åtgärda statusInte åtgärdat. Tis, 28 april 2026 

Rekommenderad åtgärd

För att korrekt åtgärda detta problem måste markören:

  • Tillämpa strikt isolering mellan tillägg och lagring av känsliga autentiseringsuppgifter.
  • Känsliga inloggningsuppgifter bör hanteras via ett säkert, krypterat lagringslager eller en nyckelring på systemnivå (t.ex. macOS-nyckelring, Windows Credential Manager).