Malicious JetBrains Marketplace plugins steal AI API keys from developers

Malicious JetBrains Marketplace Plugins Steal AI API Keys: What Developers Must Know

Earlier this year, security researchers exposed a disturbing supply chain attack: at least 15 malicious plugins on the JetBrains Marketplace were covertly siphoning AI API keys from developer workstations. The discovery, reported by BleepingComputer, sent shockwaves through the developer community because the JetBrains ecosystem is widely trusted for its robust plugin architecture and rigorous review process. If plugins from an official marketplace can steal credentials, no development environment is safe. This article breaks down how the attack worked, why it succeeded, and what you can do to protect your keys today. The incident serves as a stark warning: every developer who relies on JetBrains tools must now treat marketplace plugins as potential threats rather than assumed safe extensions. These malicious actors exploited the trust developers place in the platform, demonstrating that supply chain compromises can target even the most reputable sources. Understanding the mechanics of this attack is the first step toward defending your own API credentials and development pipeline.

How the Malicious Plugins Operated Under the Radar

Sophisticated Trojans Masquerading as Legitimate Tools

The malicious plugins weren't crude malware; they were sophisticated trojans designed to blend in with legitimate tools. According to the investigation, many of them masqueraded as productivity boosters, code formatters, or AI assistants themselves. For example, one plugin named "AICodeHelper" promised to integrate ChatGPT directly into IntelliJ IDEA. But after installation it would scan the file system for . env files, ~/. bashrc, and configuration files for OpenAI, Anthropic, and Google Cloud API keys. The attackers deliberately chose targets that developers commonly use to store API credentials, increasing the likelihood of finding valuable keys. This targeted approach made the attack especially effective against unsuspecting users of the JetBrains Marketplace.

Stealthy Exfiltration Techniques

Once a key was found, the plugin would encode it and send it to a remote server using HTTP POST requests disguised as telemetry data. The attackers even used domain fronting and TLS encryption to evade network-based detection. Some plugins waited several days after installation before beginning exfiltration, making it harder to correlate the infection with the breach. The plugins also avoided accessing common credential stores like macOS Keychain or Windows Credential Manager, presumably to reduce the likelihood of triggering Security alerts. This patience and precision are hallmarks of a well-orchestrated supply chain compromise rather than a scatter-shot malware campaign. The malicious actors clearly understood how to steal keys without raising suspicion.

Deep Knowledge of the JetBrains Platform

This level of careful engineering indicates that the threat actors had deep knowledge of both the JetBrains plugin API and developer workflows. They likely tested their plugins against multiple IDE versions and operating systems. The fact that they remained undetected on the Marketplace for an extended period suggests that JetBrains' automated and manual review processes were insufficient to catch these signs. The attackers clearly understood the trust developers place in the JetBrains Marketplace, making this a textbook supply chain compromise. The entire incident underscores how malicious actors can weaponize developer trust for credential theft. BleepingComputer's full report provides additional technical context on the attack's sophistication.

The Specific Vulnerability: Unrestricted File System Access

JetBrains Plugin Permissions Model

JetBrains plugins run with the same permissions as the IDE process itself, which typically has access to the entire user file system. While JetBrains does enforce some sandboxing through the Plugin Development Kit (PDK), the default security model trusts the plugin developer. Plugins can declare permissions in plugin xml via the and tags. But a plugin that requests broad access is rarely blocked unless it explicitly violates marketplace policies. This permissive model is what allowed the malicious plugins to steal keys without raising immediate red flags. The JetBrains Marketplace relies heavily on developer trust rather than granular permissions enforcement.

How Attackers Exploited Trust

In this case, the malicious plugins requested permissions that appeared normal for their stated functionality. A code formatter might need com intellij, and modulesplatform and file system access. But but an AI assistant plugin would naturally need network access to call API endpoints. Attackers exploited this by adding exfiltration code that wasn't visible in the plugin's description or source code review. Since plugins can be distributed as precompiled JAR files without public source code, JetBrains' review team couldn't easily audit the binary. This lack of transparency is a systemic weakness across many plugin ecosystems, not just JetBrains Marketplace. For developers, the lesson is clear: binary-only plugins should be treated with extreme caution.

The Broader Security Gap

The incident highlights a broader issue in plugin security: file system access control is binary (allowed or denied), not granular. A plugin either can read all files or none. Until IDEs adopt more granular permission models - similar to mobile operating systems - developers must rely on manual security reviews and third-party tooling to verify plugin behavior. This is a systemic risk that extends beyond JetBrains. The entire developer tooling industry needs to address this gap before the next wave of supply chain attacks emerges. The OWASP Supply Chain Security Tools project offers resources for auditing such vulnerabilities.

A Real-World Example: How API Keys Were Exfiltrated

Hypothetical But Representative: GPTBooster

Consider the hypothetical (but representative) plugin "GPTBooster". Which claimed to improve prompts for better AI responses. After installation, it would monitor files matching patterns like openai, anthropic, gcloud, \. env, and it used Java's Fileswalk API to traverse the home directory BufferedReader to read file contents. The plugin would then strip surrounding whitespace and base64-encode the key before sending it to https://api gptbooster, and tech/collectThis pattern is representative of how the 15 malicious plugins actually operated in the wild. The goal was to steal AI API keys from unsuspecting developers worldwide.

Network Evasion Tactics

The network request included a fake User-Agent: JetBrains-IDE/2024. 1 to blend with legitimate telemetry. The response from the server would be an empty 200 OK, so no logs were generated. Attackers could then replay the stolen API keys from their own systems, racking up usage costs or extracting data from the AI provider's services. Since many organizations don't set spending limits or monitor API usage closely, the theft could go unnoticed for weeks or even months. This quiet exfiltration is what makes these malicious plugins so dangerous for developers and their organizations. The BleepingComputer coverage emphasized how easily such attacks can evade detection when security practices are lax.

Not a JetBrains-Only Problem

This pattern isn't unique to JetBrains; similar attacks have occurred in VS Code extensions and npm packages. But the JetBrains Marketplace's reputation for quality made the breach particularly jarring. Developers who once felt safe now face the question: how many other malicious plugins remain undetected? The JetBrains official security update outlines the actions taken so far, including enhanced automated scanning and a commitment to improved permission verification.

Immediate Steps to Protect Your Development Environment

Audit Installed Plugins Now

If you're a JetBrains IDE user, take these actions today. First, audit all installed plugins. Navigate to Settings → Plugins and review the list. Remove any plugin you don't recognize or no longer use. Pay special attention to plugins that request network permissions or file system access without a clear need. JetBrains provides a list of verified plugins with a "JetBrains" badge. But even that isn't foolproof. Treat every plugin as a potential vector for malicious activity until proven otherwise. The Marketplace remains a target for attackers seeking to steal keys.

Store API Keys in a secret Manager

Second, store API keys in a dedicated secrets manager like Hashicorp Vault, AWS Secrets Manager. Or 1Password CLI. Never put keys in . env files inside your home directory or project root. Use environment variables set at the OS level or within your shell profile. But understand that those can still be read by processes with matching permissions. For maximum security, inject secrets at runtime using your CI/CD pipeline or container orchestration layer. This reduces the attack surface for any plugin attempting to steal keys. Many developers overlook this simple step, making them easy targets.

Enable Usage Alerts and Monitoring

Third, set up API key usage alerts and spending limits with each AI provider. OpenAI, Anthropic, and Google Cloud all offer alerts for unusual activity. If a stolen key is used from an unexpected IP address or region, you'll get notified quickly. Integrate these alerts into your incident response system. Check your provider's documentation for configuring cost thresholds. Monitoring alone won't prevent theft. But it dramatically reduces the window of undetected misuse by malicious actors. The BleepingComputer report recommended all developers add such monitoring to catch abuse early.

Long-Term Solutions: Sandboxing and Code Signing

IDE-Level Sandboxing

JetBrains has announced improvements to its plugin review process, including automated binary analysis and stricter permission declarations. However, the fundamental problem of trusting third-party code remains. A more solid solution would be operating system-level sandboxing for developer tools. For example, macOS's App Sandbox can restrict file system access. But JetBrains IDEs aren't sandboxed by default. Users can run their IDE inside a Docker container or a virtual machine, but that adds complexity to development workflows. The balance between security and usability is difficult but essential. The JetBrains Marketplace needs to evolve its security model to prevent future malicious plugins.

Mandatory Code Signing and Reproducible Builds

Another approach is mandatory code signing with reproducible builds. If JetBrains required plugins to be built from source in an auditable environment, attackers would find it harder to insert backdoors. The Electron ecosystem has faced similar challenges; many VS Code extensions now must use the @typescript-eslint suite for type-checking. But binary scanning is still reactive. Exploring how other package managers handle supply chain security can help inform best practices, and the OpenSSF Scorecard offers guidelines for open source projects that could be adapted for IDE plugins. This would make it significantly harder for malicious code to hide.

Demand Open-Source Transparency

Open-source transparency is also critical. Developers should demand that plugins they rely on have public source code repositories. While open-source doesn't guarantee security, it allows community audits. The malicious plugins in this attack had no public source,, and which should have been a red flagJetBrains could incentivize plugin authors to publish their source code by offering faster reviews or better visibility in search results. This kind of transparency would make it significantly harder for malicious plugins to hide their true intentions. For developers, choosing open-source plugins is a proactive defense against supply chain attacks that aim to steal keys.

Lessons for the Entire Developer Ecosystem

Trust Must Be Earned Continuously

This attack isn't just about JetBrains - it's about the general trust we place in plugin marketplaces. From npm to VS Code to GitHub Actions, the same pattern repeats: a curated marketplace with limited security review, and developers who install tools without thinking twice. The cost of a compromised development environment can be catastrophic: stolen credentials, intellectual property theft. And even backdoored software shipped to customers. Every developer must now treat plugin installation as a security decision, not just a convenience action. The malicious plugins on the JetBrains Marketplace are a wake-up call for the entire industry.

Shift from Convenience to Verification

Developers must shift from a culture of convenience to a culture of verification. Before installing any plugin, ask: "Does this tool need network access? Why does it need file system read permissions, and and can I find the source code" If the answers are unsatisfactory, find an alternative. Open-source tools like Lighthouse for VS Code or JetBrains Plugin Verifier can help analyze plugin behavior. But they aren't widely adopted. The OWASP supply chain tools can help teams audit their dependencies more thoroughly. This proactive approach reduces the risk that malicious code will steal your keys.

Organizational Policy Is Essential

Furthermore, organizations should enforce a software supply chain policy for development tools. Just as you scan npm dependencies for vulnerabilities with Snyk or Dependabot, you should scan IDE plugin binaries. Tools like JFrog Xray and Snyk Container can be extended to inspect plugin JARs. Though it's not trivial. The security community needs to develop standardized plugin analysis tools that every team can plug into their CI pipeline. Until then, manual review and cautious installation remain the best defenses against malicious