Signed, Reviewed, Verified — and Still Malicious
For years, the security advice for installing developer tooling has quietly converged on a short checklist. Is it on the official marketplace? Is the vendor verified? Is the package signed? Does it have good reviews and a healthy download count? Tick those boxes and you can install with reasonable confidence.
The campaign JetBrains disclosed on 17 June 2026 ticked every one of them.
Fifteen plugins, published under seven vendor accounts, sat in the official JetBrains Marketplace and were installed close to 70,000 times. Aikido Security, which uncovered the campaign, found that all fifteen shared near-identical code, repackaged and renamed across listings. They posed as AI coding assistants built on DeepSeek, OpenAI, and SiliconFlow, offering chat, commit-message generation, code review, bug finding, and unit-test scaffolding. They appeared to do those jobs well enough to pass as legitimate developer tools. And the moment a developer pasted an AI provider API key into a plugin’s settings and clicked Apply, the plugin serialised that key and sent it to a hard-coded server at 39.107.60[.]51 over unencrypted HTTP.
That is the whole story, and the part worth sitting with is not the sophistication of the malware. It’s the primitiveness of what worked. Every visible signal a developer is trained to notice was present and correct — marketplace distribution, vendor identity, a signature, reviews, ratings, a five-figure download count — and the decisive behaviour was about as crude as network attacks get: a raw IP address and plaintext HTTP. The attack didn’t defeat those trust signals. It exploited the gap between what they actually prove and what we’ve come to believe they prove.
One clarification before the argument, because it shapes the argument: JetBrains was not breached. The company says it verified that no internal source code, development environments, or core infrastructure were touched. This was malicious third-party code living inside the store, not a compromise of the store itself — which is exactly what makes it instructive. The platform’s checks did what they were built to do. The attack walked through them anyway, because catching this was never what they were built for.
It helps to be clear about why AI keys, specifically, are such attractive loot. An AI provider API key is not just a password. It is a spend-bearing credential. A stolen one generates immediate, real cost on someone else’s bill; it can expose proprietary prompts and internal workflows; and it typically sits outside the mature controls — rotation, scoping, IP allowlisting, anomaly detection — that organisations have spent a decade wrapping around cloud IAM keys. A developer’s IDE is where those keys get pasted, and the IDE, as JetBrains itself notes, runs unsandboxed with full user privileges. That combination — high-value secret, low-maturity controls, privileged host — is precisely what a supply-chain campaign wants.
The reassurance stack
Pull the trust signals apart one at a time and the same pattern shows up in each.
The official marketplace and manual review. JetBrains reviews new plugins and updates before they go live. It did here. But review of this kind is built to catch policy violations and broken APIs, not to trace data flows through every code path. JetBrains is unusually candid about this in its own post-mortem. It says the Plugin Verifier was built as a “compatibility and API-usage checker” — not a malware or data-flow scanner — and because the APIs the plugins called looked normal in isolation, the hard-coded endpoint and the custom TLS handling slipped through ingestion. The malicious logic didn’t hide in an exotic corner. It sat in an ordinary settings path — the function that runs when a user saves configuration — a location that reads as routine unless review includes behavioural inspection of how a plugin handles credentials and where it sends them.
The Verified Vendor badge. This is the signal most people misread, and JetBrains now spells out the limit itself: the badge confirms a publisher is a real, identified legal entity. It is explicitly not a guarantee of a plugin’s safety or code quality. It is an identity check. A verified vendor can ship malware as easily as an anonymous one — they’re just easier to name afterwards.
Code signing. A signature guarantees the package you download is the package the publisher built, unaltered in transit. It is tamper-evidence, and a good one. It is not a malware scan. A signed malicious plugin is still signed, and still malicious. The signature tells you the poison arrived exactly as the poisoner mixed it.
Reviews and ratings. The Marketplace does not verify the authenticity of reviews. Ratings are a social signal, and social signals are the easiest thing in the world to manufacture — they measure perceived legitimacy, which is the precise quantity an attacker wants to inflate.
Download counts. Close to 70,000 sounds like reach, and it is. But both Aikido and BleepingComputer — which downloaded the latest DeepSeek AI Assist build and independently confirmed the theft code was still present — cautioned that the counts can be inflated, and are not a verified tally of victims. A big number builds trust. It doesn’t earn it.
Lay them side by side and the throughline is unmistakable. Every one of these is a statement about identity, integrity, or reputation. Not one is a statement about behaviour — about what the code does once it’s running on your machine. Manual review is the only control that arguably failed in the ordinary sense: a human looked and missed it. But the deeper point survives even a perfect review, because review, signing, verification, ratings, and downloads were all validating the wrong property. They were never going to catch a plugin that does exactly what it claims, plus one thing more.
At a glance, the gap between what each signal certifies and what developers read into it:
| Trust signal | What it actually certifies | What developers assume it means |
|---|---|---|
| Official Marketplace listing | The plugin cleared automated and manual review | ”Someone checked that this is safe” |
| Verified Vendor badge | The publisher is a real, identifiable legal entity | ”A trustworthy party stands behind this” |
| Code signature | The package wasn’t altered between build and download | ”The code itself has been vetted” |
| Ratings & reviews | Users left feedback — authenticity unverified | ”The community confirms it’s good” |
| Download count | Installs were recorded — figure can be inflated | ”This many people use it safely” |
It wasn’t just theft. It was a business.
Here is where the story stops being a familiar smash-and-grab. The attacker’s server was not only a drop point. According to Aikido — and independently echoed by BleepingComputer and others — the plugins ran a paid tier: after a user paid a small fee through a donation wall, the server sent an API key back down to the client, and the plugin began using that key for its model calls instead of the user’s own. Read that sequence twice. One group of victims unknowingly supplies credentials; another group, paying customers, consumes them. Aikido’s framing is blunt — the operators earn from one set of users while quietly draining credentials from another, and the people who actually own the keys are the ones left paying for the usage.
It’s worth being exact about how much of this is established, because the difference between observation and inference is where careful reporting lives:
| Confidence | Claim |
|---|---|
| Observed | The plugins exfiltrate the API key a developer enters into settings |
| Observed | The server can send a key back to the plugin, which then uses it instead of the user’s own |
| Inferred | The operators pool keys stolen from free users and hand them to paying users |
| Unproven | The precise commercial model — pricing, scale, and who ultimately profits |
The business model is the inferred rung, not the confessed one. But the mechanism on the rung above it — a server engineered to hand keys back to clients — tells you something the download numbers can’t. You don’t build a key-return endpoint for a hit-and-run. You build it for infrastructure.
Why this keeps happening
The reason none of the marketplace’s controls caught the campaign is, in the end, that none of them was built to. JetBrains documents the relevant fact plainly: plugins run with the same rights as the IDE itself. They can read and modify any file the user can. They can reach the network without an extra prompt. They are not sandboxed. So the store’s job was never to confine dangerous code to a sandbox — there is no sandbox. Its controls are about accountability and integrity, and establishing the behavioural safety of arbitrary code running with full user privileges is a genuinely hard problem the store does not fully solve. Few do.
And this campaign was not lazy about staying hidden. JetBrains found that the plugins silently installed a JVM-wide X509TrustManager to suppress TLS warnings, specifically so local networks and IDE debuggers wouldn’t flag the anomalous outbound connection. The plaintext HTTP wasn’t carelessness; the exfiltration was engineered to look like nothing.
The most pointed detail in the whole affair is that JetBrains had, in effect, already warned against the exact pattern the campaign relied on. In the same period, its platform team published a post bluntly titled “Stop Pasting Tokens: OAuth2 Login for JetBrains IDE Plugins”, urging plugin authors to stop asking users to paste long-lived secrets into settings fields and to use a browser-based OAuth2 flow with secure storage instead. The single design choice this entire campaign depended on — paste your secret here — was already on JetBrains’ own list of patterns to retire.
To its credit, JetBrains’ response points the right way. Alongside purging the plugins, permanently terminating the seven publisher accounts, and triggering a remote kill-switch that disables the extensions on each affected IDE’s next relaunch, the company says it is adding ingestion rules to flag raw-IP and non-HTTPS endpoints, unauthorised TLS weakening, and code that handles inputs resembling cloud API keys — and it is steering developers toward the sandbox-minded Agent Client Protocol for AI integrations rather than bespoke unsandboxed plugins. That is the marketplace starting to inspect behaviour rather than just identity and integrity, which is the correct direction and also a quiet admission of where the gap was.
What it actually means
There’s a comfortable way to read this incident and a useful one. The comfortable reading is that rare malware slipped through, was caught, and was removed — a bad week, now resolved. The useful reading is harder: an official plugin marketplace is, functionally, a lightly governed distribution channel for code that runs with full developer-machine privileges, and the badges that make it feel curated are overwhelmingly about who published the code and whether it arrived intact — not whether it’s safe to run. That feeling of curation is doing more reassurance work than the underlying controls can support.
For an individual developer, the takeaway is a reframe: treat a plugin as a dependency that runs with your privileges — because that is what it is — not as a harmless editor preference. For an organisation, it’s that the install decision can’t sit entirely with individual discretion. Plugin allowlisting, per-user and tightly scoped keys, enforced spending caps, and provider-side usage monitoring stop being nice-to-haves the moment a single pasted secret can be silently resold to strangers.
And if you or your team installed any of the fifteen plugins before 17 June 2026, the practical part is short and not optional. Rotate every AI key you ever entered into one of them, and treat those keys as compromised whether or not you’ve seen misuse. Check your provider’s usage and billing dashboards for anomalies. Block outbound traffic to 39.107.60[.]51 at the firewall, and hunt your network logs for connections to it. JetBrains’ advisory carries the full remediation steps and the complete list of affected plugin IDs; the kill-switch handles the plugin, but only you can handle the key.
The fifteen plugins were signed. They were reviewed. They were published by verified vendors with good ratings and tens of thousands of downloads. They were also malicious the entire time. The lesson isn’t that those signals are worthless — it’s that we’ve spent years reading them as promises they were never making.
Sources
- Aikido Security — Multiple JetBrains IDE plugins caught stealing AI keys (primary technical analysis)
- JetBrains — Marketplace Ecosystem Security Update: Addressing Malicious Third-Party AI Plugins (official advisory and remediation)
- BleepingComputer — Malicious JetBrains Marketplace plugins steal AI API keys from developers (independent verification)
- JetBrains — Stop Pasting Tokens: OAuth2 Login for JetBrains IDE Plugins
- Additional corroboration: The Hacker News · Infosecurity Magazine