A high-severity access control vulnerability (CVSS 8.2) in Cursor AI that allows any installed extension to silently extract developers’ API keys and session tokens from an unprotected local SQLite database, with no user interaction required after installation. No fix has been issued to date.
LayerX Security disclosed on April 27, 2026, that Cursor, one of the most widely adopted AI-powered development environments, stores sensitive credentials, including OpenAI, Anthropic, and Google API keys, as well as Cursor session tokens, in a plaintext-accessible local SQLite database located at ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb.
Unlike industry-standard security practices that mandate the use of OS-level protected storage such as macOS Keychain or Windows Credential Manager, Cursor enforces no access control boundary between installed extensions and this database.
This means every Cursor user who has installed any third-party extension is potentially exposed to credential theft without performing a single suspicious action.
The Attack Chain: Step by Step
The exploitation path is straightforward and requires minimal attacker sophistication:
- Extension creation – An attacker crafts a seemingly benign extension (a theme, productivity tool, or code formatter) that requests no suspicious permissions
- User installation – A developer installs the extension from a marketplace or GitHub repository with no warning, permission prompt, or visible risk indicator
- Database access – The extension directly opens and queries the local SQLite database, which holds session tokens, API keys, and authentication artifacts
- Credential extraction – Because data is stored in plaintext or with insufficient protection, parsing is trivial
- Silent exfiltration – A simple
fetch()call transmits credentials to an attacker-controlled server with no UI change, alert, or user interaction - Post-exploitation – The attacker holds valid credentials for full account takeover and downstream abuse
LayerX published a working proof-of-concept extension on GitHub to demonstrate how easily this attack can be weaponized. This attack pattern aligns with broader concerns around malicious IDE extensions; a real-world $500,000 crypto heist was previously traced to a malicious “Solidity Language” extension distributed through the Cursor marketplace.
The official CVSS v4.0 score of 8.2 reflects a particularly dangerous threat profile:
- No permissions required – the extension needs zero declared access to credentials
- No user interaction – exploitation begins the moment the extension is installed
- Low attack complexity – no race conditions, chaining, or privilege escalation required
- High confidentiality impact – full credential exposure across local and dependent cloud services
- Scope change – downstream services (OpenAI, Anthropic, Google) are also compromised
This vulnerability does not exist in isolation. Cursor has faced a string of security disclosures in recent months, including a persistent RCE vulnerability via MCP trust bypass uncovered by Check Point Research and a prompt-injection-driven code-execution flaw reported by Oasis Security. Cursor’s cumulative security posture is increasingly under scrutiny within the security community.
Downstream Financial and Data Risk
If an attacker successfully exfiltrates a developer’s OpenAI API key via this vulnerability, the consequences extend well beyond Cursor itself:
- Financial fraud – API calls billed to the victim’s account with no usage cap in some configurations
- Data exposure – access to prompts, completions, and interaction metadata from prior sessions
- API abuse – leveraging stolen keys for spam, automation, or further attacks
- Inference attacks – reconstructing sensitive business logic or proprietary code from cached interactions
Because AI API keys often carry broad, unrestricted access scopes, a single stolen key can cascade into a significant breach across the developer’s entire toolchain and organization.
LayerX reported the vulnerability to Cursor on February 1, 2026. Cursor responded on February 5, 2026, acknowledging the issue but characterizing it as within the user’s responsibility to manage their trust boundary, framing the risk as equivalent to that of any local application with filesystem access.
As of April 28, 2026, the vulnerability remains unpatched, and no CVE identifier has been formally assigned to this specific issue. The Cursor community forum has independently raised related concerns, with users requesting at-rest database encryption with SQLCipher and process-level access restrictions.
Mitigations
Until Cursor issues an official patch, developers should take the following precautions:
- Audit all installed extensions, remove any extension not sourced from a verified, trusted publisher
- Rotate API keys immediately if you suspect any unverified extension was ever installed
- Use scoped, budget-limited API keys with usage alerts set on OpenAI, Anthropic, and Google dashboards
- Avoid storing high-privilege keys in Cursor until credential isolation is enforced
- Monitor API usage anomalies via provider dashboards for unauthorized calls
LayerX recommends that Cursor enforce strict extension-to-storage isolation and migrate all credential storage to system-level OS keychains. The Cursor Hardening Guide, published on April 27, 2026, also recommends turning off unnecessary extensions and reviewing MCP server trust configurations as interim hardening steps.
FAQ
Q1: Is this vulnerability actively being exploited in the wild?
No confirmed in-the-wild exploitation has been reported, but a working PoC extension is publicly available on GitHub.
Q2: Does this affect all operating systems where Cursor runs?
Yes, the unprotected SQLite database path exists across macOS, Windows, and Linux installations of Cursor.
Q3: Will simply uninstalling suspicious extensions remove the risk?
Uninstalling reduces future risk, but credentials already exfiltrated before removal remain compromised and must be rotated.
Q4: Has Cursor been assigned a CVE for this specific credential-access flaw?
No CVE has been formally assigned to this access control issue as of April 28, 2026.
Site: https://thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.
About the Author
