Leaked OpenAI/inference key in Cursor config files
Updated
Cursor's `.cursor/` directory holds model preferences + custom rules + sometimes inline API keys when developers configure non-default providers. The April 2026 Bitwarden CLI malware specifically searched for this pattern alongside `.claude/`. Treat Cursor config files the same as you'd treat `.env` — never commit, never publish.
The next 60 seconds matter
Identical to the Anthropic / Claude pattern — automated scrapers find the dot-directory + key shape; LLMjacking pools resell or directly use the key. OpenAI keys with team-account scope can additionally exfiltrate Assistants API thread histories and any fine-tuned models attached to the account.
- Burn the key's spend budget on GPT-4o / GPT-5 inference until the spend cap trips ($1K-$50K typical)
- Pull Assistants API thread histories with attached files
- Exfiltrate fine-tuned model weights trained on your corpus
- Create new fine-tunes that poison your account's billing record
Rotation playbook
- Revoke the key at the provider's dashboard immediately (platform.openai.com → API keys; openrouter.ai → keys; together.ai → API)
- Rotate the key in every environment: Vercel, Railway, GitHub Actions, local .env, AND your `.cursor/` config
- Audit `.cursor/settings.json` + `.cursorrules` on every developer's machine; remove inline keys
- Add `.cursor/` to .gitignore + .npmignore
- Audit npm publish history + git history for `.cursor/` directory inclusion
Prevent the next one
- Cursor config should reference env vars, never inline keys (Cursor supports `${process.env.X}` syntax)
- Securie's secret_scanner + secrets-lifecycle specialists catch dot-directory inclusion in publish artifacts
- Set per-key spend caps on every paid AI API
- Route inference server-side only when possible; the Cursor agent shouldn't need direct keys at all
Pattern we scan for
sk-proj-... (OpenAI), sk-or-... (OpenRouter), sk-... (legacy OpenAI), or Together-... keys in `.cursor/settings.json` or `.cursorrules`