LiteLLM 1.82.8 shows how supply chain malware steals NHI secrets

At a glance

What this is: This is an analysis of a compromised PyPI package that exfiltrated developer and workload secrets, then attempted Kubernetes persistence and lateral spread.

Why it matters: It matters because IAM, PAM, and NHI programmes still rely on secrets and trust assumptions that malware in the software supply chain can bypass without exploiting a traditional vulnerability.

By the numbers:

• LiteLLM sees roughly 97 million monthly PyPI downloads.

👉 Read Hush Security's analysis of the litellm supply chain compromise and secret theft

Context

Supply chain compromise becomes an identity problem the moment malicious code can read long-lived secrets from developer machines, CI runners, or workload environments. In this case, a PyPI package used the normal Python startup path to harvest cloud credentials, Kubernetes tokens, and SSH keys before attempting persistence.

The key governance failure is not just package trust. It is the assumption that possession of a file or token still maps cleanly to an authorised actor once untrusted code is executing on the same host or in the same process space.

Key questions

Q: What breaks when a malicious package can read secrets on developer machines?

A: File-based secrets stop acting like identities and become reusable data for any code running under the same user context. That means SSH keys, cloud credentials, and API tokens can be copied without defeating authentication. The practical failure is blast radius, because one infected host can expose multiple systems if the secrets are long-lived and widely distributed.

Q: Why do long-lived service account tokens increase supply chain risk?

A: Long-lived service account tokens give malicious code the same reach as legitimate workloads for far longer than necessary. If the token is stored on disk or mounted into a pod, the attacker can enumerate namespaces, read secrets, or schedule privileged workloads. Short-lived, scope-bound tokens reduce both theft value and reuse value.

Q: How can security teams reduce the impact of dependency-based secret theft?

A: They should remove static secrets from endpoints, issue runtime credentials only when needed, and monitor process-level access to secret paths and metadata endpoints. That combination shrinks what malware can steal and creates evidence when it tries. It also makes incident response narrower, because there is less reusable material to rotate.

Q: How should teams respond after a supply chain package exfiltrates credentials?

A: Treat every affected machine as compromised, rotate all exposed secrets, inspect for persistence, and review Kubernetes or cloud audit logs for follow-on activity. Then reassess whether those credentials needed to exist as reusable files at all. The real lesson is to redesign the access model so the next package has nothing valuable to steal.

Technical breakdown

How .pth files turn package install into code execution

Python processes .pth files automatically during interpreter startup, before application imports run. That makes a malicious .pth payload unusually effective because it executes on every interpreter launch, including child processes and transitive dependency paths. In the litellm case, this created silent execution without a CVE, import statement, or obvious package crash. The important architectural point is that package installation was used as a code execution primitive, not as a vulnerability exploit. Once that path exists, any process-level control that assumes benign startup behaviour is already too late to stop harvesting or exfiltration.

Practical implication: Treat package startup hooks as execution surfaces and inspect dependencies for automatic code paths, not just known CVEs.

Why static secrets fail under filesystem crawl attacks

The payload searched for secrets in predictable places such as ~/.aws/credentials, ~/.config/gcloud/, ~/.azure/, ~/.kube/config, .env files, shell history, and metadata endpoints. This works because many identity systems still materialise credentials as readable files or environment variables. Secrets do not validate the process that reads them, so malware running with the same user context can treat them as ordinary data. Vaulting helps reduce sprawl, but if the runtime still receives a reusable secret, the attack surface remains. The mechanism is simple: read, package, encrypt, exfiltrate.

Practical implication: Reduce reliance on file-based secrets and prefer short-lived, workload-bound credentials that are never written to disk.

How Kubernetes turns stolen tokens into cluster-wide impact

Once a service account token exists on the host, a malicious process can use the Kubernetes API to enumerate namespaces, list secrets, and attempt privileged pod creation. The attack described here tried to mount host filesystems and write a persistent backdoor through a scheduled pod, which is a classic privilege amplification path when tokens are over-scoped. The key failure is not Kubernetes itself. It is the presence of a broadly usable, long-lived service account token that can move from one namespace into the cluster control plane. That transforms a local compromise into a platform compromise.

Practical implication: Scope service account tokens to the narrowest API set possible and deny cluster-wide secret enumeration from workload identities.

Threat narrative

Attacker objective: Steal reusable credentials at scale, then use them to persist inside endpoints and expand into Kubernetes environments.

1. Entry occurred when the attacker published a malicious PyPI package that downstream projects installed as a transitive dependency.
2. Credential harvest followed as the package crawled local files, cloud credential locations, and metadata endpoints for SSH keys, API keys, and workload tokens.
3. Impact came from encrypted exfiltration, attempted Kubernetes secret enumeration, and persistence routines designed to survive on both developer machines and cluster nodes.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Static secrets are now a liability state, not a convenience state. This package only worked because cloud keys, Kubernetes configs, and API secrets still existed as readable artefacts on disk or in environment variables. That model assumes trusted code and trusted hosts, which supply chain malware directly disproves. The implication is structural: any programme that still treats possession of a file as proof of authorisation is carrying avoidable exposure.

Credential possession is not identity once untrusted code runs on the host. A malicious package does not need to break authentication when it can simply read what authentication systems have already issued. That is why secret scanning, SCA, and perimeter egress rules all failed in different ways here. The governance lesson is that machine identity has to be tied to runtime-bound trust, not reusable artefacts.

Identity blast radius is the real control metric for software supply chain risk. The same malicious dependency that touches one developer laptop can inherit every credential reachable in that environment, then fan out through Kubernetes or cloud APIs. That is not just compromise. It is uncontrolled privilege amplification across identity layers. Practitioners should measure how far a single process can reach before any policy boundary stops it.

Zero standing privilege belongs in the software supply chain discussion, not just privileged access reviews. This incident shows why persistent secrets on endpoints and long-lived service account tokens create standing access that malware can reuse immediately. Short-lived, scope-bound credentials reduce what can be stolen and what can be reused. Teams should treat standing credential exposure as a supply chain resilience issue, not only an IAM hygiene issue.

Runtime identity telemetry is the missing evidence layer for secret theft. The critical question is not only whether a secret existed, but which process opened it, which network destination received it, and whether that action matched the workload identity in use. Without that linkage, defenders learn about compromise after rotation begins. Practitioners need forensic visibility that joins process ancestry, file access, and identity context.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to The State of Secrets Sprawl 2026.
• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• For the wider failure pattern behind secret exposure and recovery, read The 52 NHI breaches Report for recurring credential abuse patterns.

What this signals

Static secret sprawl is becoming an operational liability that outlives detection. When 64% of valid leaked secrets remain exploitable long after disclosure, response plans built around finding secrets after the fact are already behind the curve. Teams should assume that revocation speed, not discovery speed, is the real control boundary.

The next governance step is to measure how much of your non-human identity estate still depends on reusable credentials. If a malicious dependency can read a token from disk, the issue is not package hygiene alone. It is whether your identity model still lets code possess authority in a form that survives compromise.

Identity blast radius is now a practical planning metric for software supply chain risk. If your developers, build agents, and runtime workloads all share the same secret patterns, one compromised process can cross too many trust boundaries before anyone sees it. The response is to narrow the identities, shorten the token life, and reduce the number of places secrets can exist.

For practitioners

• Eliminate file-based long-lived secrets Replace ~/.aws/credentials, .env API keys, and static Kubernetes secrets with short-lived workload credentials that are issued at runtime and expire automatically.
• Inspect package startup hooks before adoption Review .pth files, post-install scripts, and transitive dependencies for automatic execution paths that run before application code and without imports.
• Constrain Kubernetes service account scope Limit workload identities to namespace-level actions only, and block cluster-wide secret enumeration or privileged pod creation from routine service accounts.
• Instrument endpoint runtime identity telemetry Correlate process ancestry, file opens, and outbound connections so secret access from an unexpected Python child process is visible before exfiltration completes.
• Test for supply chain blast radius Simulate a malicious dependency on a developer workstation and map which cloud, cluster, and API credentials that process can actually reach.

Key takeaways

• This compromise showed that a malicious dependency can steal secrets without exploiting a CVE or a cloud provider.
• The scale of exposure is amplified by how long leaked credentials remain valid and how widely they are reused.
• The control that matters most is not faster rotation after theft, but removing standing secrets from machines in the first place.

Key terms

• Static Secret: A static secret is a reusable credential such as an API key, token, certificate, or password that remains valid until someone rotates it. In identity programmes, static secrets create persistence for attackers because any process that can read them can reuse them without proving runtime intent.
• Supply Chain Compromise: Supply chain compromise occurs when trusted software, packages, build paths, or dependencies are altered so that malicious code enters the environment through normal delivery channels. For identity security, the danger is that the compromised component inherits the trust and permissions already granted to the system it reaches.
• Identity Blast Radius: Identity blast radius is the amount of access, systems, and data that become reachable if one credential, token, or workload identity is abused. It is a useful governance measure because it turns abstract privilege into visible scope, showing how far a single compromise can spread before containment begins.
• Workload Identity: Workload identity is the non-human identity assigned to a service, application, container, or agent so it can authenticate and obtain access without using a shared human credential. It should be short-lived, scoped, and bound to runtime context, otherwise it becomes a reusable secret rather than an identity.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Hush Security: LLMjacking: How Attackers Hijack AI Using Compromised NHIs. Read the original.