Malicious Intercom PHP SDK tag drops Bun credential stealer at install time

TL;DR - A compromised service account tagged intercom/[email protected] with a Composer plugin dropper. Install the package during the 104-minute window on 2026-04-30 and it downloads Bun 1.3.13, then runs an obfuscated payload that harvests cloud credentials, SSH keys, .env files, and CI secrets.

What happened

intercom/intercom-php is Intercom's official PHP SDK, distributed via Composer. On 2026-04-30, a compromised service account (github-management-service) pushed a malicious commit to the GitHub repo and tagged it 5.0.2.

The payload had two stages. First, a Composer plugin registered at install time - this is the dropper. It downloaded the Bun JavaScript runtime at version 1.3.13, then executed an obfuscated credential-harvesting script. Targets included cloud provider credentials (AWS, GCP, Azure), environment variables, .env files, SSH keys, local configuration files, and CI/CD secrets.

The malicious tag was live from 20:53 UTC to 22:37 UTC - roughly 104 minutes. The window is short, but CI runners pulling fresh dependencies during that time are fully in scope.

This is the attack shape to plan for: install-time code execution triggered by a Composer plugin hook, combined with broad credential scraping. CI runners are the highest-value blast radius because they typically hold cloud keys, deploy tokens, and registry credentials all in the same job.

Who is impacted

• Any environment that ran composer install or composer update and resolved intercom/intercom-php to version 5.0.2 during the window 2026-04-30 20:53 UTC to 22:37 UTC.
• CI/CD runners and build agents that executed Composer during that window.
• Developer workstations that installed intercom/[email protected] with cloud credentials, SSH keys, or secrets accessible in the environment.

What to do now

• Check whether you pulled the malicious tag. Run composer show intercom/intercom-php --version. Then check composer.lock to confirm which commit hash your install resolved - compare against e69bf4b3.
• Get back to a clean state. Vendor guidance:

  "Version 5.0.1 and all prior versions are unaffected. The 5.0.2 tag has been reverted to a clean commit. Downgrade to 5.0.1 or run composer clear-cache and reinstall to get the clean 5.0.2."

• Treat credentials as compromised if the malicious version ran in any environment - dev or CI.

  "If you installed version 5.0.2 during the affected window, treat all credentials accessible from that environment as compromised and rotate them."

• Hunt for secondary impact across affected environments:
  • Review CI logs for composer install activity during the exposure window.
  • Rotate every secret reachable from the affected job: cloud keys, deploy tokens, CI secrets, SSH keys.
  • Rebuild affected runners from a known-clean image if your incident process requires it.