Popular Python package lightning hacked in supply chain attack

The popular Python package lightning was compromised in a supply chain attack that pushed credential-stealing malware to PyPI. The malicious releases affected versions 2.6.2 and 2.6.3, both published on April 30, 2026.

The package is widely used by AI and machine learning developers through the PyTorch Lightning ecosystem. That makes the incident especially serious for developer laptops, CI/CD systems, cloud build runners, notebooks, and training environments that may have installed the compromised versions.

Security researchers found that the malware ran when the package was imported. That means a developer did not need to manually execute a suspicious file. A normal import lightning statement could start the hidden payload in the background.

What happened

Socket said it detected malicious code in lightning versions 2.6.2 and 2.6.3 shortly after publication. The company said version 2.6.1, released on January 30, 2026, remained the last known clean version.

The official Lightning security advisory also lists 2.6.2 and 2.6.3 as affected versions and tells users to delete them from systems. The advisory says the affected releases introduced functionality consistent with credential harvesting.

The root cause of the compromise remains under investigation. However, the project said it has quarantined the malicious versions from PyPI, rotated internal credentials tied to its release process, and started a full investigation.

At a glance

Item	Details
Affected package	lightning
Ecosystem	Python Package Index, PyPI
Affected versions	2.6.2 and 2.6.3
Last known clean version	2.6.1
Trigger	Package import
Main risk	Credential theft from developer and CI/CD environments
CVE status	No known CVE listed in the official advisory

How the malware worked

The malicious package included a hidden _runtime directory. Inside it, researchers found a Python launcher and a large obfuscated JavaScript payload.

The execution chain began with a Python file named start.py. It downloaded the Bun JavaScript runtime from GitHub and used it to run a file called router_runtime.js.

Researchers described the JavaScript payload as a heavily obfuscated credential stealer. It looked for secrets such as GitHub tokens, npm tokens, cloud credentials, environment variables, and other authentication material.

Why this attack is dangerous

The attack hit developer environments rather than ordinary consumer machines. That changes the impact. Developer machines and CI/CD runners often store powerful tokens that can publish packages, push code, access cloud resources, and read private repositories.

Once those tokens are stolen, attackers can move beyond the original package. They may poison repositories, publish tampered packages, or steal additional secrets from build systems.

Several researchers also linked the behavior to recent Shai-Hulud-style supply chain activity. Public reports describe similar credential theft, repository abuse, and cross-ecosystem propagation patterns involving Python and npm packages.

What the malware tried to steal

• GitHub personal access tokens and repository credentials
• npm publishing tokens
• Cloud credentials for AWS, Google Cloud, Azure, and similar services
• Secrets stored in environment variables
• SSH keys and service account credentials
• Repository data available from the affected machine or CI job
• Authentication data exposed inside build runners

StepSecurity reported that attacks in this family can also target GitHub Actions runner memory by scanning Linux process data. That makes CI/CD exposure especially important for security teams.

For AI teams, the risk is broader than a single workstation. Training jobs, notebooks, containers, internal packages, and automated deployment pipelines may all import the affected package indirectly.

GitHub activity raised further concern

Community reports appeared in the Lightning-AI GitHub repository shortly after the suspicious releases were found. Security researchers and users raised issues warning that version 2.6.3 looked like a supply chain attack.

Socket reported that a warning issue was closed quickly by the pl-ghost account, followed by suspicious behavior in the thread. The company said this suggested a project GitHub account may have been compromised, although the full scope was not confirmed.

Snyk also documented a rapid sequence of GitHub issues, closures, and repository activity during the incident window. These signals added to concern that the attack may have involved more than a simple malicious package upload.

Who is affected

Any environment that installed and imported lightning version 2.6.2 or 2.6.3 should be treated as potentially compromised. This includes local developer systems, CI jobs, Jupyter notebooks, Docker builds, model training servers, and cloud runners.

Installing the package alone may not be the only concern. The highest-risk case is an environment where the package was imported after installation, because public analysis shows the payload executed during import.

Projects that pinned dependencies to 2.6.1 avoided the affected versions. Projects that allowed automatic upgrades or loose version ranges faced higher exposure during the release window.

What developers should do now

• Remove lightning versions 2.6.2 and 2.6.3 from all systems.
• Pin the package to 2.6.1 until maintainers provide further guidance.
• Clear local package caches so compromised wheels cannot be reinstalled accidentally.
• Rotate GitHub, npm, PyPI, cloud, SSH, and service account credentials.
• Review repositories for unauthorized commits, strange files, or suspicious encoded data.
• Audit CI/CD logs for unexpected network connections or child processes.
• Rebuild affected machines, containers, and runners from a known clean state.
• Check whether downstream packages or internal artifacts were built during the exposure window.

The official advisory recommends assuming affected environments may be compromised. That is the right baseline because credential-stealing malware can copy secrets quickly and silently.

Simply uninstalling the package is not enough if secrets were exposed. Teams should rotate credentials first, then rebuild systems and review activity tied to those credentials.

Why package pinning matters

This incident shows why dependency pinning and lockfiles matter. A project that allowed automatic dependency resolution may have pulled the compromised releases soon after they appeared on PyPI.

A lockfile pinned to a known clean version gives teams more control. It prevents sudden upgrades to newly published packages unless the team approves them.

Security teams should also consider cooldown periods for new package releases, especially in production CI/CD environments. A short delay can give scanners and researchers time to detect malicious releases before they reach build systems.

FAQ