What Happened
On April 30, 2026, attackers published two malicious versions of PyTorch Lightning—versions 2.6.2 and 2.6.3—to the Python Package Index (PyPI) after compromising a publisher account. These packages contained code to steal developer credentials and automatically republish infected versions to spread the attack. Sonatype's security research team detected and reported the incident, leading to the removal of both packages.
This was not a typosquatting attack or a look-alike package. The attackers accessed the legitimate PyTorch Lightning namespace and pushed malicious code under the project's official name.
Timeline
- April 30, 2026: Attacker compromises publisher account and uploads malicious versions 2.6.2 and 2.6.3 to PyPI.
- April 30-May 2, 2026 (estimated): Packages remain available for download; any developer running
pip install pytorch-lightningor updating to the latest version receives the malicious code. - May 2, 2026: Sonatype detects and reports the malicious packages.
- May 2, 2026: PyPI removes versions 2.6.2 and 2.6.3.
The credential theft mechanism activated immediately upon installation, meaning any team that pulled these versions during the exposure window had their credentials compromised before they could complete their first import statement.
Which Controls Failed or Were Missing
Publisher Account Security: The compromised account lacked protection against credential theft. Multi-factor authentication (MFA) was either not enforced or not implemented. Using hardware security keys or time-based one-time passwords (TOTP) would have required more than stolen credentials to publish malicious packages.
Package Signing and Verification: PyPI does not enforce cryptographic signing for packages. If maintainers had signed their releases with GPG keys or used Sigstore, consumers could have detected that versions 2.6.2 and 2.6.3 were published without valid signatures.
Automated Dependency Scanning: Organizations that installed these versions lacked automated scanning to detect malicious behavior in dependencies before deployment. The credential-stealing code should have triggered alerts in any environment running Software Composition Analysis (SCA) tools configured to detect suspicious network calls or file system access patterns.
Dependency Pinning: Teams using unpinned version specifiers (pytorch-lightning>=2.6.0 or pytorch-lightning==latest) automatically pulled the malicious versions. Without explicit version pins and hash verification, there was no barrier between the compromised package and production environments.
Network Egress Controls: The malicious code successfully exfiltrated credentials, indicating that development environments lacked network segmentation or egress filtering. Outbound connections to attacker-controlled infrastructure should have been blocked or logged for review.
What the Relevant Standards Require
NIST 800-53 Rev 5 SR-3 (Supply Chain Controls) requires organizations to employ integrity verification mechanisms to detect unauthorized changes to software components. This includes verifying the integrity of packages through checksums, signatures, or hash verification before integration.
NIST 800-53 Rev 5 SR-4 (Provenance) mandates documenting and tracking the provenance of system components. For software dependencies, this means maintaining a Software Bill of Materials (SBOM) and verifying that packages originate from legitimate sources with valid signatures.
NIST 800-53 Rev 5 IA-5 (Authenticator Management) requires multi-factor authentication for accounts with elevated privileges. Publisher accounts on package repositories qualify as privileged access—they can push code that thousands of downstream consumers will execute without review.
ISO/IEC 27001:2022 Annex A.8.30 (Outsourced Development) addresses security requirements for externally developed software. While open source isn't traditional outsourcing, the control principle applies: verify the integrity of code from external sources before integration into your systems.
PCI DSS v4.0.1 Requirement 6.3.2 requires that software components are verified before deployment and that security patches are applied within defined timeframes. This includes maintaining an inventory of components (SBOM) and scanning for known vulnerabilities—a control that extends to detecting malicious packages.
OWASP ASVS v4.0.3 V14.2.2 specifies that package managers should verify component checksums or signatures before installation. This verification step would have caught the unsigned malicious versions if properly implemented.
Lessons and Action Items for Your Team
Enforce MFA on all package publishing accounts. If your team maintains any open source packages, enable hardware security keys or TOTP on every account with publish permissions. Review PyPI's security settings and enable every available protection. Document which team members hold these credentials and rotate them quarterly.
Pin dependencies with hash verification. Replace version ranges in your requirements.txt or pyproject.toml with exact versions and SHA256 hashes. Use pip-tools or poetry to generate locked dependency files. Your CI/CD pipeline should fail if a package hash doesn't match the expected value.
Implement automated SCA scanning in CI/CD. Deploy tools like Snyk, Socket, or Phylum that analyze package behavior, not just known CVEs. Configure these tools to fail builds if they detect suspicious network calls, credential access, or filesystem operations in new dependencies. Run scans on every pull request before code review.
Generate and maintain an SBOM. Use tools like Syft or CycloneDX to create a machine-readable inventory of every component in your application. Store these SBOMs in version control alongside your code. When incidents like this occur, you need to know within minutes whether you're affected—not after hours of manual investigation.
Segment development networks. Your development environments should not have unrestricted internet access. Implement egress filtering that allows connections only to approved package repositories and development tools. Log all outbound connections and review them weekly for anomalies.
Verify package signatures when available. While PyPI doesn't enforce signing, some maintainers publish GPG signatures separately. Check project documentation for signature verification instructions. For critical dependencies, contact maintainers and request that they implement Sigstore signing.
Create an incident response procedure for supply chain compromises. Document the steps your team will take when a dependency is compromised: How will you identify affected systems? Who has authority to block deployments? Where will you publish internal alerts? Test this procedure quarterly with tabletop exercises.
Review credentials immediately if you installed these versions. If your team pulled PyTorch Lightning 2.6.2 or 2.6.3, assume all credentials on those systems were compromised. Rotate API keys, access tokens, database passwords, and SSH keys. Review your audit logs for the 48-hour exposure window and investigate any suspicious access patterns.
The PyTorch Lightning incident demonstrates that even well-maintained, widely-used packages can be compromised through publisher account takeovers. Your defenses can't rely on upstream security alone. Build verification into every step of your dependency management process.
