PyPI lightning supply chain attack exposes cloud and GitHub secrets

At a glance

What this is: A compromised PyPI package named lightning was found to run malicious code on import, steal secrets from developer and cloud environments, and plant persistence hooks in repositories.

Why it matters: IAM, NHI and CI teams need to treat package installation paths as credential-exposure paths, because compromised dependencies can harvest tokens, cloud access and workflow secrets before routine controls see them.

Context

PyPI supply chain compromise becomes an identity governance problem when a dependency can execute before trust is established. In this case, the malicious package is not just a code integrity issue; it is a path to credential theft across developer laptops, CI runners and cloud environments. That makes workload identity, token scope and secrets inventory central to the response.

The article is especially relevant to teams using CI pipelines, GitHub Actions and cloud-connected development workflows because the malicious package targets the places where non-human identities already operate with high privilege. Once credentials are exposed in those environments, standard application security controls no longer contain the blast radius.

Key questions

Q: How should security teams reduce the risk of npx commands resolving to unclaimed packages in CI and developer workflows?

A: Teams should avoid relying on npx to fetch tools from the registry at runtime. Use npx --no-install, pin approved CLI tools as explicit dependencies, and verify that documentation points to a real package before execution. In CI, this should be enforced as a policy, because convenience prompts can turn unclaimed names into arbitrary code execution.

Q: Why do exposed machine secrets make supply chain attacks worse?

A: Because machine secrets are often reusable across package publishing, repository access, and cloud operations. If attackers steal tokens or keys, they can use legitimate identities to publish malicious updates, create repositories, and expand access without needing a separate intrusion path. That multiplies the blast radius of the initial compromise.

Q: What are the signs that a repository has been used as a persistence mechanism after dependency compromise?

A: Look for unexpected .claude or .vscode files, new workflow definitions, unusual session-start or folder-open hooks, and commit patterns tied to the attacker’s naming convention. Those artefacts indicate the repository itself may now re-trigger the malware whenever a developer opens the project or pushes changes.

Q: How should teams respond when package compromise exposes cloud credentials?

A: Contain the affected runtime first, then revoke and rotate the exposed cloud credentials, review metadata service access, and inspect egress logs for exfiltration. The priority is to cut off reuse of the stolen identity material before the attacker can pivot into cloud services or downstream systems.

Technical breakdown

Import-time execution turns package install into a trust boundary failure

The malicious lightning versions place an obfuscated payload inside a hidden _runtime directory and trigger it automatically when the module is imported. That matters because import-time execution happens before many teams consider the package to be operationally active, which means the dependency itself becomes an execution vector. In supply chain terms, this is a build-time and runtime boundary collapse: the code path that should only deliver libraries instead delivers active malware. For teams running notebooks, training jobs or CI pipelines, the install step is already a compromise surface when the package is tainted.

Practical implication: Treat package installation and import as security-relevant events, not passive setup steps.

Credential harvesting spans developer, CI and cloud identity surfaces

The malware targets credentials across files, environment variables, GitHub Actions secrets and major cloud providers. That broad scope is important because modern development environments mix human and non-human identities in the same runtime context: local tokens, runner secrets, workload credentials and federated cloud access can all be present at once. By searching credential files, dumping environment variables and querying cloud secret stores, the attacker is not relying on one path. The design assumes that if one identity source is blocked, another may still expose reusable access tokens or API keys.

Practical implication: Inventory where credentials can exist in build and developer environments, then reduce shared exposure paths.

Repository persistence and worm propagation extend the compromise lifecycle

After initial theft, the malware tries to write persistence hooks into Claude Code and VS Code settings and then spread through GitHub and npm workflows. This is a classic supply chain propagation pattern: steal a valid identity, use it to plant automation, and let trusted developer tooling amplify the compromise. The important architectural point is that the attacker does not need long-lived direct access if they can convert one stolen token into repeated execution inside repositories. That makes repository write privilege and workflow secrets part of the threat model, not just the endpoint.

Practical implication: Limit repository-write credentials and inspect developer-tool config files as part of compromise containment.

Threat narrative

Attacker objective: Steal reusable credentials and convert them into persistent repository access and downstream package propagation.

1. Entry occurs when an operator installs lightning 2.6.2 or 2.6.3 and the hidden payload executes on module import.
2. Credential_harvested follows as the malware extracts GitHub tokens, cloud credentials, environment variables and CI secrets from the host and runner.
3. Escalation and persistence occur when stolen identities are used to write repository hooks, create malicious workflows and prepare downstream propagation.
4. Impact is credential reuse, repository poisoning and broader supply chain spread across developer and CI environments.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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

Supply chain compromise is now an NHI governance event, not only a software integrity event. When a package can run on import and harvest credentials from files, environment variables and cloud secret stores, the real failure is uncontrolled identity exposure inside trusted build paths. The governance question shifts from whether the dependency is safe to whether the environment can survive a malicious dependency with access to non-human identities. Practitioners should treat package trust, token scope and secret residency as one control surface.

Cross-environment credential convergence creates the blast radius. The article shows the same compromise touching local development, CI runners, GitHub and cloud providers. That pattern is important because it breaks the old assumption that developer tooling, pipeline identity and cloud workload identity are separate problems. In practice, a stolen token in one place can become access across multiple layers, so the defender must govern the intersections, not the individual tools. The response is to reduce shared credential reuse and narrow where secrets can be present at runtime.

Repository persistence through developer tooling is a named concept teams should recognise: developer-tool hook persistence. The malware’s use of Claude Code and VS Code hooks shows that repository control can outlast the original compromise window. Once an attacker can write session-start or folder-open automation, the repo itself becomes a re-trigger mechanism. That means security teams need to include developer-tool configuration in their NHI and supply chain control model, especially where write-capable identities can modify project files. The practical implication is to govern repo-level automation as part of identity lifecycle control.

Worm-style propagation changes what containment means. A malicious dependency that republishes itself into downstream packages creates a recursive compromise problem, not a single infected artifact. That makes traditional alerting too late if organisations wait for a downstream detection before taking action. The right governance response is to assume any writing identity exposed during the affected window may have been used to spread the compromise. Teams should therefore prioritise identity revocation, secret rotation and repository audit over narrow package removal.

Shai-Hulud-style attacks now tie together software supply chain risk and identity trust debt. The technical issue is not simply malicious code, but the accumulated trust that lets a token, repository secret or workflow credential be reused elsewhere with little friction. That is why the same package compromise can become a cloud exposure, a GitHub exposure and a CI exposure at once. Practitioners should read this as evidence that supply chain hardening and NHI governance must be designed together, not tracked in separate programmes.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Developer-tool hook persistence: repository control now extends beyond code into the automation that developers use to open and operate a project. When write-capable identities can alter session hooks or folder-open tasks, the repository itself can become a repeated execution point. Practitioners should include developer-tool configurations in the same governance boundary as CI secrets and workflow files.

Supply chain response plans need to assume that a compromised package can touch both human and non-human identities in one event. That means revocation, not just removal, becomes the priority because the attacker’s value lies in the tokens already harvested from developer, pipeline and cloud contexts. The programme implication is clear: if your secret sprawl is ungoverned, your dependency risk is already amplified.

For practitioners

• Audit dependency install paths for import-time execution Identify packages that run code during import or post-install, then restrict where they can execute in CI and notebook environments.
• Rotate exposed GitHub and cloud credentials Revoke tokens, API keys and cloud secrets that were present on affected hosts or runners, including values stored in environment variables and credential files.
• Inspect repositories for injected persistence files Search for unexpected .claude and .vscode configuration changes, especially session hooks, auto-run tasks and dropper files added by compromised workflows.
• Review write-capable identities in build systems Limit which GitHub and CI identities can modify workflow files, publish packages or push to repository branches used by automation.
• Trigger fresh scans on recently built projects Re-run dependency and advisory scans across active projects so that any installed malicious lightning versions are surfaced quickly.

Key takeaways

• A malicious package can turn dependency installation into credential theft, repository modification and downstream propagation in one sequence.
• The blast radius is larger when GitHub, cloud and CI secrets are available in the same runtime context, because one token can unlock multiple systems.
• Containment must focus on identity revocation, secret rotation and repository inspection, not just package removal, when supply chain malware is discovered.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• Developer-tool Hook Persistence: A persistence pattern where malware writes automation into tools such as IDEs or assistant runtimes so that the compromise re-triggers when the project is opened. It turns a repository into a recurring execution surface and extends attacker access beyond the original infection window.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• Supply Chain Propagation: Supply chain propagation is the spread of malicious code or trust abuse from one compromised package, account, or dependency into multiple downstream systems. The key risk is that trusted distribution mechanisms amplify impact faster than traditional endpoint or perimeter controls can respond.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity and secrets management for practitioners who need to connect identity controls to real operational risk. It is designed for teams responsible for access, auditability and secret exposure across modern delivery pipelines.