🔍AI RiskAtlas
← Real-world cases
Case study

Malicious JetBrains Marketplace plugins steal AI API keys

Real-world incident16 Jun 2026🗺️ Model / Package Supply Chain

Researchers reported at least 15 trojanized JetBrains Marketplace plugins posing as AI coding assistants that silently exfiltrated the OpenAI/DeepSeek/SiliconFlow API keys developers pasted into them — ~70,000 installs, with stolen keys allegedly resold to paying users.

Root cause — why it happened

Developers installed plugins from the JetBrains Marketplace that advertised themselves as AI coding helpers built on tools like DeepSeek and OpenAI. The plugins worked exactly as promised — but they were also booby-trapped. When a developer pasted in their AI provider key so the plugin could call the AI, the plugin quietly copied that key to a stranger's server. The danger wasn't a poisoned AI model; it was that a tool the IDE trusted was handed a real secret and abused that trust, with no warning shown to the user.

Risks this case illustrates

Named in the standard (OWASP/ATLAS/NIST) lens. Click a highlighted component in the diagram below to see which risks attach where.

How it unfolded

Untrusted supply chainYour infrastructureuploads artefact🌐Publisher(maybe🏪Model / PackageRegistry🧬Downloadedmodel / package🏗️Your build /serving stack🧠Your deployedmodel🧑‍⚖️Developer(pastes API🌐Attackerkey-collection
InstructionsDataActionsControl / decisionFeedback / logs
👆 Click a component to inspect its risks
SetupStep 1 / 7

An attacker publishes a working AI plugin to the Marketplace

Someone uploads a plugin to the JetBrains Marketplace that looks like a genuinely useful AI coding assistant — chat, commit-message generation, code review. It is published under an ordinary-looking vendor account, and it really does work.

⚙️Marketplace listing (as advertised)config
Name:      DeepSeek AI Assist
Vendor:    <one of seven publisher accounts>
Features:  AI chat · commit-message gen · code review · bug finding · unit tests
Built on:  DeepSeek / OpenAI / SiliconFlow
Installs:  ~27,727   (CodeGPT AI Assistant: ~25,571; ~70k across the set)
# Works exactly as advertised. The malicious fragment is buried in working code.
Step 1 / 7

Controls & guardrails — what would have stopped it

The cleanest fix is to never hand a long-lived secret to a third-party plugin at all — log in to the AI provider through a proper sign-in flow that gives the plugin a short-lived, revocable token instead of your master key. Failing that, two things would have caught it: vetting plugins like real software before installing (not trusting the listing), and watching the developer machine so a coding tool sending a key to an unrelated server raises an alarm. And if a key did leak, rotating it immediately is what actually shuts the attacker out.

Preventive
Detective
  • Runtime monitoring & anomaly detection

    Detects the anomalous, not the novel-but-subtle; high false-positive rates cause alert fatigue. Always a step behind a sufficiently quiet attacker.

  • Full-trace audit logging

    Logging is forensic, not preventive — it explains harm after the fact. Useless if no one reviews it or if the materialised context isn't captured.

Corrective
  • Governance: risk assessment, red-teaming & incident response

    Process reduces likelihood and speeds recovery but executes no technical control itself; weak follow-through makes it theatre.

Lessons

  • Marketplace presence and a working feature set are not provenance — a fully-functional AI plugin can hide a small credential-stealing fragment that survives manual review.
  • The most valuable thing an AI dev tool can steal is often the developer's own provider API key — voluntarily pasted in, long-lived, and immediately monetisable via reuse/resale (LLMjacking).
  • Third-party IDE plugins run with the developer's privileges and open network egress; an egress boundary (allowlist + credential DLP) on the dev environment is the practical chokepoint for exfiltration.
  • Keep secrets out of plugin custody: brokered, short-lived, per-tool tokens (OAuth) mean a future trojan has no long-lived key to exfiltrate in the first place.
  • Once a long-lived key has left the machine, only rotation neutralises it — treat any secret entered into an affected plugin as compromised, and audit provider billing for unexpected usage.

Proposals & gaps this case surfaced

Non-destructive suggestions for the library — proposed, not adopted.

✚ proposed guardrailKeep provider credentials out of third-party plugin/tool custody: broker short-lived, per-tool, revocable tokens (OAuth) instead of long-lived pasted API keys, and require explicit user consent before any secret leaves the hostAgent Access & Tool Control

Third-party developer tools (IDE plugins, MCP servers) must not store or transmit long-lived provider API keys. Issue short-lived, scoped, revocable tokens via a broker/OAuth flow, and gate any first-time outbound transmission of secret-shaped data behind an explicit consent prompt — so a trojanized tool has no long-lived credential to exfiltrate and any attempt is visible.

This case shows a gap: we usually worry about poisoned AI models or tools that trick the AI. Here the trick was on the human — a trusted tool simply collected the secret the developer typed in, with no warning. We should treat 'a tool handles your credential' as its own risk, with rules about how plugins are allowed to hold and send secrets.

These surface as proposals across the Control Library and Risk Taxonomy; adopt them by hand when ready.

AI RiskAtlas is an educational model of how GenAI & agentic systems work and fail. Architectures and payloads are illustrative and simplified for learning — not operational guidance. Real-world cases are summarised from public reporting.

Sources & further reading →·Built by Shi Yuan ↗