Malicious npm and PyPI packages turn dev servers into Chinese LLM proxies

Aikido Security reported on April 22 that two innocuous-looking packages, the PyPI kube-node-health and the npm kube-health-tools, contained a stage-2 Go binary running a fully functional, OpenAI-compatible LLM proxy. The proxy routes requests for 109 frontier models, including Claude, GPT, and Gemini, through Chinese aggregator endpoints. Every request, every response, and every API key passes through the operator’s machine in plaintext.

What we know

• The packages. Aikido names two: kube-node-health (PyPI) and kube-health-tools (npm). Both pose as Kubernetes node-health utilities. The malicious payload is in a native binary loaded at import time: __init___cpython-311-x86_64-linux-gnu.so for Python and addon.node for Node.
• The dropper. The first stage downloads a Go-based stage-2 binary that opens reverse tunnels to a command-and-control host at sync[.]geeker[.]indevs[.]in. The process disguises itself as node-health-check --mode=daemon.
• The proxy itself. The Go binary embeds a complete OpenAI-compatible router. Aikido’s analysis found 109 hardcoded model names spanning Anthropic, OpenAI, Google, ByteDance VolcEngine, and Alibaba. Upstream routes go to Chinese aggregators including shubiaobiao, cloudsway, volengine, and aliyun, not to the official provider APIs.
• What the operator gets. Aikido lays it out plainly: “silently exfiltrate secrets from request and response bodies, including API keys, AWS credentials, GitHub tokens, Ethereum private keys, and system prompts.” Worse, the proxy can rewrite responses on the way back to inject tool calls. A coding agent told to pip install requests may receive a response telling it to curl | bash something else first.
• Attribution. The pattern (open proxies on compromised servers, Chinese aggregator endpoints, packaging style) tracks the broader Chinese threat-actor playbook of using Western infra as relay nodes for traffic that the Great Firewall would otherwise block. The GitHub operator gibunxi4201 shows prior involvement with proxy-related projects.

What’s still unclear

• Install count. Aikido didn’t publish download stats for the two packages, and both have been pulled. Bleeding-edge supply-chain attacks rely on a small number of CI machines pulling fresh dependencies; whether this hit production or just sat dormant is what determines impact.
• Spread to other ecosystems. The same operator group has been linked to LiteLLM Python compromises earlier this year. Whether the same C2 endpoint shows up in other AI-tooling packages is the question security teams should be searching for right now.
• What other agents got rewritten. This is the new ugliness in supply-chain attacks aimed at AI dev workflows. Mid-flight response rewriting is a category we’ve barely started auditing for. If a Cursor or Claude Code session ran through a compromised host between mid-March and April 22, the audit trail for what tool calls actually executed is thin.

How to check

Aikido published file hashes and the C2 hostname. The fastest checks:

• Find the binaries. find / -name '__init___cpython-311-x86_64-linux-gnu.so' and find / -name 'addon.node' -path '*/kube-health-tools/*'. Match SHA256 against the four hashes in the Aikido write-up.
• Egress hunt. Block and alert on outbound to sync.geeker.indevs.in, plus the aggregator hostnames shubiaobiao, cloudsway, volengine, and aliyun.com from machines that shouldn’t be talking to them.
• Process audit. A node-health-check --mode=daemon process running on a machine that doesn’t run Kubernetes is the obvious tell.
• Rotate keys. Anything that touched a system with these packages installed: rotate API keys, AWS creds, GitHub tokens, and any wallet keys present in env. Don’t only revoke; rotate, because the operator may already be using them.

Who reported it first

Aikido published the write-up on April 22. The Hacker News covered the broader self-propagating worm pattern the same day. Snyk published a separate retrospective on LiteLLM that ties the same operator family back to compromised security scanners earlier in the spring.

What this means for you

If you ship code that touches LLM APIs, the threat surface just grew. Treat any locally-running OpenAI-compatible router as you’d treat a TLS-terminating proxy on your laptop. Check what’s bound to localhost:443 and localhost:11434. The malicious payload here was packaged as a Kubernetes utility, but the technique works for any package that can plausibly justify shipping a binary.

If you run CI, the Bitwarden CLI Shai-Hulud worm, the Trivy GitHub Actions hijack, and now GPT-Proxy share a common pattern: the attacker doesn’t need persistent access to your infrastructure if the package you npm install does it for them. Pin to commit hashes, not tags. Run installs in a sandbox that can’t reach the internet outside of a registry allowlist. Audit what binaries your dependencies bring along.

My read: the AI-dev-tools ecosystem has an attack surface most security teams haven’t budgeted for yet. Coding agents make autonomous tool calls; if a router in the middle can rewrite responses, “did the agent really do that” becomes a forensics question without a clean answer. Aikido’s write-up is the canary. Plan for the second.