Targeted Packagist poisoning turns Composer installs into RCE

At a glance

What this is: This is an analysis of a poisoned Packagist development branch that could execute remote code during Composer installs and stage further payloads through runtime activity.

Why it matters: It matters because developers and CI runners often inherit broad credential access, so a package that looks routine can become a path into secrets, deployments, and source control.

👉 Read Corgea's analysis of the Packagist branch poisoning and RCE chain

Context

Supply-chain compromise is most dangerous when the malicious code sits inside a path teams already trust for routine development work. In this case, the risk is not a broad package-wide release flaw but a narrow Composer development branch that could be selected intentionally through a plausible instruction, which makes provenance, pinning, and review the real control points.

For IAM and NHI programmes, the important issue is what the build process can reach once code executes. Developer workstations and CI runners frequently hold secrets, tokens, and deploy credentials that function as non-human identities, so a package-level compromise becomes an identity-governance problem as soon as the loader can read environment variables or cached credentials.

Key questions

Q: What breaks when a poisoned package can execute during Composer install?

A: A package install stops being a file retrieval step and becomes a code-execution event. If the installer can run arbitrary JavaScript or shell activity, the attacker can read environment variables, cached credentials, source files, and CI metadata. That collapses the boundary between dependency management and identity compromise, especially where build hosts hold machine credentials.

Q: What breaks when supply-chain poisoning reaches developer workstations and CI runners?

A: The main failure is assuming a compromised package only affects one project. In practice, developer hosts and CI runners often hold cloud tokens, source access, and signing credentials, so a poisoned dependency can become a broader trust-breach across repositories and deployment paths. Once that happens, traditional package scanning is no longer enough on its own.

Q: What do security teams get wrong about package provenance in supply-chain attacks?

A: They focus on whether the package name looks legitimate and ignore how the dependency is selected and installed. A malicious branch, version constraint, or task-specific instruction can be enough to trigger code execution even when the maintainer name and repository appear normal. Provenance must include branch, commit, and build context.

Q: What should teams do after a malicious dependency is discovered?

A: Contain the affected endpoints, revoke any credentials that were reachable from those systems, and rebuild trust from known-clean environments. Then review where secrets are stored, not just which package was compromised. If the same workstation holds cloud, SSH, and SaaS credentials, the incident response plan must cover all three identity domains.

Technical breakdown

How a poisoned Composer branch becomes execution during install

Composer can install development versions when a branch constraint is explicitly requested, and that makes the package selection step part of the attack surface. In this case, the malicious artifact lived in a dev branch rather than the stable release line, which reduces accidental exposure but makes social engineering more effective. The attacker relies on a believable request, then abuses the trust developers place in package names and branch references. Once installed, the loader runs inside the PHP or Node.js environment and inherits the same local access that the build process has, including file system reach and environment visibility.

Practical implication: treat dev-branch package installs as executable content and require commit pinning plus approval for any unreviewed branch constraint.

Why the loader used runtime decoding and public blockchain services

The loader did not depend on a fixed malware domain. Instead, it reconstructed later-stage payloads at runtime by querying public blockchain RPC services, deriving transaction-linked data, and decrypting content with embedded keys. This pattern creates resilience for the attacker because defenders cannot rely on a single hosted indicator or a static download URL. The package only needs outbound network access and a way to transform remote transaction data into executable JavaScript. That design also blurs normal build telemetry, because the workflow can look like ordinary API traffic until the process spawns a new Node.js interpreter.

Practical implication: monitor build-time calls to blockchain RPC endpoints and block child-process spawning from package-install contexts.

Why developer and CI secrets are the real target

The exploit is valuable because code execution during a build can expose credentials that were never meant to leave the workstation or runner. That includes .env files, shell history, SSH keys, cloud tokens, Composer credentials, npm tokens, and deploy secrets. In identity terms, these are non-human identities and machine credentials concentrated in environments that often have weak lifecycle governance and minimal session isolation. The issue is not just malware on a developer laptop. It is uncontrolled access to the credential estate that supports source control, deployment, and production access.

Practical implication: segment build identities from production identities and rotate every secret reachable from the affected process environment after any suspected execution.

Threat narrative

Attacker objective: The attacker wanted arbitrary code execution in development and CI environments so they could harvest secrets and extend access into source control and deployment systems.

1. Entry occurred when a developer or CI process installed the poisoned Composer development branch through a plausible package request.
2. Escalation happened as the loader executed runtime-decoded JavaScript and used public blockchain services to fetch staged payloads.
3. Impact followed when the process could read environment secrets, credential caches, and deployment tokens from the build host.

NHI Mgmt Group analysis

Package trust is now an identity control, not just a software supply-chain concern. When a build system can execute package code during install, the package itself becomes a temporary bearer of trust. That trust reaches environment variables, cached credentials, and deployment tokens, which are all machine identities in practice. Security teams should therefore evaluate package provenance with the same discipline they use for privileged access.

Development branches create a narrow but highly believable execution path. The attacker did not need to poison the stable release line if they could persuade a target to install a named branch that looked task-specific. That makes social engineering and package selection inseparable from code review. Practitioners should treat branch constraints as executable instructions requiring governance, not convenience shortcuts.

Credential concentration in developer tooling is the blast-radius problem this breach exposes. Build hosts often accumulate secrets from Git, cloud, CI, and deployment tooling, yet those credentials are rarely governed as a lifecycle-managed identity estate. The result is a single install path that can reach multiple downstream systems. The control gap is not just malware detection, but the lack of compartmentalised machine identity boundaries.

Blockchain-backed payload staging is a defender visibility problem, not an exotic attacker trick. Using public RPC services removes the need for a persistent malware domain and shifts detection toward behaviour, process ancestry, and child-process control. That means traditional allowlists are weaker than policy around what build processes may invoke. Teams should assume that benign-looking external services can be used as dead-drops.

NHI governance must extend into CI and developer workstations. Secrets used by automation, build runners, and package managers are non-human identities with real privileges, even if they are not centrally managed as such. This kind of compromise works because those identities are present, reachable, and often over-scoped. Practitioners should align package-install controls with NHI lifecycle, not treat them as separate security domains.

What this signals

Package-install compromise now sits on the same risk path as secret exposure, because the installer can reach the credential estate before defenders notice the dependency is poisoned. The practical response is to treat build systems as governed identity platforms, with short-lived access, isolated runners, and explicit limits on what a package install may invoke. That is where the control boundary needs to move.

Credential fragmentation increases the chance that one poisoned install becomes many downstream compromises. When secrets are spread across package managers, CI services, cloud consoles, and developer machines, rotation after detection is slow and incomplete. Teams should map where machine credentials live, then collapse unnecessary duplication before the next supply-chain event creates recovery drag.

For practitioners

• Pin and approve every dev-branch dependency Block unreviewed dev-* Composer constraints in CI, and require commit-level pinning for any branch that is not a vetted release artifact.
• Separate build secrets from production identities Use isolated runner credentials, short-lived tokens, and distinct service accounts so a compromised build process cannot read the same secrets used for deployment or source control.
• Detect blockchain RPC use in build telemetry Alert on outbound calls to TRON, Aptos, or similar RPC services from package-install contexts, especially when the same job later spawns node -e or other interpreters.
• Rebuild and rotate after suspected package execution Reimage affected developer workstations and CI runners, then rotate GitHub, GitLab, Bitbucket, cloud, SSH, npm, Composer, and database credentials reachable from the process environment.

Key takeaways

• The breach shows that a dependency can become a code-execution path without touching the stable release line.
• The biggest risk is not the package alone, but the developer and CI secrets it can reach once execution starts.
• Pinning branches, isolating build identities, and rebuilding affected runners are the controls that reduce the blast radius fastest.

Key terms

• Dependency Branch Poisoning: A supply-chain attack in which a seemingly legitimate development branch or version constraint contains malicious code. The danger is not limited to release artefacts, because build tools may execute code from targeted branches during normal installation workflows.
• Build-Time Credential Exposure: The loss of secrets that exist on developer workstations or CI runners at the moment a dependency executes. These credentials often include cloud tokens, SSH keys, package manager secrets, and deployment access, making the build environment a high-value identity boundary.
• Runtime Payload Staging: A technique where the first malicious component fetches or reconstructs a second-stage payload at execution time rather than storing it directly in the package. This reduces static detection and shifts defender focus to behaviour, network activity, and process creation.
• Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.

What's in the full report

Corgea's full analysis covers the operational detail this post intentionally leaves for the source:

• The exact poisoned branch selection and package scope needed to verify whether your environment is exposed.
• The loader indicators and search patterns useful for hunting across Composer caches, source trees, and CI workspaces.
• The runtime behaviour chain that reaches blockchain RPC services and spawns secondary Node.js payloads.
• The response workflow for purging caches, rebuilding runners, and rotating affected credentials.

👉 Corgea's full post covers loader indicators, hunt queries, and response steps for affected build environments.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, workload identity, and agentic AI identity. It gives practitioners a framework for managing machine credentials across development, automation, and production environments.