Topic starter
10/06/2026 12:02 am
TL;DR: A local SQLite database in Cursor stores API keys and session tokens that any extension can read, creating a high-severity credential exposure path with no user interaction after install, according to LayerX Security. The issue shows that local trust boundaries and protected storage assumptions still matter for AI development tooling, especially where third-party integrations carry broad access.
Editorial analysis by NHI Mgmt Group, based on content published by LayerX Security: “CursorJacking: Every Cursor User Is Vulnerable to API Key Theft by Rogue Extensions”.
Key questions
Q: What breaks when AI developer tools store API keys where extensions can read them?
A: The main failure is that local extension code can bypass the intended trust boundary and read secrets as plain application data.
Q: Why do compromised developer tools create outsized risk for application secrets and API keys?
A: Compromised developer tools sit close to the systems that issue, store, or deploy secrets.
Q: How can security teams tell whether a developer tool is mishandling secrets?
A: Look for credentials stored in local files, databases, or caches that any plugin or extension can access without a separate privilege check.
Practitioner guidance
- Isolate extension access from credential stores Keep API keys and session tokens out of storage that extensions can reach directly.
- Inventory developer-tool credentials by downstream service Map every AI and developer service reachable through Cursor-issued keys, including LLM providers and internal APIs.
- Reduce key scope before installing extensions Prefer narrowly scoped tokens for developer workflows and separate them from credentials that can reach production data or high-value automation.
Bottom line: AI developer tools can fail at the trust boundary itself when extensions are allowed to read local credential stores.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
10/06/2026 2:39 am
Protected local storage is the broken premise here: the platform assumed sensitive credentials would be separated from untrusted extension code, but the database design erased that boundary. Once API keys and session tokens are stored where any extension can read them, the control is no longer access control but hope. Practitioners should recognise this as a local trust-boundary failure in developer identity tooling, not merely a product bug.
A few things that frame the scale:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
- 64% of valid secrets leaked in 2022 are still valid and exploitable today, showing that detection without revocation leaves live NHI exposure in place.
A question worth separating out:
Q: Who is accountable when a tool vendor leaves credential exposure unpatched?
A: The vendor remains accountable for the software control failure, but the deploying organisation still owns the risk acceptance decision. Security teams should document the exposure, restrict affected tooling, and decide whether the business case justifies continued use while the flaw remains open. That is the point where governance meets operational tolerance.
👉 Read our full editorial: Cursor extension access control flaw exposes AI developer keys
12/06/2026 3:13 am
Extension-readable secret stores create trust boundaries that extension ecosystems cannot safely assume away: When a local application stores API keys and session tokens in a database that any extension can read, the extension model itself becomes the control failure. The issue is not merely insecure storage, but the absence of an enforceable separation between user intent and code execution inside the same client. Practitioners should treat extensibility as a privilege boundary, not a convenience feature.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: Should organisations keep AI service credentials inside extensible developer apps?
A: Only when the app can prove strong isolation between extensions and secret material. If an extension can read the same database that holds API keys or tokens, the safer choice is to move those credentials into protected storage or a brokered secret flow. Otherwise the local client becomes part of the attack surface.
👉 Read our full editorial: Cursor extension access control flaw exposes AI developer keys
This post was modified 1 day ago by NHI Mgmt Group