# GHSA-gr3r-crp5-qrrm: Compromised tag of intercom-php published via GitHub > A compromised tag in the intercom-php library allowed attackers to harvest cloud credentials and secrets from developer environments. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Not needed - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** No - **Published:** 7 May 2026 ## What is GHSA-gr3r-crp5-qrrm? GHSA-gr3r-crp5-qrrm is a vulnerability in intercom/intercom-php, published on 7 May 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. ### Official description ### Impact On April 30, 2026, a malicious commit was pushed to the intercom/intercom-php repository and tagged as version 5.0.2, using a compromised service account (github-management-service). This occurred as part of the same supply chain attack that affected intercom-client on npm. The malicious version contained a Composer plugin that acted as a dropper, downloading the Bun JavaScript runtime (version 1.3.13) and executing an obfuscated credential-harvesting payload. The payload targeted cloud provider credentials (AWS, GCP, Azure), environment variables, .env files, SSH keys, local configuration files, and CI/CD secrets. The malicious tag was live between approximately 20:53 UTC and 22:37 UTC on April 30, 2026, before being identified and reverted to a clean commit. This compromise is part of the "Mini Shai-Hulud" supply chain campaign tracked by Wiz and Socket. To check if a consuming project is affected, run: `composer show intercom/intercom-php --version`. If the project installed or updated between 20:53 and 22:37 UTC on April 30, it may have received the malicious version. The malicious commit hash was `e69bf4b3`. The clean commit is `9371eba9`. Check `composer.lock` to verify which version the consuming project is using. ### Patches 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. ### Workarounds If a project installed version 5.0.2 during the affected window, treat all credentials accessible from that environment as compromised and rotate them. Clear the Composer cache with `composer clear-cache` and check `composer.lock` for the commit hash to confirm whether you have the malicious or clean version. ### Resources - https://www.intercomstatus.com/us-hosting/incidents/01KQFN6VS6ARP1XBR1K1SBYY59 - https://www.wiz.io/blog/mini-shai-hulud-supply-chain-sap-npm ## Which versions are affected by GHSA-gr3r-crp5-qrrm? 2 open source packages ship an affected version, including intercom/intercom-php. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `intercom/intercom-php` | Packagist | All versions | None | | `intercom/intercom-php` | Packagist | All versions | None | ## How do I fix GHSA-gr3r-crp5-qrrm? No fix has been published for GHSA-gr3r-crp5-qrrm yet. Limit exposure of the affected software until one is available. ## Is GHSA-gr3r-crp5-qrrm being exploited? There is no known exploitation of GHSA-gr3r-crp5-qrrm in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-gr3r-crp5-qrrm and fix it if it is affected. What it is: GHSA-gr3r-crp5-qrrm is a vulnerability in intercom/intercom-php, published on 7 May 2026. An attacker can exploit it over the internet without logging in, with no action from the victim. Exploitation: There is no known exploitation of GHSA-gr3r-crp5-qrrm in the wild and no public exploit code. Affected packages and fixed versions: - intercom/intercom-php (Packagist): affected all versions; no fix listed - intercom/intercom-php (Packagist): affected all versions; no fix listed Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-gr3r-crp5-qrrm/ (Markdown: https://insights.sbomify.com/GHSA-gr3r-crp5-qrrm/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-gr3r-crp5-qrrm --- From sbomify Insights: https://insights.sbomify.com/GHSA-gr3r-crp5-qrrm/ Summaries are generated and may contain mistakes; the official description above is the record.