The cross- ecosystem attack that shook Packagist: when PHP and Node allow back doors in CI

A recent coordinated attack on the supply chain has committed eight packages published in Packagist, introducing malicious code designed to download and run a Linux binary hosted in a GitHub release. What makes this campaign particularly worrying is the "cross-ecosystem placement" technique: the attackers did not modify the composer.json file (the point that they normally review equipment that analyses PHP dependencies), but the package.json that accompanies projects that pack JavaScript building tools along with PHP code, allowing Node installation scripts to run inadvertently in building facilities or processes.

The malicious installer adds a post-install script that tries to get an executable from a GitHub Releases URL (publicly indicated as pointing to a repo that no longer exists), save it in / tmp / .shd, give it execution permissions with chmod and launch it in the background. In addition, according to the analysis, the installer tries to hide its activity by disabling TLS verification and removing errors. This creates a remote execution window during installation or in CI work which can result in theft of secrets, pivoting within building environments or installation of back doors in productive infrastructure.

Socket reported that the malicious versions were already removed from Packagist, but his research found references of the same payload in 777 files in GitHub, including at least two insertions into GitHub Actions workflows. This suggests a potentially much greater scope: some cases may be compromised forks, duplicate artifacts or cache references, but the presence of the payload in both artifacts and workflows shows that the attackers used several execution vectors.

The technical consequences are clear: projects that pack multi-ecosystem units and run scripts during installation or in CI are high value targets. Many tools and processes are assumed safe because they only inspect metadata from the main ecosystem (e.g., composer.json in PHP projects) and not the metadata of packages included from other ecosystems (package.json, package-lock.json, yarn.lock), leaving an exploitable attack surface.

If your project could be affected (or simply as good hygiene), act immediately: first, avoid running facilities or building in environments with sensitive credentials until you have checked the artifacts. Inspects any recent commitments in upstream repositories and reviews the publication history. If you found a malicious version, revoke any key or token that might have been in the environment during the installation, because remote execution may have exfiltered secrets. It publishes a clean version and notifies your users transparently about the need to update.

At the operational level, it implements controls that reduce the risk of execution of unauthorized scripts: it configures CI to not run fork workflows automatically, uses runners with minimum and isolated permissions, uses the option to ignore scripts in automated facilities (e.g., npm ci --ignore-scripts or the npm config set ignore-scripts true when appropriate), and avoids arbitrary downloads in build time from external unvalidated URLs. It also enables strict verification of TLS in all automated processes and records outgoing calls during buildings to detect suspicious downloads.

From the perspective of software supply chain management, it adopts more advanced security practices: it generates and consumes SBOMs, uses device signatures and source verification (e.g. technologies such as Sigstore), and applies SCA scanning including analysis of CI package.json and workflows, not only the main ecosystem manifests. Security tools and platforms such as GitHub Actions require strict policies for third-party execution; review GitHub Actions' documentation on workflow protection to reduce the execution of unreliable code: GitHub Actions.

For detection and response, it incorporates scanners looking for suspicious postinstall scripts, binary download patterns in / tmp, or calls to unusual domains and repositories. Services and external providers specialized in SCA can help identify malicious versions and blockages in package sources; in addition, maintaining release approval policies and requiring human reviews before publishing or integrating changes in critical units reduces the likelihood of unnoticed commitments.

This incident is a reminder that the security of the supply chain requires cross-cutting visibility: it is not enough to audit a single ecosystem when projects mix languages and tools. Keep up-to-date inventory of units, apply installation controls and defensive CI, require signed source of devices and act quickly in case of detection to mitigate the exposure window. To better understand the picture and best practices on supply chain attacks, consult analysis and practical guides such as Snyk's on such threats: Snyk - Software Supply Chain Attacks and regularly reviews official sources and security repositories for commitment indicators.