TL;DR: A compromised PyPI package, lightning 2.6.2 and 2.6.3, can trigger on import, steal GitHub, cloud, and environment secrets, and plant persistence in developer tooling while also attempting worm-style propagation into downstream repositories, according to Semgrep. The incident shows how package integrity failures now translate directly into NHI governance problems, because tokens and secrets can be harvested and reused before teams detect the compromise.
NHIMG editorial — based on content published by Semgrep: the lightning PyPI supply chain compromise and its secret-stealing payload
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.
Questions worth separating out
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.
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.
Q: What do security teams get wrong about secret rotation?
A: They often treat rotation as a substitute for removing the underlying credential model.
Practitioner guidance
- Quarantine newly updated Python dependencies Block or sandbox package updates until installed versions are verified against trusted advisories, hashes, and lockfiles.
- Rotate every credential exposed to developer and CI environments Assume GitHub tokens, cloud keys, and API secrets present on affected hosts are compromised.
- 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.
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
👉 Read Semgrep's analysis of the lightning PyPI supply chain compromise →
PyPI lightning compromise: what NHI and CI teams need to know?
Explore further
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.
A few things that frame the scale:
- 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.
- 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.
A question worth separating out:
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.
👉 Read our full editorial: PyPI lightning supply chain attack exposes cloud and GitHub secrets