AI’s Open Secret: Why Your Cursor Extensions Can Silently Siphon Your API Keys

In the fast-moving world of AI-assisted development, a significant security oversight has been uncovered in Cursor, a popular AI-powered code editor. A new report from LayerX security researchers reveals that the IDE currently stores sensitive credentials, including session tokens and API keys, in an unprotected local database—leaving them wide open to theft by any installed extension.

The vulnerability, which carries a high-severity CVSS score of 8.2, highlights a critical “trust boundary” issue within the editor’s architecture.

Unlike most modern applications that leverage secure, encrypted storage layers—such as the macOS Keychain or Windows Credential Manager—Cursor stores its sensitive secrets in a standard, local SQLite database. This database, found at ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb, contains the sensitive information of a developer’s AI environment.

The LayerX team discovered that Cursor does not enforce access control between the editor and its ecosystem of extensions. As a result: “any Cursor extension can access the developer’s API keys and session tokens, leading to full credential compromise, with no need for user interaction or activity at all”.

The researchers demonstrated how a “rogue” extension could silently exfiltrate these keys without the developer ever knowing. Once a malicious extension is installed, it can:

• Locate the local SQLite database on the disk.
• Query the database to extract API keys and session tokens.
• Exfiltrate the stolen data to an attacker-controlled server via a simple background fetch.

“This happens silently,” the researchers noted, with “no user interaction required,” “no visible UI changes,” and “no alerts”.

Perhaps most concerning for the developer community is the vendor’s response to the disclosure. According to LayerX, Cursor acknowledged the findings but suggested that the current behavior is by design: “Cursor replied that they recognize the issue, but that it’s the user’s responsibility to define their trust boundary”.

As of April 28, 2026, the issue remains unfixed. This stance places the burden of security entirely on the developer, who must now vet every single extension for potential credential-stealing behavior before adding it to their workflow.