Supply chain malware in npm and PyPI is targeting Kubernetes teams

At a glance

What this is: This is a supply chain attack analysis showing how a malicious npm and PyPI package can plant a persistent tunnel on Kubernetes developer and CI/CD systems.

Why it matters: It matters because cluster access, cloud tokens, and service account credentials often live on the same machines, so one compromised developer environment can become an NHI and infrastructure compromise path.

By the numbers:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.
• 17 minutes

👉 Read Panther's analysis of the kube-health-tools supply chain attack

Context

Supply chain malware in package ecosystems works because developers and build systems treat popular tooling as routine infrastructure. In Kubernetes environments, that trust boundary is especially fragile because developer workstations and CI/CD runners often hold kubeconfigs, cloud tokens, and service account credentials that can reach far beyond the host itself.

The primary security issue here is not just malicious code in npm or PyPI. It is the way a single compromised package can convert software installation into credential exposure, cluster access, and persistent network access. That makes this a Kubernetes supply chain problem with a clear NHI governance intersection, because the attack targets service accounts, tokens, and other machine credentials already trusted by the environment.

Key questions

Q: What breaks when malicious packages can run on developer machines with cluster access?

A: The boundary between software installation and privileged access breaks first. If a package can execute on a workstation that already holds kubeconfigs or cloud tokens, the attacker inherits trusted access paths rather than needing a separate exploit. That turns ordinary dependency installation into a cluster compromise path, especially when credentials are long-lived and broadly scoped.

Q: Why do Kubernetes environments make supply chain attacks more dangerous?

A: Kubernetes environments often concentrate privileged identities on developer and CI/CD machines. Those hosts may hold service account tokens, cloud provider credentials, and kubeconfigs that can reach multiple clusters. Once malware runs there, the attacker can pivot from a single endpoint into orchestration, secrets, and infrastructure control planes.

Q: How do security teams know if cluster credentials are usable outside their intended boundary?

A: Look for credentials that work from developer endpoints, build runners, or shared automation hosts without additional context checks. If a token can reach cluster APIs, cloud control planes, or internal services from a generic workstation, it is operating outside a safe boundary. That is a governance signal, not just an access issue.

Q: Who should own response when supply chain malware reaches Kubernetes credentials?

A: Accountability should sit jointly with platform security, IAM, and the team that owns the build or developer environment. The response should include host rebuild, credential rotation, scope reduction, and review of which identities were reachable from the compromised machine. If the identity inventory is unclear, containment will be slower than the attacker’s access window.

Technical breakdown

How malicious packages turn install time into execution time

Package-based supply chain attacks abuse the moment when developers or CI jobs install dependencies. A loader script can execute automatically on import or require, before defenders have a chance to inspect behaviour. In this case, the package disguised itself as Kubernetes health tooling, then launched a dropper that wrote and executed a second-stage payload. The key technical point is that package metadata, file layout, and install hooks can all be engineered to look normal while the actual payload is delayed or nested. That makes static review alone unreliable when trust is anchored to ecosystem reputation rather than runtime behaviour.

Practical implication: treat package installation as an execution event and monitor it with the same controls used for script and binary launch.

Why reverse tunnels and proxy capability matter in Kubernetes

A reverse tunnel creates outbound connectivity from the victim back to attacker-controlled infrastructure, which is harder to block than inbound command channels. Here the stage-two payload established a TLS tunnel with SOCKS5 and SSH capability, giving the operator a flexible way to move laterally inside networks where the infected host already had reach. In Kubernetes and CI/CD environments, that reach is often amplified by mounted tokens, kubeconfigs, and cloud credentials. Once the tunnel exists, the attacker does not need to stay on the original host. They can pivot into cluster APIs, internal services, and cloud control planes using the trust already granted to the compromised machine.

Practical implication: baseline outbound tunnel behaviour on developer and build systems and restrict egress from environments that hold cluster credentials.

What makes the anti-forensics layer technically effective

The campaign was designed to disappear quickly. The shell script and downloaded binary were deleted after execution, the PyPI variant rewrote itself into a benign stub, and the tunnel process used a disguised name to blend into normal activity. It also reused an AES-GCM nonce across configuration blobs, which is an operational weakness for the attacker but not a defensive control by itself. The real lesson is that file presence is a weak indicator when malware is built to self-delete and persist in memory or through encrypted configuration. Detection must therefore focus on process lineage, outbound connections, and credential access from build and developer hosts.

Practical implication: collect process, network, and credential telemetry from build systems before relying on disk artefacts for confirmation.

Threat narrative

Attacker objective: The attacker wants persistent remote access into Kubernetes and CI/CD environments so they can harvest credentials, pivot into clusters, and expand into connected cloud and internal systems.

1. Entry occurs when a developer or CI/CD pipeline installs the malicious kube-health-tools package from npm or PyPI.
2. Credential access follows when the infected workstation or build system exposes kubeconfigs, cloud tokens, and mounted service account credentials to the attacker’s reverse tunnel.
3. Escalation and lateral movement occur when the operator uses that access to enumerate Kubernetes secrets, pivot into cluster APIs, and reach adjacent cloud and internal services.
4. Impact is full cluster and environment compromise, with persistent remote access and potential theft of files, secrets, and infrastructure credentials.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Supply chain compromise is now an identity problem as much as a code problem. This campaign does not stop at package installation. It targets the credentials, tokens, and service account material that live on developer and CI/CD machines, which means the security boundary has shifted from dependency trust to machine identity trust. In practice, that makes NHI governance a necessary part of software supply chain defence, not a separate discipline.

Cluster access on developer endpoints creates a standing blast radius that defenders routinely underestimate. When a workstation can reach kubectl, cloud APIs, and internal services, compromise of that host becomes a privileged identity event rather than a local endpoint issue. The governance failure is not just poor hygiene. It is the assumption that developer machines are low-value when they may actually hold the keys to the cluster.

Persistent tunnel malware exposes a control gap we can call package-to-cluster privilege collapse. Once attacker code can move from a package install into a reverse proxy and then into cluster credentials, the environment has no meaningful separation between software supply chain risk and infrastructure privilege. This is where least privilege, workload identity scoping, and runtime egress control need to be evaluated together, because isolated control ownership leaves the gap intact.

Self-deleting malware makes forensic confidence more fragile than most response plans assume. The faster the attacker removes artefacts, the more defenders must rely on behaviour-based evidence and credential lifecycle controls. That puts pressure on IAM and NHI teams to shorten credential lifetime, narrow token scope, and verify where privileged identities are actually usable before the evidence disappears.

Package ecosystem attacks against Kubernetes environments will continue to target the weakest identity layer, not the fanciest exploit. The most practical route to impact is still the path where a build agent or developer machine can authenticate broadly and persistently. Practitioner priority should therefore shift toward eliminating standing access on systems that can reach clusters, not just scanning more packages.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Forward view: AI systems learning from codebases are a concern for 43% of security professionals, according to The State of Secrets in AppSec, which raises the stakes for package screening and secret hygiene in build pipelines.

What this signals

Package-to-cluster privilege collapse is the operational risk this campaign sharpens. Once a developer workstation or build runner can authenticate into Kubernetes, the compromise path no longer depends on stealing a separate production secret. It depends on how much standing access was already available on the host, which is why OWASP Non-Human Identity Top 10 style governance matters for endpoints as well as services.

The most immediate programme shift is toward shorter-lived and narrower machine credentials on systems that can execute third-party code. If build hosts still carry reusable tokens, then package compromise becomes credential compromise by design. That should drive tighter token scoping, endpoint segmentation, and more explicit ownership of NHI lifecycle controls.

From a detection perspective, this kind of attack argues for more telemetry on process creation, outbound tunnels, and secret access from development infrastructure. Defender visibility must cover both identity use and network behaviour, because the attacker’s objective is to convert a single package install into a reachable control path.

For practitioners

• Audit cluster-facing credentials on developer and CI/CD systems Inventory kubeconfigs, service account tokens, cloud provider credentials, and SSH material stored on endpoints and build runners that can reach Kubernetes. Remove any identity that can authenticate broadly from machines that also execute third-party code.
• Constrain package installation on high-trust systems Separate dependency install hosts from systems that hold privileged cluster access, and block direct internet package installs where practical. Apply behavioural monitoring to install-time execution, not just malware scanning of source archives.
• Tighten egress from build and developer networks Detect and restrict reverse tunnels, SOCKS proxies, and unexpected long-lived TLS sessions from environments that should only talk to approved repositories, registries, and cluster endpoints.
• Shorten the lifetime and scope of cluster credentials Rotate service account tokens and cloud credentials that are accessible from developer workstations, and reduce their permissions to the smallest set needed for the task. This limits the blast radius when a package install becomes a host compromise.

Key takeaways

• This campaign shows that malicious packages can convert developer trust into Kubernetes compromise by abusing the identities already present on the host.
• The strongest evidence of scale is not the package count alone, but the combination of persistent tunnel access, credential reach, and rapid anti-forensic cleanup.
• Teams should respond by reducing standing credential exposure on build and developer systems, because package scanning alone will not stop identity abuse once execution begins.

Key terms

• Package-to-cluster privilege collapse: A failure mode where code installation on a developer or build host turns into privileged Kubernetes access because that host already holds usable credentials. The risk is not the package alone. It is the overlap between third-party execution, standing identities, and reach into cluster and cloud control planes.
• Reverse tunnel implant: Malware that creates an outbound encrypted connection from the victim to attacker infrastructure, often with proxy or shell access built in. It is effective because egress is easier to permit than inbound access, and because the tunnel can hide behind legitimate-looking TLS traffic while preserving long-lived control.
• Standing Credential Exposure Window: A standing credential exposure window is the period during which a long-lived secret remains usable after it has been created, exposed, or forgotten. The longer that window stays open, the more likely an attacker can reuse the credential for access, lateral movement, or persistence before the organisation notices.
• Self-deleting malware: Malware engineered to remove its own files, overwrite traces, or delete supporting artifacts after execution. This reduces forensic visibility and shifts defender reliance toward telemetry from process behaviour, network connections, and credential use rather than disk-based indicators alone.

What's in the full report

Panther's full blog covers the operational detail this post intentionally leaves for the source:

• Indicator details for the malicious npm and PyPI packages, including hashes, filenames, and registry versions.
• Stage-by-stage malware analysis of the dropper, tunnel client, and self-deleting behaviour observed in the campaign.
• Concrete detection artefacts such as process names, C2 indicators, and file system paths from the investigation.
• Timeline and actor tracking information that supports incident response and hunting work.

👉 Panther's full post covers the attack chain, malware mechanics, and investigation artefacts.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It is designed for practitioners who need to connect identity controls to real-world attack paths across modern infrastructure.