On April 30, 2026, two malicious releases of the lightning package, the PyPI distribution behind PyTorch Lightning, were pushed live. Versions 2.6.2 and 2.6.3 carried a credential stealer that fired the moment a developer imported the module. The same campaign hit the npm intercom-client package. Neither was a typosquat. These were trusted, widely depended-on packages, and on a normal day lightning pulls hundreds of thousands of downloads. Socket's scanners flagged the releases roughly eighteen minutes after publication, and the malicious versions stayed live on PyPI for about 42 minutes before they were quarantined and deleted, with 2.6.1 standing as the last clean release. But even 42 minutes of an auto-installing payload on a package that size is enough to matter.
This one deserves a careful read, not because the malware was exotic, but because of what it was hunting. The attackers were not after a crypto wallet on some hobbyist's laptop. They were after the exact secrets that live inside machine learning build pipelines: cloud IAM tokens, GitHub and npm tokens, Kubernetes secrets, and CI/CD environment variables. ML developer tooling has quietly become one of the highest-value targets in the software supply chain, and this incident is a clean illustration of why.
What actually shipped in the package
The malicious wheel hid a _runtime directory containing a downloader and an obfuscated JavaScript payload. When a developer ran import lightning, the execution chain started on its own. No flag, no opt-in, no second step. A start.py component reached out to GitHub to pull down the Bun JavaScript runtime, then executed router_runtime.js, an obfuscated payload reported at around 11 MB. The work ran inside a daemon thread with its output suppressed, so nothing obvious surfaced in the terminal while it executed.
Analysts who reverse-engineered the payload counted hundreds of references to process and environment data, hundreds more to tokens and authentication material, and a large block dedicated to repository operations. In plain terms: the malware was built to read everything the running process could see and to reach into the developer's source control.
The behavior was staged. Stage one harvested credentials, scanning for GitHub, npm, AWS, Azure, and GCP material using both regex patterns and direct calls to cloud metadata and credential endpoints. Stage two used any stolen GitHub token to poison repositories through the GraphQL API, committing a self-copying payload, reportedly under a spoofed commit identity. Stage three turned to propagation on npm, injecting a setup.mjs file into package roots and rewriting package.json to add a postinstall hook so the infection could ride along into downstream publishes.
Why ML tooling is the bullseye
Think about what a lightning import implies about the environment around it. You are almost certainly on a machine, a notebook, or a CI runner that touches model training infrastructure. That means GPU cluster access, cloud IAM roles with real spend and storage attached, model registry tokens, dataset bucket credentials, and experiment-tracking keys. These environments concentrate exactly the kind of long-lived, high-privilege secrets that attackers want, and they often do it with looser hygiene than production application stacks.
There is a cultural factor too. ML and data science workflows lean heavily on fast iteration, shared notebooks, and pip-installing whatever the latest tutorial recommends. Pinning, lockfiles, and provenance checks are common in mature application teams and far less common in research and experimentation environments. The result is a soft target sitting on top of expensive, sensitive infrastructure. An attacker who lands a credential stealer inside a training pipeline can pivot to cloud accounts, poison models, exfiltrate proprietary datasets, or simply rack up compute on someone else's bill.
This is the part worth internalizing: the package was a delivery vehicle. The prize was the credential surface that ML work tends to accumulate.
A pattern, not a one-off
The lightning and intercom-client compromise did not appear in a vacuum. It has been described as an extension of the broader "Mini Shai-Hulud" activity that earlier hit npm packages, and it shares tradecraft with self-propagating campaigns seen across 2026, including install-time execution, credential harvesting, and cross-ecosystem worming between npm and PyPI. The repository-poisoning and postinstall-worm behavior here is the same DNA that has shown up repeatedly this year.
Several reports attribute the activity to a group operating under the TeamPCP banner, and the operators reportedly claimed responsibility on a Tor site. Attribution claims from threat actors should always be treated with a grain of salt, so take the specific naming as reported rather than confirmed. What is not in doubt is the shape of the threat: a trusted package, a near-instant post-install or post-import trigger, automated credential theft, and a built-in mechanism to spread to the next victim. That combination is now a repeatable playbook, and ML libraries are squarely in scope.
What to do about it
First, the immediate hygiene. If you pulled lightning 2.6.2 or 2.6.3, treat any credential that was reachable from that environment as compromised. Rotate GitHub and npm tokens, cloud keys, Kubernetes secrets, and CI/CD variables. Pin to a known-good version and review recent commits and published packages for unexpected postinstall hooks or stray setup.mjs files.
Beyond cleanup, the structural lessons hold for any team shipping ML code:
- Pin dependencies and use lockfiles, even in research environments. "Latest" is a liability when import alone can execute code.
- Scope credentials tightly and prefer short-lived, federated tokens over long-lived static keys sitting in environment variables.
- Run installs and imports for untrusted or freshly bumped packages in sandboxed, network-restricted environments before they touch a pipeline with real secrets.
- Generate and keep an inventory of what your ML stack actually depends on, including models and datasets, so a compromise has a known blast radius.
- Watch for install-time and import-time network egress to code-hosting and runtime-download endpoints, which is exactly how this payload pulled Bun and executed.
None of this is glamorous. It is the unglamorous work that turns a frantic incident into a contained one.
How Safeguard Helps
Safeguard treats your dependency graph and your ML stack as one supply chain to defend. We continuously check packages and registries for compromised releases, malicious install hooks, and anomalous behavior, and our AIBOM and ML-BOM inventory plus provenance and attestation give you a concrete blast radius the moment a package like lightning goes bad. Policy gates and the vendor policy registry let you block unvetted version bumps before they reach a pipeline holding real cloud and CI/CD credentials, and our Multi-Agent TAOR Deep Think AI Engine runs verification above any single model, so detections of this kind are cross-checked rather than taken at face value. If you want to pressure-test your ML supply chain against attacks like this one, reach out.