VULNpocalypse
CriticalSupply chainPatch available

PyTorch Lightning 2.6.2 and 2.6.3 on PyPI ran a Bun-based credential stealer on import; intercom-client 7.0.4 followed

lightning 2.6.2 and 2.6.3 on PyPI stole credentials on import and spread via GitHub and npm. Check installs, rotate secrets, use 2.6.1 or 2.6.4+.

Published
Updated
Fixed in
lightning 2.6.1 (last clean) or 2.6.4 and later; intercom-client 7.0.3; intercom-php not stated
Exploitation
Yes. lightning 2.6.2 and 2.6.3 were installable for 42 minutes on 30 April 2026; Intercom was infected through them

Live scores

CVE-2026-44484
EPSS
0.004
low predicted chance of attack
VEDAS
0.048
little exploit evidence
On CISA KEV
Not listed
Detection rule
None yet

What happened

On 30 April 2026, tampered lightning 2.6.2 and 2.6.3 wheels were installable from PyPI between 12:45:20 and 13:27:30 UTC, about 42 minutes (Lightning AI). The maintainers say the attacker had captured PyPI publishing credentials, cloned the open-source code, added a payload and uploaded the builds directly. They found no evidence the GitHub repository was compromised. How the credentials were captured is not stated.

Snyk found that the release workflow published with a long-lived PyPI token and no Trusted Publisher, and that no 2.6.3 tag exists on GitHub. It infers a direct upload with that token, but marks this as unconfirmed (Snyk).

Which package. The Lightning blog and Snyk name the lightning package and say the legacy pytorch-lightning package was not affected. The GitHub advisory GHSA-w37p-236h-pfx3 and CVE-2026-44484 are filed under pytorch-lightning (GitHub advisory). Check both names.

Downstream: Intercom. Intercom traced its own compromise to a local install of pyannote-audio, which pulled in the bad Lightning as a transitive dependency (The Hacker News). The same day, intercom-client@7.0.4 was published to npm from a compromised developer account, outside Intercom’s build pipeline. It ran a credential stealer from a preinstall hook and was live for about two hours, 15:00 to 17:00 UTC (GHSA-54pg-9963-v8vg). The Packagist package intercom/intercom-php 5.0.2 was also compromised. It ran setup-intercom.sh from Composer’s post-install-cmd and post-update-cmd events (The Hacker News).

Attribution. The payload reuses the Bun version and cipher of the Mini Shai-Hulud npm wave from the day before. Wiz and Aikido tie it to that campaign. The Hacker News reports that Socket links it to TeamPCP, while Snyk reports Socket assessing a distinct actor with a similar playbook. Attribution is not settled (Snyk; The Hacker News). See our Shai-Hulud advisory and TeamPCP advisory.

How the payload works

Details from Snyk unless stated:

  1. The wheel keeps the real library and adds a hidden _runtime directory with start.py and an 11 MB obfuscated router_runtime.js.
  2. __init__.py starts a daemon thread on import lightning. No install hook is needed. The thread runs start.py, which downloads Bun v1.3.13 from the official oven-sh/bun GitHub releases and runs router_runtime.js.
  3. The stealer looks for GitHub, npm and GitHub App tokens, queries the AWS instance and ECS metadata endpoints and Google’s tokeninfo endpoint, and validates tokens against api.github.com/user and registry.npmjs.org/-/whoami. Lightning AI adds AWS, GCP and Azure credentials, Chrome, Firefox and Brave stored credentials, and .env files (Lightning AI).
  4. Data goes to zero.masscan[.]cloud:443/v1/telemetry. If that fails, it creates a public repository with the description “A Mini Shai-Hulud has Appeared” using a stolen GitHub token (The Hacker News).
  5. GitHub spread: through the GraphQL createCommitOnBranch mutation it commits to repositories the token can write, as claude <claude@users.noreply.github.com>, adding .claude/router_runtime.js, .claude/settings.json, .claude/setup.mjs, .vscode/tasks.json, .vscode/setup.mjs and .github/workflows/format-check.yml. The Hacker News reports up to 50 branches per repository.
  6. npm spread: it modifies local npm tarballs, injects setup.mjs, bumps the patch version, and publishes with a direct HTTP PUT to the registry.

Am I affected?

bash
# Installed versions of both package names
pip show lightning pytorch-lightning 2>/dev/null | grep -E '^(Name|Version)'

# The payload directory in any environment on this machine
find / -path '*site-packages/lightning/_runtime*' \( -name start.py -o -name router_runtime.js \) 2>/dev/null

# Pins in requirements and lockfiles
grep -rnE '^(py(torch-)?)?lightning(\[[^]]*\])?==2\.6\.[23]' --include='requirements*.txt' .
grep -nE -A1 'name = "(lightning|pytorch-lightning)"' poetry.lock uv.lock 2>/dev/null | grep -E '"2\.6\.[23]"'

# npm: intercom-client 7.0.4
npm ls intercom-client --all 2>/dev/null | grep 7.0.4
grep -nE 'intercom-client' package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# PHP: intercom-php 5.0.2
grep -n -A2 '"name": "intercom/intercom-php"' composer.lock 2>/dev/null | grep '"5.0.2"'

Hash any _runtime files you find. Known SHA-256 values (Lightning AI):

  • router_runtime.js: 5f5852b5f604369945118937b058e49064612ac69826e0adadca39a357dfb5b1
  • start.py: 8046a11187c135da6959862ff3846e99ad15462d2ec8a2f77a30ad53ebd5dcf2
  • lightning 2.6.3 wheel: 56070a9d8de0c0ffb1ec5c309953cf4679432df5a78df9aeb020fbb73d2be9fb (Snyk)

Then check GitHub for the worm’s traces:

bash
# Commits by the spoofed identity in a repository
git log --all --author='claude@users.noreply.github.com' --format='%h %ad %s' --date=iso

# Files the worm adds
git log --all --format='%h %s' -- .claude/router_runtime.js .claude/setup.mjs .vscode/setup.mjs .github/workflows/format-check.yml

# Dead-drop repositories created in your account
gh repo list YOUR_USER --limit 1000 --json name,description \
  --jq '.[] | select((.description // "") | test("Mini Shai-Hulud")) | .name'

Snyk also lists commit messages prefixed OhNoWhatsGoingOnWithGitHub:. In network logs, look for zero.masscan.cloud, unexpected Bun downloads from github.com/oven-sh/bun/releases/download/bun-v1.3.13/, and metadata-service calls from Python processes.

What to do now

  1. Pin a clean version. The maintainers named lightning==2.6.1 as safe and retired 2.6.2 and 2.6.3 (Lightning AI). They released 2.6.4 on 20 May 2026, and PyPI lists 2.6.6 as the latest (PyPI). For npm, downgrade to intercom-client@7.0.3. As of 2 November 2026, 7.0.4 is gone from the registry and 7.0.3 is latest (npm; GHSA-54pg-9963-v8vg). No clean intercom-php version is named in the sources we checked.
  2. Rotate from another machine. Cloud credentials (AWS, GCP, Azure), GitHub and npm tokens, SSH keys, browser-stored passwords, and every secret in .env files and environment variables of affected hosts and CI jobs (Lightning AI).
  3. Clean your repositories. Revert commits by the spoofed claude identity, delete unexpected branches, and remove the .claude/, .vscode/ and format-check.yml files listed above. Delete any “A Mini Shai-Hulud has Appeared” repositories after saving them for investigation.
  4. Audit npm publishes from any machine that imported the bad Lightning with npm credentials present. Unpublish any patch release you did not make.
  5. Look for transitive installs. Intercom got it through pyannote-audio. Search lockfiles, not just direct requirements.
  6. Publish with Trusted Publishing. The way in was a stored PyPI token. Move your own projects to OIDC Trusted Publishing and drop long-lived upload tokens.

Sources