PyTorch Lightning Compromised With Two Malicious Package Versions Published

May 01, 2026
By Sonatype Research Team

Note: This blog was initially published at 8:40pm ET on April 30. It was updated at 6:54pm ET on May 1 to include additional packages.

TL;DR

• Two malicious versions of the popular PyTorch Lightning package have been uploaded to PyPI following the publisher account’s compromise.
• Lightning versions 2.6.2 and 2.6.3 (tracked as sonatype-2026-002817) were published on April 30, 2026, containing embedded malicious code that gathers developer credentials and publishes infected package versions.
• If downloaded, these malicious versions have likely already done their damage — if you are unsure, verify that your build processes are using version 2.6.1.

The widely used pytorch-lightning package has been hijacked by malicious actors, resulting in two malicious versions (2.6.2 and 2.6.3) publishing on the PyPI registry on April 30, 2026. The packages are designed to steal developer credentials and republish malicious versions of the repositories to which stolen tokens have access.

This is yet another escalation in a series of self-propagating open source malware attacks that are designed to steal credentials, spread rapidly, and overwhelm open source repositories.

What Happened

On April 30, 2026, two back-to-back releases of the lightning package were published to PyPI:

• lightning 2.6.2
• lightning 2.6.3 (published just 13 minutes later)

The project's maintainers released an advisory detailing the incident. Both versions were uploaded by the same publisher and researchers believe are part of a coordinated attack. Despite minimal differences between the releases, both contained the same malicious payload.

Critically, version 2.6.3 was not a fix. It retained the full malicious functionality while slightly modifying metadata and loader behavior to evade detection. The attack also spread to hijack the npm package intercom-client 7.0.4, as well as intercom and intercom-php on Composer.

Technical Analysis: How the Attack Works

The attack is triggered automatically when the package is imported:

• A modified init.py file launches a background process.
• The process executes silently with no visible output.
• Users receive no indication of compromise.

This means simply importing the package is enough to activate the malware.

Obfuscated Multi-Cloud Credential Harvester

The package includes a large (11 MB) obfuscated JavaScript file that uses heavy hex-encoded variable obfuscation to evade static analysis and executes via a bundled runtime loader.

The payload targets a wide range of services, including:

• AWS (IMDS, STS, Secrets Manager).
• Azure (AD, Key Vault, Service Fabric).
• Google Cloud (OAuth, metadata services, KMS).
• GitHub APIs.
• Local environment variables and credential files.

The intent is to harvest credentials across multi-cloud and developer environments.

Secondary Payload Execution

The package includes a Python bootstrapper that downloads a runtime (Bun) from GitHub if not present, executes the malicious JavaScript payload, and runs in the background without blocking execution.

Additionally, the malware attempts to download and execute a second-stage payload from attacker-controlled infrastructure, increasing the potential impact.

Why This Attack Matters

Compromised Package, Not a Fake

Unlike traditional typosquatting attacks, this incident involves a compromised version of a legitimate, widely used package.

This makes it significantly more dangerous because:

• Developers trust the package name.
• Automated systems may allow it by default.
• Detection relies on behavioral analysis, not naming anomalies.

Rapid Republish to Evade Detection.

One of the most important findings from is how quickly attackers iterated. Version 2.6.2 was flagged as suspicious, yet just minutes later, version 2.6.3 was published with the same malicious payload in an attempt to evade detection.

This highlights a critical tactic of rapidly republishing near-identical versions to bypass security controls that evaluate releases in isolation.

Signal Evasion Through Minimal Changes

Attackers made subtle changes between versions, including slight modifications to loader scripts, minor metadata updates, and no meaningful differences in the underlying payload.

These small changes were enough to avoid triggering certain detection signals, underscoring the need for:

• Cross-version correlation.
• Payload reuse detection.
• Behavioral analysis over static heuristics.

What to Do if You've Been Compromised

Organizations that installed or used these versions should treat affected systems as compromised.

The malicious package is designed to steal credentials and may have already downloaded additional payloads, meaning sensitive data could be exposed and further malicious activity may already be underway.

How to Stay Ahead of This Threat Class

The PyTorch Lightning incident shows how quickly attackers can exploit trust in open source ecosystems. As pipelines become more automated, the window between compromise and impact continues to shrink.

This incident reinforces several best practices:

• Pin dependencies to known-good versions and verify package integrity before use.
• Monitor for behavioral anomalies such as unexpected subprocess execution, network calls during import, and large or obfuscated embedded files.
• Detect cross-version threats by flagging rapid successive releases from the same publisher and identifying reused payloads across versions.
• Use automated supply chain security tools to continuously monitor dependencies, enforce policies, and detect malicious packages early.

Security teams need to move beyond static checks toward context-aware, behavior-driven analysis, and give developers better visibility into dependency risk before code is ever used. In practice, that means surfacing signals like unusual runtime behavior, rapid releases, or payload reuse early in the decision process.

Tools like Sonatype Guide help provide that context, enabling teams to avoid high-risk components before they enter the build.

Sonatype will continue to monitor this situation and provide updates as more information becomes available.

Written by Sonatype Research Team
Sonatype's Research Team is focused on bringing real-time, in-depth intelligence and actionable information about open source and third party vulnerabilities to Sonatype customers.

Tags

pythonPyPIpypi vulnerabilityMalware AnalysisMalwareopen source malware