PyTorch Lightning Breach: Credential Theft via PyPI v2.6.2 & v2.6.3
Just when we thought we could catch a break, here comes another supply chain hit. It looks like the pytorch-lightning package was compromised on April 30, 2026. Threat actors managed to publish versions 2.6.2 and 2.6.3 specifically designed to swipe credentials.
According to reports from Aikido Security and Socket, this isn't just a typo dependency issue; it's malicious code execution aimed at theft. If you are running AI/ML workloads, you need to audit your environments immediately. This package is ubiquitous in the data science community, so the blast radius could be massive.
Immediate Action Items:
- Audit your
requirements.txtand lock files. - Revoke any tokens or keys used in environments where these versions were installed.
Here is a quick script to check for the malicious versions in your current environment:
import pkg_resources
package_name = 'pytorch-lightning'
malicious_versions = ['2.6.2', '2.6.3']
try:
installed_version = pkg_resources.get_distribution(package_name).version
if installed_version in malicious_versions:
print(f"[!] CRITICAL: Malicious version {installed_version} detected.")
else:
print(f"[+] Safe: Version {installed_version} is installed.")
except pkg_resources.DistributionNotFound:
print(f"[-] Package {package_name} is not installed.")
This attack is being assessed as an extension of a broader campaign targeting developer tools.
How is everyone handling package pinning these days? Are you strictly using lock files like poetry.lock or requirements.txt with hashes, or do you rely on runtime scanning tools like Socket?
We saw this hit our CI pipeline this morning. luckily, we enforce strict dependency pinning using pip-compile, which failed the hash check before the build even completed.
If you aren't hashing your dependencies, you're flying blind. Here is the command to generate requirements with hashes:
pip-compile requirements.in --generate-hashes
This forces PyPI to present a hash that must match your lockfile, preventing these swaps entirely.
From a SOC perspective, this is a nightmare to detect post-facto because the traffic looks like valid Python package repository traffic.
We're hunting for processes spawned by pip that immediately reach out to non-standard IP addresses. You can use a simple KQL query to look for suspicious child processes:
ProcessCreationEvents
| where FileName in ("pip.exe", "pip3", "python.exe")
| where ProcessCommandLine contains "pytorch-lightning"
| project Timestamp, DeviceName, FileName, ProcessCommandLine
If you see `pip` installing something and then `python` instantly connecting to the internet, block it.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access