A Backdoored PyTorch Lightning Just Tried to Worm From PyPI Into npm and Steal Every Cloud Credential It Could Find. Here's the 30-Minute Audit.

On April 30, attackers published lightning versions 2.6.2 and 2.6.3 to PyPI. The package is the Python deep-learning framework with hundreds of thousands of daily downloads. The two malicious versions contained a hidden _runtime directory holding an obfuscated JavaScript payload that runs the moment the module is imported. It steals credentials and cloud secrets out of the environment. If it finds an npm publish token sitting on the same machine, it injects a setup.mjs dropper plus a router_runtime.js file into every package that token can publish to, sets scripts.preinstall to execute the dropper, bumps the patch version, and republishes.

Socket flagged the package 18 minutes after publication. The Lightning maintainers had it pulled and patched 42 minutes after that. The incident response was actually textbook — but the threat model isn't, and the threat model is the part you should pay attention to.

If you've run any project that pip-installs an AI dependency in the last week, the right answer to "did this affect me" is to actually go check, not to assume. Here's what I ran on my own boxes this morning.

This is a cross-ecosystem worm, and that's the part nobody is reading correctly

Most coverage is filing this under "another supply chain attack." Technically true and structurally wrong. The interesting thing about this attack is that the malicious payload arrives via PyPI — that's Python — but the propagation logic runs through npm — that's JavaScript. The attacker is using Python AI packages as an entry vector to attack the npm ecosystem, where the worm then poisons the JavaScript packages a solo operator might actually depend on.

That changes the risk model in a specific way. "I don't write Python" doesn't save you. If your Python-developer friend ran pip install lightning on a machine that also has an ~/.npmrc with a publish token — because they also maintain a small JavaScript library on the side, which is increasingly common — the worm has now corrupted the npm side from the Python side. Their npm package is now malicious. You install their npm package. You're in the chain.

This is the new shape. The "Shai-Hulud" cluster that's been hitting npm since September is now showing up as PyPI-launched. Expect more of this pattern, not less. The package registries that solo operators rely on are no longer one ecosystem at a time — they're a unified attack surface from the attacker's point of view, even though they still feel like separate worlds from the developer's point of view.

The 30-minute audit, in five steps

In order, with the actual commands:

Step 1: Check whether lightning 2.6.2 or 2.6.3 is in any project's lockfile.

grep -r "lightning==2.6.[23]" .

Run this across every active project, every Docker image you've built since April 30, and every cached virtualenv. The Docker case is the one that gets people — a CI pipeline that pip-installed the bad version into a base image, which then sits in your registry, is exactly the silent compromise this attack class is designed for.

Step 2: Check for the _runtime/ directory under any installed lightning/ package.

find ~ -path "*/lightning/_runtime" -type d 2>/dev/null

If anything turns up, that environment is compromised. The directory is the artifact the malicious payload extracts to before executing. Nuke the environment, don't just pip uninstall.

Step 3: Audit ~/.npmrc for tokens, and rotate any that may have been present on a machine that ran a Python script in the affected window.

This is the cross-ecosystem catch. Even if you don't actively publish npm packages from this machine, your ~/.npmrc may contain a token left over from a long-forgotten project. Rotate it. The cost is 30 seconds. The cost of not rotating is "your one-person company gets used as a redistribution node for a worm."

Step 4: Audit ~/.aws/credentials, ~/.config/gcloud, ~/.docker/config.json, and .env files for suspicious access patterns since April 30.

CloudTrail, Cloud Audit Logs, and any cloud provider's "recent activity" feed are your friends here. Look specifically for API calls from IPs you don't recognize, principals that aren't in your usual workflow, and read access to S3 buckets or GCS objects that nobody on your team touches normally. Most people skip this step because it's tedious. The people who skip it are the ones who get a credit-card-charged-up-to-the-limit surprise three weeks later.

Step 5: If you publish your own npm packages, check the last week of versions for unexpected patch bumps with preinstall scripts you didn't write.

npm view your-package versions --json | tail -10

Then check the most recent versions for scripts.preinstall entries. The malware's signature is a patch bump you didn't make, with a preinstall hook that's there to extract and run the dropper. If you find one, unpublish, rotate the token, and post a security advisory on your repo.

The whole audit takes about 30 minutes if you find nothing, and a couple of hours if you find something. Worth doing now, this morning, before the weekend.

Why solo operators are over-exposed to this specific attack class

The indie pattern is "one machine that has everything." Your ~/.aws credentials, your ~/.npmrc publish token, your GitHub PAT, your Cloudflare token, your Stripe keys, your Anthropic API key — all sitting next to each other on a personal laptop that also runs pip install for hobby AI projects, also runs npm install for whatever side project you started last Sunday, also runs bun install for the experiment from two weekends ago.

The blast radius of that pattern is enormous. The "I'll separate concerns later" voice in your head has been wrong every single time it's promised it. The right move this weekend is not to migrate to a hardware-isolated build machine, because you won't actually do that. The right move is to audit and rotate. Assume any token that was present on a machine that imported lightning between April 30 and the time you read this is compromised, and rotate it on principle. The rotation takes longer than the assessment of whether you "actually" need to rotate, and the rotation is the only action with a real risk-reduction payoff.

Why this attack worked: tutorials are a vulnerability surface

The structural takeaway about AI dependencies specifically is that AI/ML packages have a different risk profile than ordinary Python packages because they get pulled in transitively by tools and tutorials at a higher rate than other categories. If a popular tutorial says "pip install lightning" and a hundred thousand indie devs run that command on a Tuesday morning, the attacker only needs to be malicious for 18 minutes before Socket flags it to get hundreds of compromised machines. That's the entire economic model of this attack class.

PyPI's two-factor publish requirement and mandatory provenance attestations are the structural fixes. "Be careful what you install" is not a fix — it's a shrug. The Lightning maintainers' 42-minute response time was excellent, and it would not have mattered if a single popular tutorial had its install instructions copied into a thousand other tutorials, which is exactly what happens with AI packages.

The maintainers are doing their job. PyPI is shipping the security primitives. The thing solo operators can do this weekend is enable hardware key MFA on their own PyPI and npm accounts, so that your package doesn't become the next attack vector when someone inevitably phishes the credentials you've been using since 2019.

The running 17-day pattern this is the latest entry in

The infrastructure security thread on this blog has been getting longer. April 21: LMDeploy SSRF. April 26: Bitwarden npm package compromise. April 28: LeRobot pickle RCE plus GitHub CVE-2026-3854. April 30: cPanel zero-day, Linux kernel local privilege escalation, CanisterWorm npm worm, and now PyTorch Lightning. May 4: MOVEit Automation auth bypass. May 6: the 1 million exposed AI services scan with 175,000 unauthenticated Ollama servers.

That's nine distinct security wedges in 17 days, all hitting infrastructure that solo operators specifically over-index on. The honest meta-takeaway is that 2026 is structurally a "rotate your tokens monthly" year whether you wanted it to be or not. The "spin it up and forget" pattern is dead. Active maintenance is the new operational baseline for self-hosted, self-published, self-anything infrastructure.

This isn't a panic-migrate-everything-to-managed-services argument. It's an honest accounting of what indie operations now require. The cost of doing the audit is 30 minutes. The cost of not doing it is unbounded.

Should you keep using Lightning at all?

Yes. The maintainers fixed the issue in 42 minutes. The Lightning AI team's incident response was the model — flag, pull, patch, post-mortem, ship the lessons learned. The package isn't the problem. The threat model that lets a single compromised account propagate across ecosystems is the problem, and that threat model exists for every package on every registry, not just Lightning.

If the maintainers had had hardware-key-required publishing on, this attack does not happen. That's the structural fix. Your indie equivalent is to enable hardware key MFA on your own PyPI and npm accounts today, while you still have the energy generated by reading this story. The energy fades in a couple of hours. The protection lasts until you change accounts.

What to do right now

Three things, in order. First, run the grep -r "lightning==2.6.[23]" check across every project directory you have. Second, if anything turns up, treat it as a real compromise — nuke the environment, audit the credential files, check cloud provider activity logs. Third, regardless of whether you found anything, enable hardware key MFA on PyPI and npm before the weekend ends. The first two take 30 minutes if you're clean. The third takes 10 minutes once you have a YubiKey. If you don't have one, a $50 YubiKey 5C NFC is the cheapest and best investment you can make in your own infrastructure security this year.

The point isn't this specific attack. The point is that "this specific attack" is now happening every week. Your 2026 operational posture has to assume the next one is already in flight.

Sources

• Semgrep — Shai-Hulud Themed Malware in PyTorch Lightning
• The Hacker News — PyTorch Lightning and Intercom-client Hit in Supply Chain Attacks
• Socket — lightning PyPI Package Compromised in Supply Chain Attack
• BleepingComputer — Backdoored PyTorch Lightning package drops credential stealer
• Lightning AI — How the community discovered and fixed it in 42 minutes
• SecurityAffairs — Malicious PyTorch Lightning update hits AI supply chain security