The PyTorch Lightning machine learning framework has been confirmed as the latest target of the Mini Shai-Hulud supply chain campaign that previously compromised SAP’s official npm packages and several other developer tool distribution channels. Versions 2.6.2 and 2.6.3 of the pytorch-lightning package on PyPI contained a malicious postinstall payload that executed on package installation and exfiltrated developer credentials and environment configuration from the installing host.
What Was Compromised
Aikido Security researchers identified the malicious versions on 30 April, triggering PyPI’s emergency removal process. The affected versions — 2.6.2 and 2.6.3 — were live for approximately 18 hours before removal. PyTorch Lightning is a widely-used framework for training deep learning models with PyTorch, with an estimated 2–4 million monthly downloads.
The malicious payload followed the same structural pattern observed in the SAP npm compromise: a legitimate-appearing setup.py postinstall script that executed a secondary Python script fetching a payload from a GitHub Gist URL. The secondary payload performed:
- Environment variable enumeration (capturing API keys, tokens, and cloud credentials stored as environment variables)
- Collection of cloud provider credential files (
~/.aws/credentials,~/.config/gcloud/, Azure CLI tokens) - Collection of Python package index tokens (
~/.pypirc, pip authentication files) - Git configuration file collection (
~/.gitconfigincluding any credential helpers or embedded tokens)
Data was exfiltrated via HTTP POST to a Cloudflare-hosted endpoint — the same infrastructure pattern used in DEEP#DOOR and consistent with the broader Mini Shai-Hulud campaign’s use of legitimate CDN infrastructure for exfiltration endpoints.
Campaign Attribution and Pattern
Research from Aikido, Socket Security, OX Security, and StepSecurity has linked this PyTorch Lightning compromise to the same threat actor responsible for the prior April 2026 SAP npm campaign, the @bitwarden/cli compromise via Checkmarx CI/CD credentials, and the Checkmarx Docker Hub image tagging attacks. The shared payload delivery pattern, Cloudflare endpoint infrastructure, and exfiltration format (Bun runtime, router_runtime.js payload name, identical GitHub Gist delivery mechanism) confirm a single coordinated campaign across multiple package ecosystems.
The campaign’s consistent targeting of AI/ML tooling (PyTorch Lightning), security tooling (Bitwarden CLI), and enterprise software development (SAP packages) reflects a targeting strategy oriented toward developer credential harvesting at organisations working in high-value sectors — financial technology, cybersecurity, and enterprise software development.
Scope of Exposure
Any developer or CI/CD system that installed pytorch-lightning==2.6.2 or pytorch-lightning==2.6.3 during the 18-hour exposure window (approximately 30 April to 1 May 2026) should be treated as a credential compromise candidate. A pip show pytorch-lightning on affected systems will report the installed version; the clean replacement version is 2.6.4 or later.
Virtual environments, Docker build caches, and CI/CD pipeline dependency caches may all contain the malicious version if they cached packages during the exposure window — a version match does not require a fresh install.
Recommended Actions
- Audit all Python environments for affected versions: Check all developer workstations, CI/CD agents, and container build environments. Run
pip show pytorch-lightning | grep Versionorpip list | grep pytorch-lightning. - Treat any match as a credential compromise: For any environment where the affected version was installed, assume that environment variables, AWS/GCP/Azure credentials, and PyPI tokens were exfiltrated. Rotate all secrets accessible from those environments immediately.
- Purge pip and Docker caches: Remove cached packages from affected version ranges:
pip cache purgeand rebuild any Docker images that may have cached the malicious versions. - Audit CI/CD pipeline logs: Review pipeline logs from 30 April–1 May 2026 for runs that installed
pytorch-lightning— these pipeline environments should have their service account credentials rotated. - Verify PyPI token scopes: PyPI token scope should be limited to specific projects, not account-wide. Review token configuration and rotate any broad-scope tokens that may have been exposed.
The Mini Shai-Hulud campaign’s expansion from npm to PyPI confirms that it is targeting developer credential infrastructure across ecosystems, not package-manager-specific. Organisations with mixed Python and JavaScript development environments should treat both ecosystems as potentially compromised.
Share this article