CursorJacking: Rogue Cursor Extensions Can Steal AI API Keys
LayerX reported that Cursor stores API keys and session tokens in a local SQLite database that any installed Cursor extension can read. The attack does not need a prompt injection or user interaction after installation: a benign-looking extension can extract OpenAI, Anthropic, Google, or Cursor credentials and quietly exfiltrate them. The defensive lesson is that AI coding IDEs need protected credential storage, per-extension permission enforcement, and enterprise extension governance.
The secret store was not a real boundary. LayerX says Cursor stores credentials in state.vscdb, not behind an OS keychain or credential manager.
Any installed extension became a credential reader. A theme, helper, or productivity extension can query the local SQLite database without an obvious credential-access prompt.
The blast radius leaves Cursor. The database can hold Cursor session tokens and OpenAI, Anthropic, or Google keys; stolen keys enable impersonation, paid API abuse, and prompt or completion exposure.
This is extension supply chain, not model behavior. After installation, the attack path is local code reading local storage and sending the result to an attacker server.
Trust semantics matter. If a product treats all extensions as the same local trust boundary, enterprises need extension allowlisting and protected storage before using real keys.
This is the primary control. API keys, OAuth tokens, refresh tokens, and session tokens should live in platform-native secure storage or a managed secret store, not in a local database every extension can open. Storage also needs lifecycle controls: expiry, rotation, logout cleanup, uninstall cleanup, and server-side deauthorization.
Cursor extensions should not get ambient access to all local IDE state. Each extension needs a machine-readable permission manifest and a runtime interceptor that blocks undeclared file reads, protected credential paths, outbound network destinations, shell use, and privileged IDE APIs. A theme extension should not be able to read state.vscdb or post its contents to the internet.
Enterprises need a central inventory of installed Cursor extensions and similar AI IDE plugins: source, publisher, version, hash, owner, approval state, permission scope, last scan, and usage. That inventory is what lets a security team disable a risky extension across machines instead of hoping each developer cleans up their own environment.
Cursor is a local AI-enabled client, so the security boundary has to include the extension host, local application context, credential stores, and native bridge. Client-side isolation should prevent untrusted extension code from reaching secrets, other workspace state, OS resources, or privileged application APIs unless those capabilities are explicitly granted.
LayerX's attack flow ends with silent exfiltration by a simple outbound request. If extension execution is sandboxed, default-deny egress and narrow allowlists make credential theft harder to complete even when an extension manages to read something sensitive.
Stolen provider keys hurt less when they are scoped, short-lived, tied to a workspace or service identity, and monitored by provider and owner. Avoid shared organization-wide API keys inside developer IDEs; use separate credentials for development, testing, and production-sensitive workflows.
Honey Data, Decoy Artifacts & Canary Tokens for AI
Medium
Canary API keys placed in plausible but non-production credential locations can reveal whether a rogue extension or local process is scraping secrets. The key must never grant real access; any attempted use should create a high-confidence alert with device, user, extension, and destination context.
One downstream impact is paid API abuse after an OpenAI, Anthropic, Google, or Cursor key is stolen. Per-key monitoring for cost spikes, abnormal model usage, unusual request parameters, new geographies, and replay-like behavior helps detect compromise before a stolen key becomes a large bill or broader data incident.
When a canary fires, a secret scanner finds exposure, or provider telemetry shows suspicious API use, response should not wait for a manual ticket. The affected API key, session token, refresh token, or IDE authorization should be revoked immediately and propagated to the service path that accepts it.
What Defenders Should Do Now
Inventory Cursor and other AI coding IDE installations, then list every installed extension, its source, version, publisher, declared permissions, and whether it runs on machines that hold AI provider keys or cloud credentials.
Move API keys, session tokens, refresh tokens, and provider credentials out of readable local databases or config files. Prefer OS keychains, encrypted secret stores, short token lifetimes, and logout or uninstall cleanup.
Block unapproved extensions on developer machines that handle sensitive work. At minimum, separate experimental extension testing from workspaces that contain real customer data, production access, or billable AI provider keys.
Enforce file and network boundaries around the extension host. Extensions should not be able to read credential databases, cloud CLI profiles, .env files, SSH keys, or secrets managers unless their manifest explicitly requires it and the policy approves it.
Add detections for suspicious local reads and egress: extension processes opening Cursor credential storage, unknown extensions making outbound requests, provider keys used from new locations, and sudden API spend or model-usage spikes.
If exposure is possible, rotate affected OpenAI, Anthropic, Google, Cursor, and cloud keys; revoke active sessions; review provider logs for recent use; and remove any extension that cannot be tied to a trusted source and owner.
1 additional consideration
Enterprise policy for AI IDEs that cannot enforce extension isolation
Beyond the techniques mapped above, teams should also treat AI coding IDEs as endpoint platforms with their own trust boundary. If an IDE cannot keep extensions away from credential storage, the enterprise may need a stricter policy: no production AI keys in that IDE, no unapproved extensions on secret-bearing workstations, and separate profiles for experimental extension testing.
Recommendation: Classify each AI IDE by what local secrets it stores and whether it can enforce per-extension file and network controls. Permit real provider keys only in approved builds with protected storage, managed extension allowlists, and monitored egress.
Conclusion
CursorJacking is useful because it makes an AI IDE trust boundary visible. The model did not need to misbehave, and the user did not need to approve a dangerous prompt. The failure was simpler: a local extension could read credentials that should have lived behind a stronger boundary. AIDEFEND ↗ maps the baseline clearly: protect client credentials, govern installed skills and extensions, enforce per-extension permissions, contain client-side execution, monitor downstream key abuse, and revoke exposed credentials quickly.