PyTorch Lightning Compromised in Supply Chain Attack — Malware Steals Credentials Automatically on Import
Versions 2.6.2 and 2.6.3 of PyTorch Lightning were compromised in a supply chain attack — executing credential-stealing malware automatically on import, targeting SSH keys, cloud credentials, GitHub tokens, and crypto wallets.
PyTorch Lightning's PyPI package was compromised in a supply chain attack — two malicious versions published April 30 execute credential-stealing malware automatically on import, targeting SSH keys, cloud credentials, GitHub tokens, and cryptocurrency wallets from developer machines and CI/CD pipelines.
SAN FRANCISCO — Security firms Aikido Security, Socket, OX Security, and StepSecurity simultaneously flagged two malicious versions of the widely used lightning Python package on April 30, 2026 — just 18 minutes after publication. Versions 2.6.2 and 2.6.3 of PyTorch Lightning, the open-source deep learning framework with over 31,100 GitHub stars and millions of monthly PyPI downloads, contained hidden malicious code that executes automatically the moment the package is imported. No additional user action required. PyPI administrators quarantined the project within hours of the disclosure. Version 2.6.1, released January 30, 2026, remains the last known clean baseline.
Attack profile
The attack chain
The malicious versions insert a hidden _runtime directory and modify __init__.py so that a background thread launches start.py when the lightning module is imported. start.py downloads the Bun JavaScript runtime and executes an 11MB obfuscated JavaScript payload. The obfuscated file contains over 703 references to process and env, 463 references to tokens and authentication, and 336 references to repositories — the full fingerprint of a comprehensive credential harvesting operation. Stolen data is exfiltrated via four parallel channels (HTTPS POST to C2, GitHub repository commits using stolen tokens, and two additional paths) ensuring data reaches the attacker even if individual channels are blocked. The worm propagation capability is the most alarming element: if the malware finds npm publish credentials on the infected machine, it injects a setup.mjs dropper into every package that token can publish to, bumps the patch version, and republishes — potentially spreading to downstream developers who install any of those packages.
The compromised GitHub account and disclosure suppression
A community member flagged the compromise in Lightning-AI's GitHub repository under issue #21689, titled "Possible supply chain attack on version 2.6.3." That issue was closed without public explanation. When Socket filed a follow-up warning, it was closed within one minute by the pl-ghost account, which posted a "SILENCE DEVELOPER" meme in response. Socket confirmed the pl-ghost account is compromised — consistent with the same stolen credentials used to publish the malicious PyPI versions being used to suppress incoming disclosures on GitHub. The pl-ghost account also probed other Lightning-AI repositories during the incident window, with four short-lived branches pushed and deleted across Lightning-AI/litAI, utilities, and torchmetrics between 12:40Z and 13:44Z. This is part of the broader Mini Shai-Hulud campaign previously linked to compromises of LiteLLM (March 24), Telnyx (March 27), and Xinference. For all supply chain attack coverage
on The CyberSignal, and our guide on how supply chain attacks work and spread
.
What to do now
Any developer or CI/CD pipeline that installed and imported lightning versions 2.6.2 or 2.6.3 should treat the environment as fully compromised. Immediately downgrade to version 2.6.1 or below. Rotate all credentials that may have been exposed: GitHub tokens, npm tokens, AWS/GCP/Azure access keys, and any secrets in environment variables. Audit GitHub repositories for unexpected commits or encoded data. Review CI/CD pipeline logs and developer workstations for any activity during the April 30 window. Flag any npm packages published from affected machines — the worm capability means compromised tokens may have already published poisoned packages to downstream registries. Report indicators of compromise to Socket at socket.dev.
The CyberSignal Analysis
Signal 01 — Import-time execution removes every downstream defense
The design choice to trigger the malicious payload on import — not on installation, not on a specific function call — eliminates virtually every downstream defensive measure. Developers who inspect package contents before installation will not catch the execution. CI/CD pipelines that sandbox installation will not prevent execution. Any system that imported versions 2.6.2 or 2.6.3 is compromised, full stop. The only reliable defense against import-time execution is pre-installation scanning, which Socket demonstrated is possible — their AI scanner flagged both versions 18 minutes after publication.
Signal 02 — Worm propagation via stolen npm tokens creates exponential blast radius
The most dangerous capability in this attack is not the credential theft — it is the worm propagation via stolen npm publish tokens. A single developer with publish rights to multiple npm packages who imports the compromised lightning version may inadvertently become a distribution vector for the same malware to reach every downstream user of every package they maintain. This is not theoretical: the Mini Shai-Hulud campaign has demonstrated this capability across multiple prior incidents. The blast radius of a single developer credential compromise in a well-connected open source ecosystem can extend to millions of downstream installations.
Signal 03 — The Mini Shai-Hulud campaign represents systematic open-source infrastructure targeting
LiteLLM in March. Telnyx in March. Xinference shortly after. Now PyTorch Lightning in April. The Mini Shai-Hulud campaign is not hitting random targets — it is systematically working through the Python AI and machine learning ecosystem, targeting packages that are heavily used in developer and CI/CD environments where credential density is high and package trust is implicit. This is a deliberate campaign against AI development infrastructure, and it is ongoing. Organizations building AI products need to treat their Python package dependency graph as a critical attack surface requiring active monitoring.
