Compromised intercom-client 7.0.4 exfiltrates Kubernetes and Vault secrets

TL;DR - [email protected] shipped with a malicious preinstall hook that fires the moment you run npm install. It downloads and executes an unverified Bun binary, then hunts for Kubernetes credentials, Vault tokens, and GitHub secrets and exfiltrates them via the GitHub API. You don't need to import the library for the payload to run.

What happened

intercom-client is Intercom's official Node.js SDK, used in backend services and automation to talk to the Intercom API. Socket discovered that 7.0.4 contained two files absent from 7.0.3: setup.mjs and router_runtime.js.

The attack triggers at install time. The package's preinstall hook executes setup.mjs, which fetches and runs an unverified Bun binary from GitHub with no integrity checks. That binary loads router_runtime.js - a roughly 11.7 MB heavily obfuscated script. Its job: collect Kubernetes and Vault credentials from environment variables and local files, encrypt them, and ship them out via the GitHub API.

The publish path was compromised too. Socket attributes the malicious release to a hijacked GitHub user account (nhur) and manipulation of the CI publish workflow. The workflow changes introduced suspicious GitHub Actions modifications designed to serialise secrets - for example via ${{ toJSON(secrets) }} - and upload them as build artifacts.

This is the pattern supply-chain attackers have settled on: target the environments where secrets actually live. CI runners and build images hold Kubernetes configs, Vault tokens, and GitHub credentials. Install-time hooks reach all of that before a single line of application code runs.

Who is impacted

• Any developer workstation, build runner, or CI/CD environment that installed [email protected]. Exposure happens at install, not at import.
• Highest-risk targets are environments with high-value credentials present during install: Kubernetes credentials, Vault tokens, cloud credentials, and GitHub tokens.
• Socket notes the package had roughly 360,000 weekly downloads and more than 100 dependents - enough scale for significant CI and production-adjacent blast radius.

What to do now

Socket's remediation guidance:

"Remove [email protected], downgrade to a known-good version, rotate potentially exposed credentials, and review systems where the package may have been installed."

• Find every install of 7.0.4: search package.json files, lockfiles, and build logs for [email protected] across developer endpoints, ephemeral CI runners, and shared build images.
• Rotate all secrets that were accessible during affected installs:
  • Kubernetes credentials
  • Vault tokens
  • GitHub credentials and tokens
  • Any cloud credentials present in the install environment
• Audit your GitHub Actions workflows for unexpected recent changes under .github/workflows/, particularly any additions that serialise secrets (e.g. toJSON(secrets)) or upload unexpected build artifacts.
• Treat any host that ran the install as potentially compromised until you can confirm otherwise. Don't limit your rotation to secrets you know were present - assume the worst and scope down from there.

Additional Information

Indicators of compromise

Socket also lists cloud metadata endpoints as network indicators worth hunting for in telemetry (marked "Do Not Block" in the original report - flag them for alerting, not blocking).

Why this matters for AppSec

Install-time hooks are a blind spot for most teams. You review imported code. You don't always review what runs during npm install. This incident makes the case for enforcing --ignore-scripts in CI where possible, using lockfile integrity checking, and running dependency installs in sandboxed environments without access to production credentials. If your CI runner has a kubeconfig and a Vault token and can reach the internet, a malicious preinstall script can empty your credential store before your application ever boots.