PyPI Lightning supply attack

A Python package attack is bad in the abstract. A Python package attack on Lightning is worse, because Lightning sits inside a lot of machine-learning training and CI workflows. That means the danger was not just “someone downloaded a bad library.” The danger was that a trusted package could run credential-stealing code the moment it was imported. That is what happened on April 30, when malicious Lightning versions 2.6.2 and 2.6.3 hit PyPI before the project was quarantined and maintainers told users to treat affected environments as compromised. (github.com) ### What exactly got hit? The package in the blast radius was `lightning`, the modern PyPI distribution for the deep-learning framework long associated with PyTorch Lightning. Lightning AI’s advisory says versions 2.6.2 and 2.6.3 were compromised, while 2.6.1 is the safe version to pin to for now. The maintainers also said they revoked and rotated internal release credentials and are still investigating how the compromise happened. (github.com) ### Why is “import” the scary part? Because the malware did not wait for some obscure function call. Researchers found malicious changes in `__init__.py`, which runs as soon as Python imports the package. That code spawned a background process, reached into a hidden `_runtime` directory, and kicked off a downloader. Basically, a norm(github.com)ed loading. (github.com) ### What did the payload do? The loader pulled down Bun — a JavaScript runtime — and used it to execute an obfuscated payload of roughly 11 MB. Security writeups tie that payload to credential theft rather than sabotage. The target list is ugly: API keys, access tokens, SSH keys, cloud credentials, `.env` files, browser and developer-session data, Docker and K(github.com) was not to break Lightning. The point was to steal whatever secrets a developer workstation or CI runner had lying around. (aikido.dev) ### Why does Bun show up in a Python attack? That is the weird tell here. Instead of rewriting the stealer in Python, the attackers shipped a thin Python wrapper that downloaded Bun and ran a JavaScript blob. Turns out that matters because multiple researchers see the same pattern in the recent “Mini Shai-Hulud” supply-chain campaign that hit np(aikido.dev)ss-ecosystem attack kit. (aikido.dev) ### How big was the exposure window? Big enough to matter. Snyk notes that `lightning` sees about 311,027 downloads per day, with the older `pytorch-lightning` package adding another 436,296 daily downloads. Sonatype says the two malicious releases were published back to back, with 2.6.3 arriving 13 minutes after 2.6.2 — and 2.6.3 was not a fix. It kept the malicious behavior. (snyk.io) ### What should affected users do now? Assume compromise first, then clean up. Lightning AI’s guidance is blunt: delete 2.6.2 and 2.6.3, rotate any credentials that may have been exposed, rebuild affected systems from a known-clean state, pin to 2.6.1, and review logs for suspicious activity. The catch is that if secrets were already harvested, unin(snyk.io)ntil you revoke them. (github.com) ### Why does this story matter beyond Lightning? Because this is what software supply-chain risk looks like when it stops being theoretical. One poisoned package can turn an everyday dependency update into a secret-exfiltration event across laptops, cloud runners, and internal build systems. Lightning was the vehicle here. But the re(github.com)now exactly where to look. (github.com) ### Bottom line? This was not a broken release. It was a trusted ML package turned into a credential stealer. If `lightning` 2.6.2 or 2.6.3 touched your machine on April 30, treat that machine — and every secret on it — like it already left the building. (github.com)