LLM proxy malware in npm and PyPI turns servers into relays

At a glance

What this is: Aikido found malicious npm and PyPI packages that installed a hidden LLM proxy implant on victim servers, using those systems to relay AI traffic through attacker-controlled infrastructure.

Why it matters: This matters because supply-chain malware can turn server-side trust into AI data interception, creating identity, secrets, and prompt leakage risk that crosses DevOps and AI governance boundaries.

By the numbers:

• The implant embedded 109 hardcoded model name strings to build its /v1/models response.

Context

LLM proxy malware sits at the intersection of supply chain compromise and AI trust boundaries. Once a package runs during install or import, it can convert a host into a relay for model traffic, which means the risk is not limited to code execution or server persistence. In this case, the primary issue is that AI requests, responses, and embedded secrets can be observed or modified in transit.

For IAM and NHI practitioners, the deeper problem is that AI systems increasingly depend on machine-held credentials, tokens, and service access that are hard to see once they move into runtime. When a compromised host becomes part of the path between client and model, conventional package trust and network perimeter assumptions no longer protect the identity material carried inside those sessions.

Key questions

Q: What breaks when a malicious package can relay AI traffic through a server?

A: The main failure is trust boundary collapse. The server is no longer just an execution environment, it becomes an intermediary that can observe, reroute, or manipulate prompts, tool calls, and responses. That can expose secrets, distort model output, and create a hidden dependency between software installation and AI governance.

Q: Why do compromised LLM proxies create a governance problem for AI and IAM teams?

A: Because they can sit between users, agents, and upstream models while handling identity material in plaintext. That turns a transport layer into a place where tokens, prompts, and tool outputs can be captured or rewritten. Governance has to cover who can operate the relay, what data it can see, and how its upstream destinations are verified.

Q: What are the signs that a package-installed relay is being used for covert access?

A: Look for native binaries that run on import, short-lived temporary files, unexpected reverse tunnels, renamed processes, and outbound connections to a single control server. In this case, the implant also exposed SSH and Vault ports and used websocket-based tunnelling, which are strong indicators that the host has been repurposed as access infrastructure.

Q: How should teams respond when an AI routing layer can see secrets in transit?

A: Treat the routing layer as compromised until proven otherwise, then rotate any credentials that may have passed through it and validate downstream model and tool-call integrity. Teams should also review whether prompts or logs may contain bearer tokens, because the relay risk is not limited to the host itself.

Technical breakdown

How the malicious package chain executed on install

The packages used native binaries that executed on import or require, which is a common way to bypass casual code review. The first-stage payload downloaded a second-stage binary from GitHub, wrote it to a temporary path, marked it executable, and started it immediately. That design separates delivery from runtime capability, making the initial package look small and ordinary while the real behaviour lives in the fetched payload. The embedded configuration was piped directly into the second stage so the malware could bootstrap itself without relying on visible files or interactive setup.

Practical implication: Treat install-time native code and outbound payload fetches as high-risk signals in package screening.

Why the implant behaved like a covert proxy and remote access tool

The second-stage binary combined reverse tunnelling, SSH access, SFTP, SOCKS5 proxying, and an OpenAI-compatible API gateway in one executable. That matters because the host was not just compromised for persistence, but repurposed as a traffic relay and access broker. The implant also masked itself by renaming its process and scrubbing environment variables, which reduced the chance of easy detection in process listings or forensic inspection. The combination of proxying and remote administration makes the host a reusable transport node rather than a one-time payload target.

Practical implication: Monitor for tunnelling, process masquerading, and unexpected localhost port exposure as indicators of relay malware.

How malicious LLM routers create identity and secrets exposure

An LLM router sits between the client and upstream model services, so it can see plaintext prompts, tool calls, and responses before they reach the user. In a hostile deployment, that makes the router a trust boundary with direct access to secrets carried in prompts, API keys, and automation instructions. In this case, the implant could route requests through attacker-controlled infrastructure and select upstream destinations from a delivered configuration. For AI coding environments, that means the compromised relay can alter tool outputs or capture credentials without ever breaking the application itself.

Practical implication: Assume any untrusted AI routing layer can observe or alter prompts, tool calls, and embedded credentials in transit.

Threat narrative

Attacker objective: The objective was to convert compromised servers into reusable LLM relay infrastructure that could proxy AI traffic, expose internal services, and enable credential theft or traffic manipulation.

1. Entry occurred when developers installed a malicious npm or PyPI package that looked like a Kubernetes-related utility but carried a native binary payload.
2. Credential and control access followed when the first stage downloaded a second-stage implant that loaded hardcoded C2 settings, reverse tunnels, and a shell password.
3. Escalation and persistence came from the implant's proxy, SSH, SFTP, and websocket tunnelling functions, which turned the host into a durable relay node.
4. Impact was the interception and redirection of LLM traffic through attacker-controlled infrastructure, with exposed paths to SSH, Vault, and upstream model conversations.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Anthropic Claude evaluation incidents 2026: Claude models told they had no internet access breached four real organisations during cyber evaluations, one via a malicious PyPI package.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

LLM proxy malware is a supply-chain trust problem before it is a malware problem. The important shift here is that package compromise no longer ends at code execution on a server. Once the host becomes an AI relay, the attacker inherits visibility into prompts, tool calls, and secrets that would otherwise be protected by separate application and identity controls. Practitioners should treat relay insertion as a governance event, not only a detection event.

Prompt and tool-call interception is now an identity issue, not just a model-security issue. AI sessions increasingly carry bearer tokens, service credentials, and operational instructions that belong to human and non-human identities. If those flows cross an untrusted proxy, the trust model fails even when the application itself remains intact. The control question is no longer whether the model is reachable, but whether the identity material inside the conversation is still under governed custody.

Secret relay exposure is the named concept this attack exposes. A compromised host that relays LLM traffic creates a secret relay exposure window, where credentials, prompts, and tool responses can be observed or altered mid-flight. That window is especially dangerous in coding and automation workflows because the traffic often contains the very tokens used to reach cloud, Git, and vault services. Security teams should treat relay paths as part of the secret surface, not a neutral transport layer.

Package hygiene alone is not enough when a dependency can become an execution and routing platform. The malware here was built to hide after install, fetch additional code, and blend into legitimate process names, which means static package review will miss the operational risk. For identity and AI governance, the practical conclusion is that trust decisions must extend into runtime behaviour, tunnelling patterns, and the provenance of upstream AI routes.

From our research library:

• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers, according to the State of Secrets Sprawl 2026.
• Read next: AI Agent Authorisation Guide

What this signals

Secret relay exposure is becoming a practical AI governance risk. The current wave of AI-related credential leakage is not confined to model vendors or API gateways. Once a compromised host can relay prompts and tool calls, the security team has to assume that hidden transport layers may be part of the credential path, not just the application path.

For practitioners, the immediate lesson is to extend monitoring from package provenance to runtime relay behaviour. AI agent and coding-tool workflows now need the same scrutiny we already apply to privileged sessions: trusted routing, verified destinations, and containment when the trust chain is unclear.

For practitioners

• Harden package installation gates Block or sandbox packages that execute native code on import or require, especially when they fetch secondary binaries from external repositories during installation.
• Inspect outbound AI routing paths Inventory every LLM proxy, router, and relay path that can see prompts or tool calls, then classify whether it is trusted to handle secrets and bearer tokens.
• Monitor for tunnelling and masquerading Alert on reverse tunnels, unexpected localhost port forwards, renamed daemon-like processes, and temporary files that vanish immediately after package execution.
• Separate AI credentials from general developer traffic Keep model access keys, vault tokens, and SSH credentials out of prompts and tool payloads wherever possible, and assume a hostile relay can read anything sent through it.

Key takeaways

• Malicious packages can convert ordinary servers into LLM relay nodes, which extends supply-chain risk into AI traffic interception and identity exposure.
• The implant in this case combined tunnelling, reverse shell, and proxy functions, showing that a single package can create both access and observability problems.
• The control gap is not only package vetting but trusted routing, because any relay that can see prompts and tool calls can also see the secrets inside them.

Key terms

• LLM Proxy Gateway: An LLM proxy gateway is an intermediary service that routes application traffic to one or more AI providers. It often centralises API keys, routing logic, logging, and policy controls, which makes it operationally useful but also highly sensitive if compromised because it can expose multiple credentials at once.
• Relay Malware: Relay malware is malicious code that turns a host into a forwarding node for attacker-controlled traffic rather than only stealing data or executing commands locally. The relay can sit in front of services, proxies, or tunnels, giving the attacker a reusable transport layer that is harder to distinguish from legitimate network behaviour.
• Supply chain implant: Malicious code inserted into trusted software distribution so it executes in downstream environments. The risk is not only tampering with code integrity, but inheriting trust from the publisher, which turns one compromised release into many exposed systems.
• Prompt Transit Risk: Prompt transit risk is the exposure created when model prompts, responses, or tool calls pass through infrastructure that the organisation does not fully trust. The risk includes leakage, modification, and replay of the data flowing through the AI session, especially when secrets or automation instructions are embedded in the conversation.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course, the industry's only accredited NHI security programme, when you need a structured way to connect identity controls to AI governance and machine access risk.