GHSA-GR3R-CRP5-QRRM: Supply Chain Compromise in intercom-php via Malicious Composer Plugin

The vulnerability tracked as GHSA-GR3R-CRP5-QRRM represents a direct supply chain compromise of the intercom/intercom-php package, a widely utilized PHP binding for the Intercom API. Threat actors successfully gained unauthorized access to the repository's publishing pipeline and released a malicious version tagged as 5.0.2. This attack is attributed to the "Mini Shai-Hulud" campaign operated by the TeamPCP group.

The attack vector leverages the Packagist ecosystem's integration with GitHub for version tagging. The threat actors pushed the 5.0.2 tag containing an altered composer.json file. This file reconfigured the package type from a standard library to a Composer plugin. The modified package metadata instructed the Composer package manager to execute untrusted PHP code automatically upon installation or update.

This incident is classified under CWE-506 (Embedded Malicious Code) and CWE-912 (Supply Chain Compromise). The malware targets the developer environment or the Continuous Integration/Continuous Deployment (CI/CD) pipeline running the Composer process. The primary objective of the embedded payload is the immediate exfiltration of sensitive configuration files and environment variables to an external infrastructure.

The compromise of intercom-php occurred simultaneously with a similar attack against the intercom-client npm package (version 7.0.4). This cross-ecosystem strategy indicates a coordinated effort to target environments utilizing Intercom developer tools, maximizing the probability of successful credential harvesting across diverse technology stacks.

The root cause of this vulnerability lies in the compromise of maintainer credentials combined with the inherent execution privileges granted to Composer plugins. Attackers obtained sufficient authorization to push signed tags to the official GitHub repository, which Packagist automatically synchronized and published to the broader PHP ecosystem.

Composer plugins are a deliberate feature of the PHP package manager designed to extend its core functionality. When a package is defined with "type": "composer-plugin" in its composer.json file, Composer loads and executes the plugin's code within its own runtime during the lifecycle events, such as init, pre-install-cmd, and post-install-cmd. This design assumes explicit trust between the developer and the package maintainer.

The threat actors exploited this trust model by embedding malicious logic within the plugin initialization class. Because Composer operations frequently run with the privileges of the developer user or the CI/CD service account, the executing malware inherits extensive access to the local filesystem and the host's environment variables. The system lacks native sandboxing or permission boundaries for executing plugins.

Once the authentication boundary was breached, the technical mechanism relied entirely on the abuse of intended functionality. The system functioned exactly as designed, prioritizing automated extensibility over execution restrictions. This lack of runtime isolation for dependency lifecycle hooks remains a systemic weakness in modern package managers.

The attack mechanics center on the structural modification of the composer.json file introduced in the malicious 5.0.2 tag. A standard PHP library configuration was replaced with a plugin configuration requiring automatic initialization. Below is an illustrative comparison of the metadata structure.

// Standard Package Configuration
{
    "name": "intercom/intercom-php",
    "type": "library",
    "autoload": {
        "psr-4": { "Intercom\\": "src/" }
    }
}
 
// Malicious Plugin Configuration
{
    "name": "intercom/intercom-php",
    "type": "composer-plugin",
    "extra": {
        "class": "Intercom\\Plugin\\MaliciousInit"
    },
    "autoload": {
        "psr-4": { "Intercom\\": "src/" }
    }
}

The extra.class directive instructs Composer to instantiate the specified PHP class immediately upon loading the package. The malicious class implements the Composer\Plugin\PluginInterface and utilizes the activate method to execute its primary payload before the developer or build system interacts with the codebase.

The payload executes a targeted search across the host filesystem for high-value configuration files. It systematically reads files such as .env, .aws/credentials, and .kube/config. It also captures the runtime environment using the PHP getenv() function. The collected data is concatenated, encoded, and transmitted via an HTTP POST request to a remote command-and-control server operated by TeamPCP.

Because the malicious code is invoked during the resolution and installation phase, the exfiltration occurs prior to any application-level testing or runtime execution. The developer only needs to issue a standard command like composer require intercom/intercom-php or composer update to trigger the complete execution chain.

The exploitation flow requires no direct interaction beyond the routine management of application dependencies. The process begins when an automated system or a developer resolves the package graph for a project depending on intercom/intercom-php. If the constraints allow for version 5.0.2, Composer retrieves the artifact from Packagist.

During the extraction phase, the Composer runtime parses the composer.json file and identifies the package as a plugin. It loads the autoloader and invokes the plugin's entry point. This phase happens synchronously within the console session, often delaying the output of the terminal slightly while the HTTP request to the C2 server completes.

The attack completes its primary objective in seconds. The exfiltrated payload typically contains AWS Access Keys, database connection strings, GitHub Personal Access Tokens, and internal API keys. These credentials are subsequently weaponized by the threat actors for secondary intrusions, privilege escalation within cloud environments, or further supply chain compromises.

This vector bypasses traditional perimeter defenses because the outbound network connection originates from a trusted host (a developer workstation or an established CI runner) and utilizes standard web protocols (HTTPS). Security controls focusing solely on incoming traffic or application-layer vulnerabilities provide no visibility into this execution path.

The impact of installing version 5.0.2 of intercom-php is an immediate and total compromise of confidentiality for the affected environment. The malicious plugin achieves arbitrary code execution with the permissions of the user running the Composer process. In CI/CD environments, this often includes administrative access to deployment targets and access to highly privileged service principals.

The exfiltration of environment variables and credential files provides the attackers with persistent access to the victim's infrastructure. With stolen AWS credentials, attackers can provision unauthorized resources, access private S3 buckets, or manipulate Route53 DNS records. With stolen database credentials, they can extract or destroy customer data.

The secondary impact involves lateral movement across the software supply chain. If the compromised developer account holds publishing rights to other internal or external packages, the attackers can inject similar malware into downstream dependencies. This cascading effect was a primary goal of the Mini Shai-Hulud campaign.

Due to the automated nature of the exploitation and the severe consequences of credential theft, this vulnerability carries a functional severity equivalent to a CVSS 10.0. The lack of authentication required to deliver the payload, combined with the high privileges of the target process, maximizes the overall risk profile for any affected organization.

The immediate remediation step is the absolute removal of the 5.0.2 version from all environments. Organizations must audit their composer.lock files across all repositories to verify if the 5.0.2 tag was ever resolved and installed. If the version is detected, it must be downgraded to a known safe version (e.g., 4.x) or upgraded to a secure version released post-incident.

If evidence suggests that version 5.0.2 was executed on any system, organizations must assume a total compromise of all secrets accessible to that system. This requires the immediate rotation of all environment variables, database passwords, AWS IAM keys, and API tokens present on the affected developer workstations or CI/CD runners. Failure to rotate these credentials leaves the infrastructure vulnerable to persistent access, even after the malicious package is removed.

To mitigate future supply chain risks, organizations should implement strict version pinning in dependency management. Relying on exact versions in composer.json and rigidly enforcing the use of composer.lock during deployments prevents unexpected automated upgrades to malicious tags. Furthermore, limiting the network egress of CI/CD environments to a strict allowlist prevents the successful exfiltration of data to unauthorized C2 domains.

Maintainers of open-source projects must enforce Two-Factor Authentication (2FA) on all repository and registry accounts. Limiting the lifespan of API tokens and employing automated secrets scanning within the repository can prevent the initial account takeover that facilitates these supply chain attacks.