What Happened
On April 30, 2026, threat actors released two malicious versions of PyTorch Lightning—2.6.2 and 2.6.3—on the Python Package Index (PyPI). These packages included a hidden _runtime directory with a downloader and an obfuscated JavaScript payload aimed at stealing credentials from development environments. The attack is linked to TeamPCP, a group also targeting the intercom-client package at the same time.
The malicious code activated during installation, executing silently in CI/CD pipelines and developer workstations that used the compromised versions. Organizations using automated dependency updates or version ranges that included 2.6.x were especially at risk.
Timeline
April 30, 2026: Malicious versions 2.6.2 and 2.6.3 published to PyPI
Detection window: Unknown duration before discovery and removal (PyPI has since removed both versions)
Impact scope: Any environment that installed these specific versions during the exposure window
The simultaneous release of both versions suggests a coordinated strategy to maximize impact before detection.
Which Controls Failed or Were Missing
Dependency integrity verification: Teams that installed these packages did not use cryptographic verification of package signatures. PyPI does not enforce package signing, and most Python toolchains do not verify package provenance by default.
Automated update policies without security gates: Organizations using tools like Dependabot or Renovate with auto-merge enabled deployed the malicious code without human review. The packages passed basic functionality tests because the attack payload operated independently of the legitimate codebase.
Runtime monitoring in build environments: The malicious _runtime directory executed during installation, but most teams do not monitor filesystem changes or network connections during package installation. Your CI/CD agent pulled the package, ran the installer, and the payload executed without triggering alerts.
Supply chain security scanning: Static analysis tools that scan for known vulnerabilities missed this attack because it involved zero-day malicious code injection, not a CVE in legitimate code. Teams relying solely on SCA tools that check for known vulnerabilities had no protection.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.3.2 mandates maintaining an inventory of bespoke and custom software, including third-party libraries. This requirement expects you to track what you're running—but tracking alone doesn't prevent malicious packages from entering your environment.
Requirement 6.4.3 addresses scripts loaded and executed in the consumer browser, but the principle extends to your build environment: scripts executed during package installation operate with the same privileges as your build system. You need controls that prevent unauthorized code execution during dependency installation.
NIST 800-53 Rev 5 Control SA-12 (Supply Chain Protection) requires organizations to employ integrity verification mechanisms for software and firmware components. This means cryptographic validation of packages before installation, not just trusting PyPI's infrastructure.
Control SR-3 (Supply Chain Controls and Processes) specifically calls out the need to employ anti-counterfeit technologies and processes. In the context of package repositories, this translates to verifying package authenticity through signatures or checksums maintained in a separate trusted channel.
ISO 27001 Control 8.30 (Outsourced Development) requires that you apply security controls to outsourced development activities. When you pip install a package, you're incorporating outsourced code into your application. The control expects you to validate that code before integration.
Lessons and Action Items for Your Team
Implement dependency pinning with hash verification. Stop using version ranges in production dependencies. Your requirements.txt should specify exact versions with SHA256 hashes:
pytorch-lightning==2.6.1 \
--hash=sha256:abc123...
Generate these with pip-compile --generate-hashes. When TeamPCP publishes version 2.6.2, your builds fail because the hash doesn't match—which is exactly what you want.
Add a package approval workflow. Create a private PyPI mirror using tools like devpi or Artifactory. New packages enter your mirror only after manual review or automated security scanning. Your developers install from the mirror, not directly from PyPI. This adds latency to dependency updates, but it creates a chokepoint where you can catch malicious packages.
Monitor installation-time behavior. Install packages in isolated containers and monitor for unexpected network connections, filesystem modifications outside the package directory, or process spawning during installation. Tools like Syft can generate SBOMs that include installation-time artifacts—compare the actual installed files against the expected package manifest.
Audit your CI/CD permissions. The malicious payload executed with the same privileges as your CI/CD agent. If that agent has AWS credentials, database passwords, or API keys in environment variables, the payload can exfiltrate them. Use short-lived credentials, rotate them frequently, and scope them to the minimum necessary permissions. Consider using tools like Chamber or AWS Secrets Manager that require explicit secret retrieval rather than exposing secrets as environment variables.
Disable automatic dependency updates in production pipelines. Dependabot and Renovate are valuable for surfacing available updates, but auto-merge for anything beyond patch versions is dangerous. Configure these tools to create pull requests that require manual approval and automated security scanning before merge.
Implement SLSA framework principles. The Supply-chain Levels for Software Artifacts (SLSA) framework provides a maturity model for supply chain security. Start with SLSA Level 1: document your build process and generate provenance attestations. Move to Level 2 by using a hosted build service that generates signed provenance. Your goal is verifiable builds where you can trace every artifact back to specific source code and build parameters. SLSA framework
Create an incident response plan for supply chain compromise. When you discover a malicious package in your environment, you need a playbook: Which credentials were exposed? Which systems ran the compromised code? How do you rotate credentials without causing an outage? Document this now, not during an active incident.
The PyTorch Lightning attack succeeded because it exploited the trust relationship between developers and package repositories. Your team probably installed hundreds of packages this month. Without cryptographic verification and installation-time monitoring, any one of them could be the next supply chain attack vector.
