How 15 fake AI plugins turned a developer's settings panel into a credential trap

The Context

JetBrains makes the integrated development environments (IDEs) that a large share of the world's professional software developers use daily. IntelliJ IDEA, PyCharm, and GoLand are the tools developers spend most of their working hours inside. JetBrains operates an official plugin marketplace where third-party developers can publish extensions that add features to these IDEs. As AI coding assistants became standard workflow tools in 2024 and 2025, the marketplace filled with plugins connecting IDEs to OpenAI, DeepSeek, SiliconFlow, and similar providers. Developers routinely install these plugins and paste in their AI provider API keys—long-lived credentials that authorize billing and usage against their accounts.

The Attack, Phase by Phase

Phase 1: Marketplace Infiltration and Social Proof Construction

Beginning in late October 2025, the attacker created seven vendor accounts on the JetBrains Marketplace under names designed to sound like legitimate developer tool companies: CodePilot, StackSmith, CodeCrafter, CodeWeaver, JetCode, DailyCode, and ZenCoder. From these accounts, they published an initial wave of plugins presenting as AI coding assistants.

The plugins passed JetBrains' review process because the malicious logic was compact and embedded inside otherwise standard settings-persistence code. A reviewer scanning for obvious red flags would see a routine method that saves user preferences. The attacker supplemented organic installs with inflated download counts and fake five-star reviews to manufacture social proof.

Phase 2: Credential Exfiltration via the Settings Trap

Every AI coding assistant plugin requires the same setup step: the user opens the settings panel and pastes in their AI provider API key. The malicious plugins handled it exactly as a legitimate plugin would, with one addition.

The moment a developer clicked "Apply," the plugin's save() method ran two operations at once. First, it stored the key locally. Second, it validated that the key started with sk- and was exactly 51 characters long, then immediately fired an HTTP POST request to 39.107.60.51, transmitting the key as a plaintext JSON payload. The request included a static authentication token (F48D2AA7CF341F782C1D) hardcoded into the plugin binary. The entire operation ran synchronously on the main thread—no background process, no delay, no visual indicator. The key was gone before the settings panel finished closing.

The plugins also silently installed a JVM-wide X509TrustManager that disabled standard warnings about suspicious encrypted connections, reducing the chance that a corporate network security tool would flag the outbound traffic.

Phase 3: Stolen-Compute Resale Operation

The campaign ran a parallel business on top of the theft. Each plugin offered a paid donation tier. Developers who paid a small fee received a working AI provider API key from the attacker's server, which the plugin used on their behalf instead of prompting them to enter their own.

Aikido Security assessed that the keys distributed to paying customers were the keys stolen from free-tier victims. The attacker collected fees from one group of developers while a separate group of genuine key owners unknowingly funded the compute costs. The attacker built a complete commercial operation—a product, a pricing tier, a customer base—on top of stolen credentials.

Phase 4: Discovery, Kill-Switch, and Ongoing Exposure

On June 16, 2026, Aikido Security researcher Ilyas Makari publicly disclosed the campaign. JetBrains responded the same day: all 15 plugins were removed, all 7 publisher accounts were permanently banned, and a remote kill-switch disabled the plugins inside users' IDEs on the next relaunch.

The problem did not end there. StepSecurity confirmed on June 19 that the attacker's C2 server at 39.107.60.51 was still live and actively responding to requests. Any developer who had not yet rotated their API keys remained at risk. JetBrains acknowledged that its Plugin Verifier was built for compatibility checking, not behavioral or data-flow analysis, and announced changes to its review process.

What Made This Possible

1. The Plugin Verifier was the wrong tool for this threat. JetBrains' review infrastructure checked that plugins use supported APIs correctly and don't break IDE compatibility. It was not designed to trace where user-entered data flows after it is saved. A single malicious method call inside a legitimate settings handler was invisible to that kind of review.

2. Functional legitimacy suppressed suspicion. The plugins did exactly what they advertised. A developer who used one for weeks would have no reason to suspect anything was wrong—the attack exploited the implicit assumption that a working tool is a safe tool.

3. Developers apply different scrutiny to IDE tools than to code dependencies. The same engineer who carefully audits a new package added to a dependency file will paste a long-lived AI provider secret into an unvetted IDE plugin without a second thought, because the plugin came from an "official" marketplace. The trust signal substituted for actual verification.

What Should Have Stopped This

No single control would have prevented this attack. The defenses that matter are ones that don't depend on the plugin's own behavior to be safe.

• API key scoping and short expiry. Most AI providers allow keys to be scoped to specific endpoints and set to expire. A key that can only call one model and expires in 30 days is far less valuable to steal than a long-lived, unrestricted one.
• Usage alerts and billing anomaly detection. Stolen keys are used immediately. An alert that fires when a key is used from an unexpected IP or when usage spikes above a threshold would surface the theft before the bill arrives.
• Network egress monitoring. The exfiltration used unencrypted HTTP to a single hardcoded IP. A network that logs outbound HTTP traffic would have flagged the request. The plugins also disabled TLS certificate warnings—itself an anomalous behavior that endpoint security tools can detect.
• Treating IDE plugins as dependencies. The same supply chain review applied to open-source packages should apply to IDE extensions. Publisher account age, review history, and source code availability are all signals worth checking before installation.

The Takeaway

This campaign is the same class of failure as the Stryker Intune wipe and the Axios supply chain attack: a trusted tool weaponized against the people it was built to serve. Here, the trusted surface was the IDE plugin marketplace, and the weapon was the settings panel every developer uses without a second thought.

The resale tier marks a shift. This was not a smash-and-grab. The attacker built a product, priced it, and ran it for eight months. AI API keys have become a commodity with a market, and the infrastructure to monetize stolen ones is already operational.

Pattern to remember: Any tool that prompts a user to enter a long-lived secret is a potential exfiltration point if the tool itself cannot be verified, regardless of where it was downloaded from.

What changed: AI provider credentials have crossed from access token to resalable commodity, meaning theft is no longer the end of the attack chain but the beginning of a separate revenue operation.

The Technical Mechanism

The malicious logic was embedded inside the standard settings persistence handler common to all 15 plugins. The save() method, which fires when a user clicks "Apply" in the plugin settings panel, was modified to perform two operations in sequence on the main JVM thread.

First, the method validated the entered API key against a format check: the key must begin with the string sk- and be exactly 51 characters in length. This validation targets the key format used by OpenAI's API and several compatible providers (SiliconFlow uses the same format). Keys that do not match this pattern are not exfiltrated, which suggests the attacker was specifically targeting OpenAI-compatible credentials rather than collecting all entered strings indiscriminately.

Second, if the key passed validation, the method called BaseUtil.request() to dispatch a synchronous HTTP POST to http://39.107.60.51/ with a JSON payload containing the key. The request included a static bearer token (F48D2AA7CF341F782C1D) hardcoded into the plugin binary, used to authenticate the incoming data on the attacker's server side. Because the request used plain HTTP rather than HTTPS, the payload was transmitted in cleartext and was interceptable by any device on the same network path, including corporate proxies, VPN exit nodes, and shared Wi-Fi infrastructure.

To suppress network-level detection, each plugin silently registered a permissive JVM-wide X509TrustManager implementation that accepted all TLS certificates without validation. This did not affect the exfiltration request itself (which used HTTP), but it reduced the likelihood that other outbound connections from the IDE would trigger certificate-validation alerts that might prompt investigation.

The paid resale tier operated through a donation wall embedded in the plugin UI. Upon payment confirmation, the attacker's server returned a working AI provider API key via the same C2 endpoint. The plugin stored this key and used it for subsequent AI requests, bypassing the need for the user to supply their own. Aikido Security's analysis concluded that the keys distributed through this tier were sourced from keys stolen from free-tier users, creating a closed-loop operation.

The attacker merged the malicious exfiltration call with the legitimate persistence logic inside the same method, a deliberate technique to reduce the surface area visible to code auditors. A reviewer examining the save() method would see a standard key-storage operation with an additional network call that could be misread as a telemetry or license-validation request.

CVE and Advisories

No CVE identifier has been assigned to this campaign as of the publication date. The attack does not exploit a vulnerability in JetBrains IDE software itself. It is a supply chain attack conducted through the plugin distribution channel. No Common Vulnerabilities and Exposures (CVE) entry applies.

The official vendor response is documented in the JetBrains Marketplace Ecosystem Security Update (June 17, 2026).

MITRE ATT&CK Mapping

Indicators of Compromise

Network Indicators

• C2 server IP: 39.107.60.51 (Alibaba Cloud, Beijing region). StepSecurity confirmed this server was live and responding as of June 19, 2026, three days after plugin removal.
• Outbound HTTP POST requests (port 80) from a JetBrains IDE process to 39.107.60.51 at the moment a user clicks "Apply" in an AI plugin settings panel.
• Static authentication token in HTTP POST body: F48D2AA7CF341F782C1D

Plugin Identifiers

The 15 plugins were published under seven vendor accounts: CodePilot, StackSmith, CodeCrafter, CodeWeaver, JetCode, DailyCode, and ZenCoder. The two highest-reported plugins by install count were:

• DeepSeek AI Assist (plugin ID: ord.cp.code.ai.kit), 27,727 reported downloads
• CodeGPT AI Assistant, 25,571 reported downloads

Detection Notes

Standard endpoint detection tools would not flag the exfiltration because it occurs inside a legitimate IDE process performing an expected network operation (calling an AI provider). Detection requires network-layer inspection of outbound HTTP (not HTTPS) traffic from IDE processes, or behavioral rules that flag JVM processes registering permissive X509TrustManager implementations at runtime.

Attribution

Unattributed. No threat intelligence firm or government agency has publicly attributed this campaign to a named threat actor or nation-state as of the publication date. The C2 server (39.107.60.51) is hosted on Alibaba Cloud infrastructure in Beijing, China. Infrastructure hosting location alone is not sufficient for attribution. The campaign's characteristics (eight-month duration, seven separate vendor accounts, fake reviews, fully functional plugin facades, and an operational monetized resale tier) indicate a financially motivated operator with significant operational patience. No public attribution statements have been issued by CrowdStrike, Palo Alto Unit 42, Google TAG, or Microsoft MSTIC specific to this campaign.

Primary Sources