PyPI lightning supply chain attack exposes cloud and GitHub secrets

At a glance

What this is: This is a supply chain compromise of the PyPI package lightning that turns a routine import into secret theft, repository persistence, and downstream worm propagation.

Why it matters: It matters because IAM, NHI, and platform teams have to treat package installs, CI runners, and developer tooling as identity-bearing attack surfaces where tokens, secrets, and cloud access can be exfiltrated.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Semgrep's analysis of the lightning PyPI supply chain compromise

Context

PyPI supply chain compromise is not just a software integrity problem. Once a malicious dependency runs on import, it can inherit the privileges of the developer laptop, CI runner, or build pipeline that loaded it, which means credentials and secrets become the real target. In identity terms, this is a non-human identity exposure problem disguised as package management.

This case is a good example of why package installs, repository automation, and developer tooling now sit inside the identity control plane. The malicious lightning versions use the same basic pattern seen in modern NHI abuse: collect tokens, abuse cloud credentials, persist through automation hooks, and reuse identity artifacts to expand access beyond the original machine.

Key questions

Q: What breaks when a malicious dependency can execute on import in a build or ML pipeline?

A: A malicious dependency can turn installation into code execution, which means the package inherits the privileges of the developer machine or CI runner that loads it. If those environments hold tokens, cloud credentials, or repository write access, the attacker can steal and replay them immediately. The control failure is treating dependency install as non-executable activity.

Q: Why do service accounts and tokens create more supply chain risk than human logins?

A: Service accounts and tokens are often long-lived, reusable, and embedded in automation, which means they can be copied and replayed without interactive challenge. Human login controls like MFA and SSO help with employee access, but they do not by themselves govern machine-to-machine trust or third-party delegated access.

Q: What do security teams get wrong about secret rotation?

A: They often treat rotation as a substitute for removing the underlying credential model. Rotation lowers exposure time, but it still leaves a secret to steal, bootstrap, and govern. If a workload can avoid holding the secret at all, that is a stronger control than simply changing it more often.

Q: How should teams respond when a supply chain attack reaches GitHub and cloud secrets at the same time?

A: Contain the affected environments, revoke every token that was present on the compromised hosts, and audit repository automation for persistence files or malicious workflow changes. Then isolate publishing permissions from CI and developer access so one stolen credential cannot both leak secrets and spread the infection further.

Technical breakdown

How malicious Python packages execute on import

A supply chain package becomes dangerous when its install or import path contains code that runs automatically. In this case, the malicious lightning versions include a hidden _runtime directory and an obfuscated JavaScript payload that executes on module import, which means the attacker does not need an interactive session or a separate exploit. The import path itself becomes the execution path. That matters because developers often trust dependency installation as a passive action, but modern package ecosystems allow setup scripts, bootstrappers, and runtime loaders to trigger immediately. In practice, the risk boundary is the dependency tree, not just the repository being edited.

Practical implication: treat package import as an execution event and gate new dependencies with provenance, lockfile review, and sandboxed validation.

How secrets are harvested from dev, CI, and cloud environments

The malware targets the identity artifacts that matter most in engineering workflows: environment variables, GitHub tokens, runner memory, and cloud provider credentials. It scans filesystem paths for token formats, dumps process environment values, extracts secrets from GitHub Actions memory on Linux runners, and queries AWS, Azure, and GCP credential sources. That is a classic NHI abuse pattern because the attacker is not stealing a single account, but a reusable set of machine identities and tokens that can be replayed elsewhere. Once exfiltrated, those secrets often have more privilege than the original host should ever have had.

Practical implication: reduce standing access for build systems and make cloud and GitHub credentials short-lived, scoped, and tightly bound to workload identity.

How persistence spreads through developer tooling and publishing workflows

The attack does not stop at theft. It writes persistence hooks into Claude Code and VS Code configurations, then uses npm publish credentials or GitHub write access to seed more infected packages and repositories. This creates a cross-ecosystem propagation path where one compromised developer environment can infect downstream consumers through trusted tooling. The persistence model is especially concerning because it lives in directories developers routinely ignore, and it can re-trigger every time a project opens. In governance terms, the malware turns developer convenience tooling into an identity persistence layer.

Practical implication: audit developer tooling configs and publishing permissions separately from application code, because persistence can live outside the main repository tree.

Threat narrative

Attacker objective: The attacker wants to steal reusable credentials and secrets, then turn trusted development pipelines into a propagation channel for further compromise.

1. Entry occurs when a developer or CI pipeline installs the compromised lightning package from PyPI and the malicious code executes automatically on import.
2. Credential access follows as the payload steals environment variables, GitHub tokens, cloud secrets, and runner memory from developer and build environments.
3. Escalation and propagation occur when stolen publish credentials or repository write access are used to inject hooks, publish infected downstream packages, and seed additional repositories.
4. Impact is broad secret exposure, repository compromise, and worm-like spread across engineering environments and cloud accounts.

Breaches seen in the wild

• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.
• 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

Package integrity is now an identity problem, not just a software one. When a dependency executes on import, the real asset under attack is the machine and service identity it can reach. That shifts governance from code review alone to controls over tokens, build identities, and trust in the software supply chain. Practitioners should treat dependency trust as part of NHI governance.

Standing secrets create the blast radius that supply chain malware monetises. The malware succeeds because developer workstations and CI runners often hold persistent credentials that can be replayed outside the original context. That is a classic standing privilege failure, only expressed through tokens, API keys, and cloud access rather than human accounts. The governance lesson is clear: secret persistence is the failure mode.

Cross-ecosystem infection makes developer tooling part of the control surface. By persisting through Claude Code, VS Code, and package publishing, the attack shows that the operational boundary now includes editor hooks, workflow files, and automation credentials. Security teams that separate application security from identity and endpoint governance will miss this class of compromise. The practical conclusion is that tooling-level controls belong in the same review cycle as secret rotation and access review.

Runtime secret theft is accelerating the convergence of AppSec and IAM. Once attackers can harvest cloud credentials, GitHub tokens, and runner memory in one pass, traditional vulnerability management cannot contain the blast radius. The relevant question is no longer whether a package is malicious, but whether the environment gives that package reusable identity material to steal. Practitioners should align software supply chain controls with NHI lifecycle controls.

Secret sprawl is the named concept this incident exposes. A single compromised package can reach multiple secret stores, local files, and CI surfaces because credentials are fragmented across tools and environments. That is not just exposure, it is governance failure through duplication and weak lifecycle control. Teams should read this as a signal to consolidate identity-bearing secrets and reduce the number of places they can be harvested.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 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.
• Forward pivot: Review The 52 NHI breaches Report to compare this campaign with other credential abuse and secret theft patterns.

What this signals

Secret sprawl now determines blast radius. When credentials are scattered across developer tooling, CI memory, cloud consoles, and local files, one compromise can become many. The right programme response is not only faster detection, but tighter identity scoping for every secret-bearing system, backed by lifecycle controls that assume reuse is the attacker’s goal.

NHI lifecycle controls need to extend into software delivery. Build identities, package publishing tokens, and editor-integrated automation all act like non-human identities with their own onboarding, access, and offboarding risks. Teams that already map secret rotation and access review should extend that discipline to dependency ecosystems and developer tooling, not treat them as adjacent concerns.

Token persistence is the gap this campaign exploits. A secret that survives in a repo, workflow, or local tool after its original purpose is over becomes an attacker-owned access path. The operational signal to watch is not just exposed secrets, but whether those secrets can still authenticate after the workflow that created them has changed.

For practitioners

• Quarantine newly updated Python dependencies Block or sandbox package updates until installed versions are verified against trusted advisories, hashes, and lockfiles. Prioritise packages that run code on import or sit in build and ML pipelines.
• Rotate every credential exposed to developer and CI environments Assume GitHub tokens, cloud keys, and API secrets present on affected hosts are compromised. Rotate them, revoke unused scopes, and reissue short-lived credentials for build and deployment systems.
• Audit editor and repository hooks for persistence paths Inspect .claude, .vscode, workflow files, and publish scripts for unexpected auto-run logic or injected setup files. Persistence in these paths can re-trigger compromise after the initial package install.
• Separate publish privileges from build privileges Use distinct identities for package publication, repository maintenance, and CI execution so a stolen token cannot both exfiltrate secrets and republish infected artefacts. Narrow scopes wherever possible.
• Review the 52 NHI Breaches Analysis for recurring secret abuse patterns Use the 52 NHI Breaches Analysis to compare this campaign with earlier credential theft and propagation cases, then map the lessons to your own token lifecycle and offboarding controls.

Key takeaways

• A compromised package can become an identity breach when it steals tokens, cloud secrets, and repository access from the environments that install it.
• This campaign shows how quickly secret exposure can turn into active abuse, especially when credentials are persistent and broadly scoped.
• Teams should treat package trust, developer tooling, and secret lifecycle controls as one control plane, not separate security problems.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• Secrets Management: The discipline of securely storing, distributing, rotating, and auditing secrets across an organisation's systems and pipelines — typically implemented via a centralised secrets vault such as HashiCorp Vault, AWS Secrets Manager, or Akeyless.
• SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.
• Credential exfiltration: Credential exfiltration is the theft of usable authentication material such as tokens, keys, or certificates. In NHI environments, the stolen item is often already valid and can be replayed immediately. That is why detection must be paired with revocation and entitlement review rather than relying on alerts alone.

What's in the full analysis

Semgrep's full analysis covers the operational detail this post intentionally leaves for the source:

• IOC-level file and repository indicators that help you confirm whether lightning 2.6.2 or 2.6.3 reached your environment
• Specific remediation steps for GitHub tokens, AWS credentials, Azure Key Vault access, and GCP Secret Manager exposure
• The exact malicious paths and workflow artefacts to hunt for in .claude and .vscode directories
• Semgrep advisory and rule coverage that can be used to scan affected projects and dependency trees

👉 Semgrep's full post covers the attack chain, indicators of compromise, and remediation guidance for affected projects.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in practical terms. It helps security and IAM practitioners apply lifecycle control thinking to the systems that store and use credentials every day.