LayerX (Roy Paz) reported on 2026-04-28 that Cursor stores AI provider API keys and session tokens in a local SQLite database, state.vscdb, rather than behind an OS keychain or credential manager. Any installed Cursor extension can query that database without an obvious credential-access prompt, so a theme, helper or productivity extension can read OpenAI, Anthropic, Google or Cursor credentials and exfiltrate them with an ordinary outbound request. No prompt injection is involved and no user interaction is required after installation. Reported consequences are provider impersonation, paid API abuse, and exposure of prompts and completions through the stolen keys. The brief frames the underlying condition as trust semantics — a product that treats all extensions as the same local trust boundary — and the evidence reviewed documents a researcher-demonstrated weakness in the shipped product rather than an observed in-the-wild compromise.
ASSESSED SYSTEM
The Cursor AI coding IDE as a local AI client, in the configuration LayerX reported on 2026-04-28: its credential store (AI provider API keys and Cursor session tokens held in the local SQLite database state.vscdb), its extension host and the trust boundary between them, and the outbound network path available to extension code. The assessed unit is the client-side trust boundary, which is where the reported failure sits.
OUT OF SCOPE
Cursor's models and agent reasoning (the brief is explicit that this is 'extension supply chain, not model behavior'), Cursor's server-side infrastructure, the OpenAI/Anthropic/Google provider APIs themselves, and any Cursor release later than the reported configuration. No vendor fix is documented in the evidence reviewed, so no post-remediation state is assessed. This scores a reported product configuration at a point in time, not Cursor as a product line.
Architecture: Agentic / MCP System (decision tree Q2) — Q1 = NO: no two-or-more coordinating agents are described in the assessed path. Q2 = YES: Cursor is an AI coding IDE — a 'local AI-enabled client' in the brief's words, whose security boundary 'has to include the extension host, local application context, credential stores, and native bridge' — that executes multi-step editing workflows and invokes provider APIs under stored session credentials without per-action approval, and whose extension host admits third-party capability at runtime. The brief's own defensive mapping treats installed extensions as agentic skill assets requiring permission manifests and inventory (AID-H-018.007 Skill-Level Permission Manifest Validation, AID-M-001.003 Agentic Skill & Instruction Asset Inventory). The credential-theft path itself does not require the agent loop; the classification reflects the assessed system, not the exploit. Tier 3: Tier 3 Internal: a developer code assistant operating inside an organisational boundary with controlled users — the spec's own Tier 3 example — with exploitation requiring the user to install an extension on their own workstation.
Documented attack or failure path
- A user installs a Cursor extension — the only user action the path requires.
- The extension executes inside the extension host with the same ambient local trust as any other extension; no per-extension permission manifest constrains its file, credential or network access.
- It opens the local SQLite store state.vscdb and reads Cursor session tokens and OpenAI, Anthropic or Google API keys, with no credential-access prompt raised to the user.
- It sends the values to attacker infrastructure over a simple outbound request; egress from the extension host is not restricted by default-deny or an allowlist.
- The stolen provider keys are replayed for impersonation, billable API abuse and exposure of prompt and completion content; the Cursor session token additionally reaches Cursor-side state.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The path is local and post-install: exploitation requires the user to install the extension, and there is no remote or unauthenticated route to the credential store.
- The model layer was not the failing control — the brief notes explicitly that 'the model did not need to misbehave, and the user did not need to approve a dangerous prompt', so model-side guardrails were neither bypassed nor at fault.
- The stolen credentials remain revocable at their authoritative issuers, and provider-side usage logging supports post-hoc review of a stolen key's use; the brief's entire response playbook — rotate keys, revoke sessions, review provider logs for recent use — depends on those provider-side controls existing and working.
- Enterprise-side mitigations are available today without a product change: extension allowlisting, separating experimental extension testing from secret-bearing workspaces, and keeping real provider keys out of IDE builds that cannot enforce per-extension isolation.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.40 indeterminate | |||
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 3 MVT 0.45 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.25w 0.25 | 0.25 anchor: partial logging exists (provider-side key usage) but omits the critical fields needed to reconstruct the event — actor identity at the client, which extension read the credential store, and what egress it performed. An investigation cannot establish which installed component took the key. | The brief has to recommend adding detections for 'extension processes opening Cursor credential storage, unknown extensions making outbound requests, provider keys used from new locations', which indicates the client emits no such record. Conversely its response guidance — 'review provider logs for recent use' — confirms provider-side usage logging exists, but that record cannot attribute use to an extension, device or actor on the client.source: brief |
| Privacy (Pr) — scenario interval 0.09–0.74 (midpoint 0.41), Tier 3 MVT 0.50 indeterminate | |||
| Pr-3Data Minimization Compliance | 0.25w 0.35 | 0.25 anchor: some minimisation exists in that the store is scoped to the local user profile, but the client retains long-lived, high-sensitivity credential material — beyond what a short-lived, audience-bound credential would require — in local state, with no documented lifetime bound or teardown at logout or uninstall. | Long-lived provider API keys and session tokens are retained in a readable local database. The brief's remediation is to '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', which identifies both indefinite retention and the absence of cleanup on logout or uninstall.source: brief |
| Containment (Cn) — scenario interval 0.04–0.78 (midpoint 0.41), Tier 3 MVT 0.50 indeterminate | |||
| Cn-1Scope Enforcement | 0.00w 0.12 | 0.00 anchor: no effective scope boundary existed around extension code inside the assessed client — it could reach unauthorised local data (the credential store), the filesystem and the network without declaration or gating. This is scored against the extension host boundary specifically, which is the boundary the report assesses. | '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', and 'If a product treats all extensions as the same local trust boundary, enterprises need extension allowlisting and protected storage before using real keys.' The brief's mapped control states the required baseline that is missing: a machine-readable permission manifest plus a runtime interceptor blocking undeclared file reads, protected credential paths, outbound network destinations, shell use and privileged IDE APIs.source: researcher |
| Cn-5Agent Identity Integrity | 0.25w 0.14 | 0.25 anchor: identity rests on long-lived shared-secret API keys with no binding to workload, workspace or route, so possession is identity and a copied key is indistinguishable from the legitimate client; rotation is manual and after-the-fact, and client-side auditability of key use is absent. Not 0.00 — provider endpoints do authenticate the caller. | The credentials at risk are long-lived provider API keys and Cursor session tokens, and 'stolen keys enable impersonation, paid API abuse, and prompt or completion exposure'. The brief's mapped identity control prescribes what is absent: 'a distinct workspace or service identity, short-lived audience-bound credentials, and explicit route binding instead of a shared organization-wide API key.'source: brief |
Unknown, not N/A: 19 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.20 | Human-on-the-loop. Cursor's assistant executes routine editing work within the workspace while the developer monitors and can override or revert, and the platform additionally allows installed extension code to run automatically with no per-action approval once admitted — the property the attack turns on. Not higher: the evidence documents no consequential external action authority, and no action-authority matrix or agent auto-run configuration is in the evidence reviewed, so this is scored from what the brief describes rather than from Cursor's full feature surface. |
| AsAttack Surface Exposure | 0.75w 0.25 | Internet-facing client with external ingestion of partially trusted material: third-party extension code drawn from a public distribution channel executes inside the trust boundary, and the client maintains outbound connectivity to provider APIs and arbitrary destinations. Not 1.00 — the assessed configuration evidences no MCP tool integration, no external-agent communication and no untrusted retrieval corpus. |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph is published, so the worst-case default applies — and the reconstruction independently triggers the 1.00 anchor. The observed path is ungated end to end (no permission manifest, no egress restriction) and terminates in credential material that grants external, billable, irreversible effect: OpenAI, Anthropic, Google and cloud keys reaching an attacker-controlled destination, plus a Cursor session token. That is an ungated path reaching credential-bearing external authority, the P3/P4 condition, with the blast radius explicitly leaving the assessed product.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.25w 0.25 | Model-adjacent fix, days of work and no model change: relocate secrets to an OS keychain or encrypted store, shorten credential lifetimes, add per-extension permission manifests with runtime enforcement, and apply default-deny egress from the extension host; enterprises can mitigate immediately with extension allowlisting and by keeping real provider keys off secret-bearing workstations. Not 0.00 — the per-extension permission model is a product-architecture change rather than a single deterministic patch, and the evidence reviewed documents no shipped vendor fix, so this is a judgement about the class of remediation, not a claim about Cursor's roadmap. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.25 | Minimal provenance in the evidence available. The vendor, the product, the exact credential store (state.vscdb), the credential classes it holds and the access path are documented by the researcher — but there is no AIBOM, no extension inventory with publisher/version/hash, no model or tool lineage, and no identity-policy artefact for any specific installation. The brief in fact prescribes building that inventory as a first response, which confirms it does not exist by default. |
| Ec — Public evaluation coverage | 0.17 | coverage 0.17 (4 of 23 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.44 | Evidence dated 2026-04-28; age 107 days on the workpaper reference date. Components: T_containment 0.44 · C_monitor 0.65 · T_calendar 0.67 · C_evidence 0.85. Binding term: T_containment. dt_days = 107, measured from LayerX's primary disclosure dated 2026-04-28 to the 2026-08-13 evidence reference date; the AIDEFEND brief republished the analysis on 2026-05-03. agentic = true: the extension host admits new capability at runtime, so the effective permission boundary of the client is mutable between assessments — exactly the condition the containment staleness floor (M_Cn = 2.0) exists for — and no boundary re-attestation is evidenced. baw = false: none of the four Behavioral Attestation Window checklist items is evidenced for the assessed path — no cross-session memory written by the model or an agent, no live agent-to-agent channel, no self-modifying prompt or configuration, and no closed feedback loop; the mutability here is of permissions, not of behavioural state, and is already carried by the containment floor. C_monitor = 0.65: no client-side telemetry covers credential-store reads or extension egress — the brief has to prescribe those detections from scratch, and a successful theft would be invisible until provider-side spend or usage anomalies surfaced. No C_event cap is applied: the evidence documents a researcher-demonstrated design weakness, not an enumerated change, compromise or behavioural event against the assessed configuration, and asserting one would overstate what happened. C_evidence = 0.85: open identity and tool gaps remain unresolved — long-lived provider keys in readable local storage and no per-extension permission model, with no documented vendor fix. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.26 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-018.007 | Skill-Level Permission Manifest Validation & Runtime EnforcementParent AID-H-018 'Tool Authorization & Capability Scoping' (dataVersion 2026.08.05). The directly missing control and the principal Cn-1 evidence source: a per-extension manifest plus a runtime interceptor blocking undeclared reads of protected credential paths and undeclared egress. Cn-6 is in the lookup but no action-classification trace exists in this case, so Cn-6 was not scored. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-M-001.003 | Agentic Skill & Instruction Asset InventoryParent AID-M-001 'AI Asset Inventory & Mapping' (dataVersion 2026.08.05). Source, publisher, version, hash, owner, approval state, permission scope and usage for every installed extension — the artefact whose absence holds Provenance Completeness at the minimal anchor. | High | Cn-5 Fa-3 Tr-4 |
| AID-I-007 | Client-Side AI Execution IsolationParent AID-I-007 maps directly to Cn-1 and Cn-4 in the reconciled AIDEFEND dataVersion 2026.08.05 crosswalk. In substance it is the containment control for this case — keeping untrusted extension code away from secrets, workspace state and privileged IDE APIs — and it informed the Cn-1 reading as a mapped evidence source. | High | Cn-1 Cn-4 |
| AID-I-001.004 | Sandbox Network Egress RestrictionsParent AID-I-001 'AI Execution Sandboxing & Runtime Isolation' (dataVersion 2026.08.05). Default-deny egress with narrow allowlists would break the final exfiltration step even after a successful read. Pr-2 is the lookup's mapping; the evidence here speaks to egress containment rather than to inference attacks, so Pr-2 was not scored. | High | Cn-7 Pr-2 |
| AID-H-004.002 | Service & API AuthenticationParent AID-H-004 'Identity, Access & Trusted Communication for AI Systems' (dataVersion 2026.08.05). Short-lived, audience-bound, route-bound workspace credentials in place of a shared long-lived key — the gap behind Cn-5 = 0.25. | High | Cn-5 Tr-3 |
| AID-E-001.001 | Root & Long-Lived Credential Object EvictionParent AID-E-001 'Compromised Credential, Session, Principal & Grant Eviction' (dataVersion 2026.08.05). Response-side revocation and rotation of the exact provider and cloud key objects at their issuers; the brief notes Cursor sessions and IDE grants need the separate sub-techniques. | High | Cn-5 |
| AID-DV-002 | Honey Data, Decoy Artifacts & Canary Tokens for AINo AID-DV-* parent appears in the reconciled AITBM lookup at dataVersion 2026.08.05 (the Deceive tactic is unmapped), so no sub-metric is asserted. Operationally, a canary key would be the cheapest compensating detection for the C_monitor gap recorded in ACI. | Medium | Pr-1 |
| AID-D-005.007 | Token, Tool-Use, Request-Parameter & Cost Spike Detection & AlertingParent AID-D-005 'AI Activity Logging, Monitoring & Threat Hunting' (dataVersion 2026.08.05). Per-key monitoring for cost spikes, unusual parameters and new geographies is the provider-side detection that partially exists and underpins Tr-3 = 0.25. | Medium | Cn-7 Tr-3 |
WHAT THIS CASE TEACHES
Containment can score 0.00 on an AI product whose model behaved perfectly: the assessed boundary here is the extension host and the credential store, so a client-side trust-boundary failure lands squarely on Cn-1 and Cn-5 — and demonstrates that a 'no model involvement' incident is still an AI security finding, not an exemption from scoring.
Sources: AIDEFEND in Action brief — CursorJacking: Rogue Cursor Extensions Can Steal AI API Keys (published 2026-05-03) · Primary source — Roy Paz, LayerX: CursorJacking: Every Cursor User Is Vulnerable to API Key Theft by Rogue Extensions (2026-04-28)