Concerned about TeamPCP?

See if TeamPCP exposure exists in your runtime, not just your SBOM.

Mini Shai-Hulud Strikes PyTorch Lightning and intercom-client: Inside the Cross-Ecosystem Supply Chain Attack

Kodem Security Research Team
May 1, 2026
May 1, 2026

0 min read

Vulnerabilities
Mini Shai-Hulud Strikes PyTorch Lightning and intercom-client: Inside the Cross-Ecosystem Supply Chain Attack

On April 30, 2026, a cross-ecosystem supply chain attack known as Mini Shai-Hulud simultaneously compromised two major packages. The breach affected PyTorch Lightning on PyPI lightning==2.6.2 and lightning==2.6.3 as well as intercom-client@7.0.4 on npm. These malicious versions trigger automatic code execution on import (Python) and install (npm), enabling widespread credential harvesting across exposed environments.

First disclosed by researchers at Socket and Aikido, the campaign has been linked to TeamPCP due to shared tradecraft, including post-install execution, credential harvesting, and cross-ecosystem propagation patterns.

What Happened: Two Packages, Two Ecosystems, One Campaign

Mini Shai-Hulud is a Shai-Hulud variant that simultaneously compromised PyTorch Lightning on PyPI and intercom-client on npm on April 30, 2026, harvesting GitHub, npm and cloud credentials from any environment that imported or installed the affected versions.

The campaign targeted two widely used packages across separate ecosystems on the same day, using different execution triggers but the same outcome. On the Python side, execution occurs on import. On the Node.js side, execution occurs during installation through lifecycle hooks. In both cases, code executes automatically and exposes credentials available in the runtime environment.

Affected Packages

The lightning project has been quarantined on PyPI following disclosure of malicious activity in versions 2.6.2 and 2.6.3. On the npm side, intercom-client@7.0.4 is the version to remove, with 7.0.3 identified as the last clean release.

Both packages act as execution points into developer machines and CI/CD pipelines. Importing lightning==2.6.2 or 2.6.3, or installing intercom-client@7.0.4, results in automatic execution, credential exposure and downstream access through stolen tokens.

Concerned about TeamPCP? Confirm your exposure in 30 minutes.

How the Attack Chain Executes: From Import to Credential Exfiltration

The malware executes automatically on import lightning==2.6.2, lightning==2.6.3 or install intercom-client@7.0.4, downloads an obfuscated JavaScript payload through the Bun runtime, harvests credentials from the local environment, and uses stolen GitHub tokens to exfiltrate data and propagate across repositories.

Stage 1: Initial Execution

Execution is triggered without user interaction. Importing lightning==2.6.2 or lightning==2.6.3 runs malicious code during module import. Installing intercom-client@7.0.4 triggers execution through the npm lifecycle hook. Both entry points execute in the context of the developer machine or CI runner, inheriting access to environment variables and local credentials.

Stage 2: Payload Delivery

The Python package executes a start.py script that downloads the Bun JavaScript runtime and retrieves an obfuscated payload, router_runtime.js, approximately 11 MB, from a hidden _runtime directory. The payload is then executed through the Bun runtime.

Stage 3: Credential Harvesting

The payload targets the following credentials available in the execution environment:

  • GitHub tokens
  • npm tokens
  • Cloud provider credentials (AWS, GCP, Azure)
  • Kubernetes secrets
  • Vault tokens
  • CI/CD environment variables

Credential access occurs directly from environment variables, configuration files and the runtime context of the process.

Stage 4: Exfiltration and Propagation

Stolen GitHub tokens are validated against api.github.com/user, then used to interact with repositories accessible to the compromised identity. The malware commits a propagation payload to up to 50 branches per writable repository. Commits are authored using the identity claude@users.noreply.github.com.

On the npm side, the propagation chain rewrites local package.json files to insert a malicious postinstall hook, increments the patch version, and repacks the .tgz artifact. This allows subsequent publishes from the compromised environment to distribute the payload downstream.

The Mini Shai-Hulud Connection: Why Variant Naming Matters

Mini Shai-Hulud is a variant of the Shai-Hulud worm that preserves the original credential-driven propagation model while extending execution across both PyPI lightning==2.6.2, lightning==2.6.3 and npm intercom-client@7.0.4 in a single coordinated campaign. This activity has been linked to patterns associated with TeamPCP, though attribution remains inconclusive.

The campaign follows the same core mechanics observed in earlier Shai-Hulud activity. Code executes automatically on import or install, harvests credentials from the local environment, and uses stolen GitHub tokens to modify repositories and propagate through package publishing workflows.

What changes in this variant is where and how execution occurs. The attack chain operates across two ecosystems in the same campaign, using import-time execution in Python and install-time lifecycle hooks in npm. It also interacts directly with developer tooling environments by modifying local .claude/ and .vscode/ directories, extending execution beyond the initial dependency event.

Earlier Shai-Hulud campaigns focused on npm packages and install-time execution paths. This variant expands that model to include PyPI and import-time execution, increasing the number of entry points into developer machines and CI pipelines.

This activity follows the SAP-related npm package compromise observed earlier in the same week, where malicious lifecycle hooks were used to execute code during install and harvest credentials. Together, these incidents show the same propagation model applied across different ecosystems and execution triggers within a single campaign window.

Indicators of Compromise (IOCs) and Behavioral Signals

Identify exposure by checking for the affected versions lightning==2.6.2, lightning==2.6.3, intercom-client@7.0.4 and the indicators below across developer endpoints, CI runners, and repositories. Any environment that imported or installed these versions should be treated as compromised.

Package versions to block

  • lightning==2.6.2
  • lightning==2.6.3
  • intercom-client@7.0.4

File system indicators

  • Hidden _runtime directory inside the lightning package.
  • start.py downloading the Bun runtime.
  • Obfuscated payload router_runtime.js (~11 MB).
  • Unexpected files or modifications under .claude/ or .vscode/
  • Modified package.json files with injected postinstall scripts.
  • Repacked .tgz artifacts in npm working directories.

Network and process indicators

  • Outbound requests fetching the Bun runtime
  • Execution of router_runtime.js via Bun
  • GitHub API calls to api.github.com/user from non-user processes

Git and GitHub indicators

  • Commits authored as claude@users.noreply.github.com
  • Creation of multiple branches across repositories under a single token.
  • Files modified or overwritten without a pull request.
  • Repository activity immediately following install or import events.

Immediate Response: The First-Hour Runbook

Block and remove the affected versions, rotate any credential that may have been exposed, then audit Git history for the impersonation identity. Treat any environment that imported lightning==2.6.2 or lightning==2.6.3, or installed intercom-client@7.0.4, as fully compromised until proven otherwise.

  1. Quarantine the packages: Block lightning==2.6.2, lightning==2.6.3, and intercom-client@7.0.4 in your registry, proxy or mirror.
  2. Downgrade to clean versions: Pin lightning==2.6.1 and intercom-client@7.0.3 and rebuild from a clean state.
  3. Rotate all exposed credentials: Revoke and reissue GitHub tokens, npm tokens, cloud credentials (AWS, GCP, Azure), Kubernetes secrets, Vault tokens and CI/CD environment variables.
  4. Audit Git history: Search for commits authored as claude@users.noreply.github.com across all repositories. Review branches created during the incident window for injected changes.
  5. Inspect developer endpoints and CI runners: Check for .claude/ and .vscode/ directories, _runtime artifacts, and router_runtime.js payloads.
  6. Hold publication: Pause npm and PyPI publishing from any environment that imported or installed the affected versions until inspection and credential rotation are complete.
  7. Clear package caches and artifacts: Remove cached packages and build artifacts to prevent reuse of compromised files.

Why Static SCA Caught the Version Number, Not the Behavior

Static SCA tools flag compromised versions such as lightning==2.6.2, lightning==2.6.3, and intercom-client@7.0.4 only after disclosure because they rely on vulnerability feeds. They don’t detect the underlying behavior executed at import or install, including payload delivery, credential harvesting and GitHub-based exfiltration.

The affected packages appeared as valid releases at publish time, allowing them to pass version-based checks. Importing lightning==2.6.2 or 2.6.3, or installing intercom-client@7.0.4, triggers execution paths that download and run an obfuscated JavaScript payload through the Bun runtime. These behaviors are not visible in dependency metadata and are not evaluated by static analysis.

This model reflects maintainer account compromise rather than a vulnerable dependency. Malicious code is introduced as a legitimate version, which means detection only occurs after the compromised versions are identified and added to a vulnerability feed. Any environment that imported or installed these versions before that point has already executed the attack chain.

Runtime execution exposes signals that static SCA does not observe: outbound requests fetching the Bun runtime, execution of router_runtime.js, access to environment variables containing credentials and GitHub API calls to api.github.com/user. These occur during import or install and require runtime visibility to detect.

Runtime intelligence and behavioral detection focus on these execution patterns rather than version identifiers. Detecting obfuscated payload downloads, credential access and anomalous GitHub activity allows earlier identification of compromise and can interrupt propagation by blocking repository modification attempts using stolen tokens.

Hardening Your Pipeline Against the Next Variant

Assume additional variants will target the same execution paths. Remove the easiest attack surfaces by disabling lifecycle script execution, applying least privilege to tokens and monitoring for the behaviors observed in lightning==2.6.2, lightning==2.6.3 and intercom-client@7.0.4.

  1. Disable lifecycle scripts in CI: Use npm ci --ignore-scripts for pipelines that do not require lifecycle hooks. This removes the execution path used by intercom-client@7.0.4.
  2. Apply least privilege to tokens: Scope GitHub and npm tokens to the minimum required permissions and limit access to specific repositories or packages. Avoid tokens with broad write access.
  3. Pin and lock dependencies: Use lockfiles and integrity hashes to prevent unverified version changes and block resolution to lightning==2.6.2, lightning==2.6.3, and intercom-client@7.0.4.
  4. Monitor outbound traffic from build runners: Alert on unexpected downloads during import or install, including retrieval of the Bun runtime and execution of large obfuscated payloads such as router_runtime.js (~11 MB).
  5. Watch Git history for authorship anomalies: Search for commits authored as claude@users.noreply.github.com and unexpected branch creation following build or install activity.
  6. Inspect developer tooling environments: Monitor .claude/ and .vscode/ directories for unexpected file creation or modification.
  7. Treat developer endpoints as production systems: Apply monitoring and access controls to developer machines. Importing lightning==2.6.2 or 2.6.3, or installing intercom-client@7.0.4, executes with the same credentials available in these environments.

What This Campaign Tells Us About 2026 Supply Chain Risk

Trusted package ecosystems such as PyPI and npm now function as execution layers, not just distribution channels. Importing lightning==2.6.2 or lightning==2.6.3 or installing intercom-client@7.0.4, results in immediate code execution, credential access and repository modification within the same execution chain.

  1. Cross-ecosystem campaigns are operational: The same campaign executed across PyPI and npm on the same day, using import-time execution in Python and install-time execution in Node.js. Compromising lightning==2.6.2, lightning==2.6.3 and intercom-client@7.0.4 created multiple entry points into developer machines and CI/CD pipelines within a single operation.
  2. Credential harvesting and propagation are the dominant pattern: The attack chain extracts GitHub tokens, npm tokens, cloud credentials and CI/CD environment variables, then uses those credentials to modify repositories and propagate through package publishing workflows. Version-level compromise is the entry point. Repository access is the objective.
  3. Developer tooling environments are inside the execution path: The campaign modifies .claude/ and .vscode/ directories, extending execution beyond import or install into environments where code is edited, built and published. These environments hold the credentials required for propagation.

Frequently Asked Questions

What is Mini Shai-Hulud?

Mini Shai-Hulud is a variant of the Shai-Hulud supply chain worm, linked to patterns associated with TeamPCP, though attribution remains inconclusive. It compromised PyTorch Lightning on PyPI lightning==2.6.2, lightning==2.6.3 and intercom-client on npm intercom-client@7.0.4 on April 30, 2026, executing automatically on import or install and propagating through stolen credentials.

Which versions of PyTorch Lightning are compromised?

Versions lightning==2.6.2 and lightning==2.6.3 on PyPI are compromised. Pin to lightning==2.6.1.

Which version of intercom-client is compromised?

Version intercom-client@7.0.4 on npm is compromised. Downgrade to intercom-client@7.0.3.

How do I know if my environment was affected?

Any environment that imported lightning==2.6.2 or lightning==2.6.3 or installed intercom-client@7.0.4, after April 30, 2026 should be treated as exposed. Verify using the indicators of compromise listed above.

What credentials does the malware extract?

The payload extracts GitHub tokens, npm tokens, cloud credentials (AWS, GCP, Azure), Kubernetes secrets, Vault tokens, and CI/CD environment variables available at runtime.

How does Mini Shai-Hulud differ from the original Shai-Hulud?

It preserves the same credential harvesting and propagation model but executes across PyPI and npm in the same campaign. It also introduces import-time execution for Python and modifies developer tooling directories such as .claude/ and .vscode/.

Can SCA tools detect this attack?

SCA tools detect compromised versions such as lightning==2.6.2, lightning==2.6.3, and intercom-client@7.0.4 only after they are added to vulnerability feeds. They do not detect the runtime behavior executed during import or install.

What is the fastest way to stop propagation?

Rotate any exposed GitHub tokens immediately, then audit repositories for commits authored as claude@users.noreply.github.com. Propagation relies on stolen tokens with repository write access.

References

  1. Aikido. Popular PyTorch Lightning Package Compromised by Mini Shai-Hulud. Aikido.
  2. Kodem Security. November 24, 2025. Shai Hulud 2.0: What We Know About the Ongoing NPM Supply Chain Attack. Kodem.
  3. Kodem Security. December 29, 2025. Guess Who's Back: Shai-Hulud 3.0 The Golden Path. Kodem.
  4. Kodem Security. February 23, 2026. SANDWORM_MODE: A New Shai‑Hulud‑Style npm Worm Threatening Developer & AI Toolchain Security. Kodem.
  5. Kodem Security. When the Supply Chain Becomes the Attack Surface: Inside the TeamPCP Campaign. March 31, 2026. Kodem.
  6. Kodem Security. April 30, 2026. The Shai-Hulud Worm Returns: New npm Supply Chain Attack Compromises SAP Packages. Kodem Security.
  7. Lightning-AI. April 30, 2026.2.6.2 and 2.6.3 was compromised, probably shai, pl-ghost may also be compromised? GitHub.
  8. Socket. April 30, 2026. Intercom’s npm Package Compromised in Ongoing Mini Shai-Hulud Worm Attack. Socket.
  9. StepSecurity. April 30, 2026. lightning: Obfuscated JavaScript Credential Stealer Bundled in PyPI Wheel. StepSecurity.
  10. The Hacker News. April 30, 2026. PyTorch Lightning and Intercom-client Hit in Supply Chain Attacks to Steal Credentials. The Hacker News.
Table of contents

Related blogs

shai-hulud worm sap packages thumbnail image

The Shai-Hulud Worm Returns: New npm Supply Chain Attack Compromises SAP Packages

The Shai-Hulud worm targets SAP npm packages via preinstall scripts. See affected packages, IOCs, and detection guidance for this supply chain attack.

April 30, 2026

8

Bitwarden CLI Supply Chain Compromise: Trusted Secrets Tooling Becomes the Entry Point

Bitwarden CLI version 2026.4.0 was compromised after attackers gained access to its release pipeline by hijacking a GitHub Actions workflow. This allowed them to publish a tampered package to npm that executed malicious code during installation. The compromise was part of a broader supply chain attack targeting CI/CD workflows and package distribution systems, with shared infrastructure and techniques observed across multiple incidents linked to Checkmarx tooling.

April 28, 2026

4

The NIST NVD update changes vulnerability management more than most teams realize

NIST’s April 15, 2026 update to NVD operations is easy to summarize and easy to underread. The headline change is familiar by now: NIST will continue listing all CVEs, but it will only immediately enrich a subset, prioritizing CISA KEV, software used within the federal government, and software covered by Executive Order 14028’s critical software definition.

April 23, 2026

7

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo

A Primer on Runtime Intelligence

See how Kodem's cutting-edge sensor technology revolutionizes application monitoring at the kernel level.

5.1k
Applications covered
1.1m
False positives eliminated
4.8k
Triage hours reduced

Platform Overview Video

Watch our short platform overview video to see how Kodem discovers real security risks in your code at runtime.

5.1k
Applications covered
1.1m
False positives eliminated
4.8k
Triage hours reduced

The State of the Application Security Workflow

This report aims to equip readers with actionable insights that can help future-proof their security programs. Kodem, the publisher of this report, purpose built a platform that bridges these gaps by unifying shift-left strategies with runtime monitoring and protection.

Get real-time insights across the full stack…code, containers, OS, and memory

Watch how Kodem’s runtime security platform detects and blocks attacks before they cause damage. No guesswork. Just precise, automated protection.

Combined author
Kodem Security Research Team
Publish date

0 min read

Vulnerabilities