Notifications
Clear all
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.
NHIMG editorial — based on content published by LayerX Security: Cursor extension access control flaw exposes AI developer keys
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
- 28% of secrets incidents now originate outside code repositories in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
Questions worth separating out
Q: What breaks when a development tool stores API keys outside protected storage?
A: The security boundary breaks first.
Q: Why do local extension ecosystems increase NHI risk for AI developer tools?
A: Because extensions often run with broad access to the host application’s files, data stores, and network paths.
Q: How can security teams judge whether developer secret storage is actually safe?
A: They should test whether untrusted add-ons can directly read credential stores, whether secrets are encrypted at rest, and whether access is mediated by a system vault or equivalent boundary.
Practitioner guidance
- Map every AI developer tool that stores credentials locally Inventory which tools hold API keys, session tokens, and cached secrets on the endpoint, then classify those stores as high-value identity assets rather than application data.
- Separate extension code from secret custody Require protected storage for secrets, such as OS-backed credential managers or an encrypted secrets layer, and block direct database access from extension runtimes.
- Reduce the blast radius of developer API keys Replace broad, reusable bearer credentials with tightly scoped tokens, short lifetimes, and service-specific access where possible.
What's in the full article
LayerX Security's full research covers the operational detail this post intentionally leaves for the source:
- The proof-of-concept extension flow that demonstrates how local database access becomes credential theft.
- The exact storage path and database handling details that explain why the control boundary failed.
- The disclosure timeline and vendor response context for teams tracking remediation decisions.
- The downstream abuse examples for OpenAI, Anthropic, and Google credentials after exfiltration.
👉 Read LayerX Security's analysis of Cursor extension credential exposure →
Cursor extension secrets exposure: what IAM teams should know?
Explore further
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
