PhantomRaven shows how npm supply-chain attacks reach mobile builds

At a glance

What this is: PhantomRaven is an npm supply-chain attack that uses Remote Dynamic Dependencies to load malicious code during install and evade registry-focused scanners.

Why it matters: It matters because compromised developer and CI/CD identities can turn a single package install into pipeline access, credential theft, and downstream mobile app exposure.

By the numbers:

• PhantomRaven published 200+ malicious packages and accumulated tens of thousands of downloads.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read NowSecure's analysis of PhantomRaven and npm supply-chain malware

Context

PhantomRaven is a supply-chain risk problem first and a package-malware story second. The core issue is that build-time trust is often broader than registry scanning, especially when npm install can fetch code from external URLs and execute lifecycle scripts before any human review occurs. In mobile development, that gap matters because React Native, Ionic, and Capacitor projects inherit JavaScript dependency risk directly into release pipelines.

The identity dimension is the real governance bridge here. The campaign targets developer credentials, CI/CD tokens, and publishing access, which means the blast radius is defined by who and what the pipeline trusts, not just by what code the package registry contains. That starting position is common in modern DevSecOps environments, which makes the attack pattern broadly relevant rather than unusual.

Key questions

Q: What breaks when remote dynamic dependencies are not controlled in npm builds?

A: Build security breaks because the installer becomes the execution engine. A package can look harmless in the registry while fetching malicious code from an external URL during install, which bypasses many scanners and moves risk into the developer workstation or CI runner. The missing control is policy over what the installer may fetch and execute.

Q: Why do npm supply chain attacks create such a large IAM risk?

A: Because npm, GitHub, and cloud credentials often coexist in the same developer and build environments. A single compromised package can therefore expose multiple identity planes at once, including source control, workload access, and cloud control surfaces. The risk grows when secrets are reusable, long-lived, or readable from default install contexts.

Q: What do security teams get wrong about dependency scanning?

A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.

Q: How should teams reduce supply-chain risk in mobile build pipelines?

A: They should treat the pipeline as a privileged identity environment. That means deterministic installs, restricted egress, disabled or allowlisted lifecycle scripts, isolated signing keys, and review gates for new or AI-suggested dependencies. Mobile release integrity depends on controlling both code provenance and the machine identities that move code into release.

Technical breakdown

Remote Dynamic Dependencies bypass registry-based inspection

A Remote Dynamic Dependency is a package reference that points to an external URL instead of an artifact stored in the npm registry. That means the registry can show a harmless placeholder while the real payload is fetched at install time from attacker-controlled infrastructure. Traditional SCA tools often evaluate the registry artifact, package metadata, or cached tarball, but they may not retrieve the remote dependency that only appears during installation. This breaks the assumption that package provenance and package execution are the same thing.

Practical implication: teams need install-time policy controls, not just registry scanning.

Lifecycle scripts turn dependency fetches into code execution

npm lifecycle hooks such as preinstall, install, and postinstall run automatically during dependency installation. If an attacker controls the downloaded package, those scripts become an execution path that requires no user approval and no separate exploit chain. In PhantomRaven-style attacks, the malicious code runs silently during what looks like a routine install, which makes developer workstations and CI runners ideal targets. The key failure is assuming dependency installation is passive.

Practical implication: block or tightly allowlist lifecycle scripts in build environments.

Why mobile build pipelines widen the blast radius

Mobile projects frequently pull in npm dependencies even when the final deliverable is an iOS or Android app. That means a JavaScript supply-chain compromise can reach signing workflows, build artifacts, and release pipelines that sit outside the source repository itself. When those pipelines also use AI-assisted dependency suggestions, the risk expands further because a plausible but unverified package can slip into the tree before review. The attack surface is therefore the build system, not just the application codebase.

Practical implication: treat dependency governance, build egress, and signing access as one control boundary.

Threat narrative

Attacker objective: The attacker wants durable access to developer and CI/CD identities so they can steal secrets, alter builds, and extend compromise into mobile release pipelines.

1. Entry occurs when a developer or CI pipeline installs a package that references an attacker-controlled external URL through a Remote Dynamic Dependency.
2. Credential access follows when the payload searches developer files, environment variables, and CI systems for tokens, API keys, and identity data.
3. Impact lands when those credentials are used to reach repositories, pipelines, and mobile build or publishing infrastructure.

NHI Mgmt Group analysis

Remote dependency execution is the named governance failure here: the control plane assumes package trust can be judged from the registry artifact, but PhantomRaven moves execution outside that boundary. That makes provenance, execution, and inspection three different problems, not one. Security teams should stop treating package metadata as a complete trust signal and instead govern what the installer is allowed to fetch and run.

Developer and CI/CD credentials are now identity assets with supply-chain exposure: the malware does not need to defeat the application to be useful. It only needs a token, a config file, or a publishing secret to turn a single install into a broader compromise path. This is where NHI governance matters, because build systems increasingly depend on service accounts, scoped tokens, and machine credentials that are rarely reviewed with the same rigor as human access.

Install-time trust gap: build security fails when organisations assume the act of installing a dependency is lower risk than executing application code. In reality, the install step is where code, credentials, and network access converge. The practical conclusion is that supply-chain governance must include execution policy, egress control, and credential containment as one coherent model.

AI-assisted dependency selection can amplify supply-chain risk: the article’s slopsquatting example shows that attackers can weaponise plausible package names that developers or coding assistants might accept too quickly. That creates a second trust problem beyond malware hosting. Teams need verification workflows for AI-suggested dependencies, especially in repositories that feed mobile builds and signing pipelines.

Mobile release pipelines inherit the same risk, but with higher business impact: if npm compromise reaches signing keys or app-store release tooling, the issue becomes release integrity, not just developer hygiene. That expands the control set from SCA into secrets management, ephemeral build agents, and release separation. Practitioners should treat mobile delivery as a privileged identity workflow, not a simple build task.

What this signals

PhantomRaven is a reminder that software supply-chain defence now depends on identity controls as much as code controls. If a build can fetch and execute external content, then secrets containment, token scope, and egress policy become the practical boundary between routine development and compromise. Teams should expect more attacks that exploit that boundary rather than attempt to break application logic directly.

Install-time trust gap: this is the point where traditional SCA, DevSecOps, and NHI governance meet. The risk is not only malicious code, but also the machine identities that can authorise package retrieval, signing, and release operations. Practitioners should align build policy with least privilege and review the access paths that exist only during installation.

As mobile development becomes more AI-assisted, dependency review will need to account for plausible but unverified package selection. The stronger the automation, the more important it becomes to preserve explicit control over what can run, what can egress, and which credentials can be touched during the build. That is a programme design issue, not just a tooling issue.

For practitioners

• Block install-time network fetches by default Enforce egress allowlisting on build agents so npm, node, and yarn can only reach approved registries and internal mirrors during dependency installation.
• Disable lifecycle scripts in unattended builds Set npm config ignore-scripts true in CI and create a narrow allowlist for scripts that have been reviewed and explicitly required.
• Contain developer and CI/CD credentials as NHIs Use short-lived scoped tokens, vault-backed secrets, and a rotation playbook for developer, npm, publishing, and pipeline credentials after any suspicious install activity.
• Verify AI-suggested dependencies before they enter mobile repos Require manual review for new packages, especially low-reputation names suggested by coding assistants, and compare them against internal allowlists before merging.
• Separate dependency resolution from signing and publishing Use ephemeral hardened build agents so dependency download, app signing, and release publishing do not share the same credentials or network path.

Key takeaways

• PhantomRaven shows that npm supply-chain attacks can hide malicious code outside the registry and still execute during installation.
• The campaign matters because it targets developer and CI/CD identities, turning a package install into a secrets and release-risk problem.
• Teams should govern build-time execution, egress, and credential scope together or they will keep missing the real control gap.

Key terms

• Remote Dynamic Dependency: A Remote Dynamic Dependency is a package reference that points to an external URL instead of a registry-hosted artifact. It is risky because the code actually executed during installation may never appear in the package registry or normal dependency metadata.
• Lifecycle Script: A lifecycle script is npm code that runs automatically at specific points such as preinstall, install, or postinstall. These scripts can be legitimate, but they also create an execution path that attackers can abuse to run malware without further user action.
• SaaS Supply Chain Security: SaaS supply chain security is the practice of governing the trusted connections between cloud applications. It focuses on OAuth tokens, API integrations, third-party apps, and service accounts that can move data without changing code. The main concern is delegated access that outlives the original approval.
• Build Egress Control: Build egress control restricts where a pipeline job can send outbound network traffic. It reduces exfiltration risk, blocks unexpected communication, and makes build behavior observable. For delivery security, it is one of the simplest ways to constrain the blast radius of compromised jobs or dependencies.

What's in the full article

NowSecure's full article covers the operational detail this post intentionally leaves for the source:

• Package-by-package examples of Remote Dynamic Dependencies and how they appear in package.json files
• Stepwise detection signals for npm install behaviour, lifecycle scripts, and unexpected outbound network connections
• Mobile build hardening guidance for React Native, Ionic, and Capacitor pipelines that need release integrity
• Practical mitigation patterns for protecting signing keys, CI tokens, and app-store publishing access

👉 The full NowSecure post covers install-time behaviour, mobile build impact, and the mitigation steps in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect identity controls to the broader security programmes their environments depend on.