Hindi iniimbak ng Cursor ang mga API key sa protektadong storage, ibig sabihin ay maaaring ma-access ang mga ito ng anumang extension. Alam ng Cursor ang tungkol sa kahinaang ito ngunit hindi niya ito inayos.

Executive Buod

Natuklasan ng mga mananaliksik sa seguridad ng LayerX na ang anumang extension ng sikat na tool sa pagbuo ng AI na Cursor ay maaaring ma-access ang mga API key at session token ng developer, na humahantong sa ganap na pagkompromiso sa kredensyal, nang hindi na kailangan ng pakikipag-ugnayan o aktibidad ng user. 

Natuklasan ng LayerX na dahil hindi iniimbak ng Cursor ang mga susi sa protektadong imbakan, anumang Maaaring isagawa ng extension ng Cursor ang access na ito. Bilang resulta, ang bawat gumagamit ng Cursor ay maaaring mabiktima ng pagnanakaw ng API key ng mga pekeng extension ng Cursor.

Ang pagsasamantala sa kahinaang ito ay maaaring humantong sa pagkakalantad ng mga session token at API key, hindi awtorisadong pag-access sa mga serbisyo ng Cursor backend, at pagnanakaw ng data sa pamamagitan ng panggagaya ng user.

Iniulat ng LayerX ang kahinaang ito sa Cursor. Sumagot ang Cursor na kinikilala nila ang isyu, ngunit responsibilidad ng gumagamit na tukuyin ang kanilang hangganan ng tiwala. Sa ngayon, ang isyung ito ay hindi pa naaayos ng Cursor.

 

Ang mga Cursor API Key ay Nakaimbak sa Isang Bukas, Lokal na DB

Ang Cursor, isang sikat na kapaligirang pang-development na pinapagana ng AI, ay naglalaman ng isang kahinaan sa pagkontrol ng access na may mataas na antas ng kalubhaan (CVSS 8.2) na nagpapahintulot sa anumang naka-install na extension na ma-access ang mga sensitibong kredensyal na lokal na nakaimbak.

Hindi tulad ng mga karaniwang kasanayan sa seguridad kung saan ang mga sikreto tulad ng mga API key at session token ay nakaimbak sa protektadong imbakan (hal., mga OS keychain), iniimbak ng Cursor ang mga kredensyal na ito sa isang lokal na database ng SQLite:

` ~/Aklatan/Suporta sa Aplikasyon/Cursor/Gumagamit/globalStorage/state.vscdb `

Sa kritikal na aspeto, hindi ipinapatupad ng Cursor ang mga hangganan ng kontrol sa pag-access sa pagitan ng mga extension at ng database na ito. Bilang resulta, ang anumang extension – anuman ang ipinahayag na mga pahintulot nito – ay maaaring direktang magbasa mula rito at kumuha ng sensitibong data.

Lumilikha ito ng isang malakas na primitive na pag-atake: ang isang malisyosong o nakompromisong Cursor extension ay maaaring tahimik na mag-exfiltrate ng mga API key at session token, na nagbibigay-daan sa pagkuha ng account, pag-access sa data, at pang-aabusong pinansyal.

 

EPEKTO

Ang kahinaang ito ay nagbibigay-daan sa ganap na pagkompromiso ng kredensyal nang walang pakikipag-ugnayan ng user (maliban sa pag-install ng extension), na humahantong sa:

  • Paglalantad ng mga token ng sesyon at mga API key
  • Hindi awtorisadong pag-access sa mga serbisyo ng backend ng Cursor
  • Pagkompromiso sa mga integrasyon ng ikatlong partido (hal., OpenAI, Anthropic, Google)
  • Pagpapanggap ng gumagamit at pag-access sa data

Panganib sa Downstream (Halimbawa: Pagnanakaw ng OpenAI API Key)

Kung makuha ng isang umaatake ang OpenAI API key ng biktima, magagawa nila ang mga sumusunod:

  • Isagawa ang mga tawag sa API na sinisingil sa biktima → pagkalugi sa pananalapi
  • Mga prompt sa pag-access, pagkumpleto, at metadata → pagkakalantad ng data
  • Abusin ang API para sa karagdagang mga pag-atake o automation
  • Posibleng maghinuha ng sensitibong impormasyon mula sa mga naunang pakikipag-ugnayan

Dahil ang mga key na ito ay kadalasang nagbibigay ng malawak na access, ang epekto ay umaabot nang higit pa sa Cursor mismo patungo sa mas malawak na AI at development ecosystem ng user.

 

Pangkalahatang-ideya ng Teknikal

Talakayin natin ang isang makatotohanang senaryo ng pag-atake mula sa pananaw ng umaatake.

Pigura 1. Daloy ng Pagsasamantala

Hakbang 1: Paghahanda ng Malicious Extension

Lumilikha ang isang attacker ng tila hindi kanais-nais na Cursor extension – marahil isang productivity tool, theme, o helper utility. Hindi ito humihingi ng anumang kahina-hinalang pahintulot at mukhang ligtas i-install.

Mula sa pananaw ng gumagamit, walang kakaiba.

Hakbang 2: I-install ng User ang Extension

Ini-install ng isang developer ang extension mula sa isang marketplace o GitHub repository.

Mayroong:

  • Walang babala
  • Walang prompt ng pahintulot na nauugnay sa pag-access sa kredensyal
  • Walang indikasyon ng panganib

Sa puntong ito, ang attacker ay may code execution sa loob ng Cursor extension environment.

Hakbang 3: Pag-access sa Sensitibong Imbakan

Nag-iimbak ang cursor ng sensitibong datos sa isang lokal na database ng SQLite na nabanggit sa itaas. Ang database na ito ay naglalaman ng:

  • Mga token ng sesyon
  • Mga API key (hal., OpenAI)
  • Iba pang mga artifact ng pagpapatotoo

Dahil sa kawalan ng pagpapatupad ng access control, maaaring direktang buksan at i-query ng extension ang database na ito. Walang kinakailangang mga espesyal na pribilehiyo.

Hakbang 4: Pagkuha ng Kredensyal

Pina-parse ng extension ang database at kinukuha ang:

  • Mga API key
  • Mga token ng sesyon
  • Posibleng naka-cache na configuration o metadata

Pigura 2. Halimbawa ng Query sa DataBase mula sa PoC Extension

Dahil ang datos ay nakaimbak sa plaintext (o hindi sapat ang proteksyon), ang pagkuha ay madali lamang.

Hakbang 5: Tahimik na Pag-exfiltration

Ipinapadala ng extension ang mga ninakaw na kredensyal sa isang server na kontrolado ng attacker, na maaaring gawin sa pamamagitan ng simpleng pagkuha. Nangyayari ito nang tahimik:

  • Hindi kinakailangan ang pakikipag-ugnayan ng gumagamit
  • Walang nakikitang mga pagbabago sa UI
  • Walang mga alerto

Hakbang 6: Pagkatapos ng Pagsasamantala

Ang umaatake ay mayroon nang mga wastong kredensyal.

Bakit Ito Mataas ang Kalubhaan

Ang kahinaang ito ay lalong mapanganib dahil:

  • Walang kinakailangang pahintulot
  • Hindi kinakailangan ang pakikipag-ugnayan ng user pagkatapos ng pag-install 
  • Mababang pagiging kumplikado ng pag-atake
  • Mataas na epekto sa pagiging kumpidensyal

Upang itampok kung gaano kadali itong magamit, lumikha kami ng isang Pagpapalawig ng PoC at isang demo na video:

 

Takdang Panahon ng Pagbubunyag:

Bagama't ipinapakita ng ulat na maaaring ma-access ng mga extension ang lokal na database ng SQLite na naglalaman ng mga kredensyal, ang access na ito ay limitado sa lokal na makina kung saan na-install at nabigyan na ng user ng mga pahintulot ang extension. Kinakatawan nito ang parehong hangganan ng tiwala gaya ng anumang iba pang lokal na application – ang mga malisyosong extension na may access sa lokal na file system ay maaaring ma-access ang iba't ibang mga tindahan ng data ng application.

  • Ayusin ang katayuanHindi Naayos. Martes, ika-28 ng Abril 2026 

Inirerekomendang Remediasyon

Para maayos na matugunan ang isyung ito, dapat gawin ng Cursor ang mga sumusunod:

  • Magpatupad ng mahigpit na paghihiwalay sa pagitan ng mga extension at sensitibong imbakan ng kredensyal.
  • Ang mga sensitibong kredensyal ay dapat pangasiwaan sa pamamagitan ng isang ligtas at naka-encrypt na storage layer o system-level keychain (hal., macOS Keychain, Windows Credential Manager).