Skip to content

intercom-client npm compromise and install-hook credential theft (GHSA-4594-wxqv-j3pm / GHSA-54pg-9963-v8vg)

Signal: GitHub Security Advisories now has two records for the intercom-client npm compromise. The original malware advisory GHSA-4594-wxqv-j3pm flagged intercom-client 7.0.4 as embedded malicious code. The newer repository advisory GHSA-54pg-9963-v8vg adds incident details: the version was published with credentials from a compromised developer account, was not produced by Intercom's build pipeline, ran an obfuscated JavaScript payload through a preinstall hook, and exfiltrated environment and credential material to attacker-controlled GitHub repositories.

Advisories covered

  • Malware in intercom-client — GHSA-4594-wxqv-j3pm: npm package intercom-client version 7.0.4 contains embedded malicious code. GitHub's advisory language says any computer with the package installed or running should be considered fully compromised.
  • Compromised version of intercom-client published to npm — GHSA-54pg-9963-v8vg: version 7.0.4 was published on April 30, 2026 with compromised developer credentials, was live for roughly two hours (15:00-17:00 UTC), executed via npm preinstall, harvested cloud credentials, environment variables, .env files, GitHub/npm tokens, SSH keys, local config files, and metadata-service credentials, and is linked to the Mini Shai-Hulud supply-chain campaign reported by Wiz and Socket.

Why this is durable

This is not just a bad package version. It is a package-manager execution boundary failure: trusted package identity, developer account authority, lifecycle hooks, local credentials, and CI secrets all collapsed into one install-time execution path. The important lesson is to treat dependency installation as code execution and package provenance as a runtime control, not as a static inventory detail.

Triage

  1. Search lockfiles, SBOMs, package manifests, artifact metadata, dependency caches, and generated images for intercom-client@7.0.4.
  2. Run npm list intercom-client in projects that may have resolved the package, then confirm lockfiles for transitive or cached pulls.
  3. Prioritize installs between 2026-04-30 15:00-17:00 UTC, but do not rely only on that window if internal mirrors, caches, or build images could have preserved the version.
  4. Treat developer workstations, CI runners, build containers, package-publishing hosts, and deployment jobs as in scope if they installed the package or reused an affected cache.
  5. Preserve evidence before cleanup: lockfile entries, npm cache paths, CI job logs, shell history, process listings, environment snapshots where available, network telemetry, and any artifacts built from the affected dependency graph.
  6. Identify credentials reachable by affected hosts: npm tokens, GitHub tokens, cloud keys, SSH keys, CI secrets, signing keys, deployment credentials, Intercom/API credentials, .env files, local config files, and metadata-service roles.

Mitigation

  • Remove intercom-client@7.0.4 from manifests, lockfiles, internal mirrors, dependency caches, and build images.
  • Downgrade/pin to 7.0.3 or another known-good version only after verifying source provenance and maintainer trust.
  • Rebuild affected artifacts from clean hosts and clean dependency caches.
  • Rotate all secrets that were present on impacted systems, from a trusted machine that did not install the package.
  • Revoke and reissue package-registry tokens, GitHub tokens, cloud credentials, deploy keys, signing material, and CI/deploy credentials; prefer short-lived OIDC-backed credentials going forward.
  • Quarantine or rebuild affected CI runners and developer environments instead of assuming package removal is sufficient.

Detection ideas

  • Query package-manager logs and artifact SBOMs for intercom-client exactly at version 7.0.4.
  • Hunt for npm lifecycle-script execution, especially preinstall, during install/build windows.
  • Review outbound traffic from build jobs for unexpected GitHub repository writes, unusual GitHub API activity, or other exfiltration-like behavior during and immediately after installs.
  • Check for unauthorized package publishes, repository pushes, workflow changes, secret reads, cloud API calls, new access tokens, and metadata-service credential use after the first affected install time.
  • Compare generated build artifacts against a clean rebuild to catch tampering that survived dependency removal.

Durable controls

  • Treat package installation as untrusted code execution: run it in ephemeral builders with minimal network egress, no long-lived secrets, read-only source inputs where possible, and per-job teardown.
  • Disable or gate lifecycle scripts for high-risk dependency installation paths; allow only reviewed scripts for production builds.
  • Enforce dependency-firewall rules for known-malicious exact versions and purge them from mirrors and caches.
  • Require provenance checks that tie package contents to trusted commits, protected tags, maintainer identity, and expected build pipelines.
  • Scope package-registry and source-control tokens so compromise of one developer or runner cannot publish broadly or read unrelated secrets.

Durable lesson

Malicious package advisories are incident-response events, not ordinary upgrade tickets. Assume exposed hosts and secrets are compromised, preserve enough evidence to understand blast radius, and rebuild from clean trust roots before returning the dependency path to service.