The developer never saw the malware. Their agent picked it

AIR Research Lab has written up a case it calls SolanaCry, and it's a clean example of something I think we'll see a lot more of. The attacker didn't need to fool a developer. They needed to fool the developer's AI agent.

The setup

The flow AIR describes goes like this. A developer asks their coding agent to build a Solana project. The agent decides to search the web for a starter kit. It picks a GitHub repository called solana-starter-kit, published under an account named SolanaUpdateTools. The README tells it to run a command. The command installs a remote access tool controlled by the attacker.

The repo looked fine at a glance. It had 286 stars and described itself as an open-source Solana dApp template with an Anchor program, a TypeScript client and a Next.js UI. AIR says it ranked as the top result when an agent searched for a Solana starter kit.

What the command actually did

The README's only installation step was a PowerShell one-liner. It built a URL out of small variables, downloaded a script with iwr and ran it in memory with iex. Nothing touched disk at that stage.

The payload was offline by the time AIR checked, so they recovered it from the Web Archive. It was a roughly 21 MB PowerShell dropper carrying 14 files. Thirteen were genuine, signed NetSupport Manager components. NetSupport is legitimate commercial remote support software. The fourteenth was the attacker's own config file, pointing the client at the operator's server, hiding the user interface, removing the disconnect option and accepting connections from anywhere.

The dropper then added a Run key so the client starts at every login, launched it, cleared the Run history and deleted itself.

Nothing new, except the target

This is the part I find most useful. None of the malware is new. AIR matched a secret in the config file to a NetSupport cluster that eSentire already tracks in ClickFix campaigns. The install one-liner follows the same pattern, down to the variable names, as a campaign Fortian documented in October 2025 that lured traders with fake TradingView "AI signal" videos.

So the same operator ran the same playbook against traders, then developers, and now the agents working for developers. Only the path to the victim changed.

Why it matters

When a developer picks a repo and runs the install step, there's at least a chance they'll notice something odd. When the agent searches, chooses the repo, reads the README and runs the command, that human check has quietly disappeared. The developer may never look at the repository at all.

Search ranking and a few hundred stars were enough to get chosen. The attacker didn't have to compromise a real project.

What I'd change

• Treat everything an agent reads as untrusted input. That includes search results, READMEs and docs.
• Don't let agents run commands that download and execute remote code, like iwr | iex or curl | sh, without a person reviewing them.
• Don't auto-approve installs from sources nobody has checked.
• If you think a Windows machine is affected, AIR lists the signs: a hidden folder named y2inwRnI6G under %LOCALAPPDATA%, a SecureModule Run value, or client32.exe running from that folder.

The agent was doing its job. The job just needs a guard rail where the human used to be.