CVE-2026-44484 is a critical supply chain compromise (CVSS 9.8) in the pytorch-lightning package on PyPI. Per the maintainers, versions 2.6.2 and 2.6.3 contained code that behaves like a credential harvester. Pin to 2.6.1, rebuild affected systems and rotate any secrets those systems could reach.
What's affected
From the maintainers' security advisory:
- Compromised: pytorch-lightning 2.6.2 and 2.6.3.
- Recommended safe version: 2.6.1.
The record text mentions 2.6.2 only. The advisory says the team was still confirming the exact set of impacted versions when it was written, and lists 2.6.2 and 2.6.3 as the versions to delete. Treat the advisory as the live source and re-read it before you close this out.
The advisory says the malicious versions were quarantined on PyPI and that the root cause was still under investigation. Because the code sits in a package that data science teams install in notebooks, CI jobs and training images, the risk covers every place those versions were installed, not just production.
How to check if you're exposed
Search every environment for the two versions. For a single environment:
pip show pytorch-lightning
pip freeze | grep -i lightning
Search lock files and images across your repositories, for example:
grep -rn "pytorch-lightning" requirements*.txt poetry.lock Pipfile.lock pyproject.toml uv.lock 2>/dev/null
Check container images and build caches that may have pulled the package during the affected window. If you find either version anywhere, treat that machine or image as exposed.
What to do now
- Remove pytorch-lightning 2.6.2 and 2.6.3 everywhere, and pin 2.6.1 as the maintainers recommend.
- Treat every environment that installed those versions as compromised. Rebuild from a known clean state instead of cleaning in place.
- Rotate credentials those environments could reach: API keys, access tokens, SSH keys and service account credentials, as the advisory lists.
- Review logs for suspicious outbound traffic or unexpected activity from the affected machines.
- Pin dependencies with hashes in lock files so a new upload under the same package name cannot slip into a build unnoticed.
Why it matters
This entry is a supply chain compromise, not a coding flaw. The record lists CWE-506 (embedded malicious code) and CWE-829 (inclusion of functionality from an untrusted control sphere). The legitimate project name and package page were used to ship code the maintainers did not intend.
That changes how you respond. A normal patch removes a bug, and nothing about your secrets changes. A malicious release may already have read environment variables, config files and tokens on the machine that installed it, so the work is rebuild and rotate, not just upgrade.
Machine learning environments often hold cloud keys, dataset access and registry credentials, so the blast radius can be larger than the package's job suggests. The record does not mark this CVE as KEV. The maintainers describe it as a compromise under investigation, and you should read their advisory for updates.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is the fix a newer version of the package?
The advisory recommends pinning 2.6.1, the last version before the compromised ones. Check the advisory for any later clean release.
Is removing the package enough?
No. If either version ran, assume the environment is compromised, rebuild it and rotate the credentials it could access.
Sources
Last reviewed: 19 October 2026.
