Attackers pushed credential-stealing code through npm by abusing URL-based dependencies and install-time scripts. Because the payload lives outside the registry and arrives during installation, many scanners miss it. As a result, build servers and developer laptops leak tokens, CI/CD secrets, and source credentials. Consequently, security teams need to lock down install-time egress, prohibit remote dependencies, and add network-aware checks into CI.
INCIDENT SUMMARY AND SCOPE
The campaign plants seemingly harmless packages that declare few or zero dependencies. However, the package.json references a remote dependency by URL or VCS. During npm install, the environment fetches code directly from that external location and runs lifecycle scripts that harvest secrets. Meanwhile, adversaries rotate URLs, gate payloads by IP, and deliver selective malware only to juicy targets. Therefore, telemetry looks clean for most users while high-value environments lose tokens. As defenders review impact, they should assume exposure of npm tokens, GitHub credentials, and CI/CD variables across developer endpoints and shared runners.
ATTACK CHAIN AND TTPs
The chain starts when a developer installs a package that appears legitimate. Next, npm resolves a URL dependency and pulls code from a remote repository. Then a preinstall or prepare script runs and executes a small bootstrapper. That component fingerprints the host, exfiltrates secrets, and retrieves additional payloads. Afterward, the attacker reuses stolen tokens to pivot: they access private repos, poison dependent packages, or hijack workflows. This pattern maps to well-known techniques: Supply Chain Compromise for the package manipulation, Ingress Tool Transfer for tool delivery over the network, and Command and Scripting Interpreter for execution. Because the dependency originates outside the registry, static analyzers that only parse package metadata fail to see the true supply chain.
WHY MANY SCANNERS MISS IT
Registry-only scanners count the dependencies declared inside the uploaded tarball. However, URL specifiers point to code the registry does not host. Therefore, the analyzer reports zero or few dependencies and never follows the remote link. Additionally, many environments still allow install-time lifecycle scripts for convenience, which enables execution before any runtime EDR or application control observes the binary. Because this behavior sits inside accepted package-manager features, attackers enjoy cover. Consequently, defenders must add network-aware checks that resolve and inspect the remote artifact, or they must ban URL dependencies and lifecycle scripts in production builds.
SLOPSQUATTING AND PACKAGE DISCOVERY
Adversaries now seed fake-but-plausible names and then rely on suggestions from AI coding assistants or rushed copy-paste to drive adoption. Unlike classic typosquatting, slopsquatting leans on hallucinated names that sound credible but never existed until the attacker registered them. Because the names look clean and the readme promises useful tasks, developers trust the install suggestion. Therefore, the technique pairs perfectly with invisible dependencies: the malicious code hides behind a remote URL while the package page looks minimal. Security teams should add review gates when an AI tool proposes a fresh dependency, and they should require a second reviewer for any brand-new package admits into baseline images.
INDICATORS AND DETECTION
Focus on install-time network activity and script execution. First, hunt for package.json entries that reference git+https URLs, raw content links, or non-registry endpoints. Second, flag preinstall, install, and prepare scripts across corporate projects; compare against an allowlist that only includes necessary native compilation tasks. Third, inspect build logs and shell histories for curl, wget, PowerShell WebClient, or Node fetch during package installation. Then review outbound connections from build agents to previously unseen domains, short-lived repos, or paste-style endpoints. Finally, monitor unusual usage of freshly minted npm tokens and GitHub Personal Access Tokens, because adversaries frequently validate access soon after infection.
CONTAINMENT AND REMEDIATION
Start with token rotation at scale: npm, GitHub, cloud keys, and CI secrets. Remove affected packages, rebuild artifacts from trusted mirrors, and invalidate cached layers that contain infected dependencies. Next, run a forced clean install with a locked dependency graph, then generate a new SBOM for comparison against the last known-good build. Afterward, reimage developer machines that installed suspicious packages and reissue credentials. For CI, replace long-lived credentials with short-lived, workload-identity-based tokens that limit exfiltration value. In the medium term, move to an internal registry mirror with signed artifacts, ban URL dependencies in policy, and fail builds that attempt lifecycle scripts outside approved contexts.
HARDENING: BUILD EGRESS, POLICY, AND SBOM
Because the payload arrives over the network, you win by closing egress at install time. Deny outbound traffic from builders by default. Then allowlist only your internal mirror and the official registry endpoints you control. Enforce policy that rejects URL dependencies and forbids lifecycle scripts in production builds. Require SBOM generation on every build and alert on diff spikes or unexpected maintainers. Because attackers increasingly target package author accounts, monitor ownership changes and force multifactor plus passkey enrollment for maintainers. Finally, add dynamic dependency analysis to CI so the pipeline resolves remote specifiers in a sandbox and inspects their true contents before approval.
BUSINESS IMPACT AND RISK
Credential theft from build agents and developer laptops enables source code theft, package poisoning, and cloud pivoting. Consequently, organizations face breach disclosure, partner-ecosystem exposure, and sustained risk as stolen tokens enable long-tail persistence. Because many teams still trust green checks from static scanners, they underestimate impact. Treat this as a supply chain breach, not just a malware event. Then brief engineering leadership and set a deadline for policy changes that close install-time egress and remove URL dependencies from baseline templates.
FAQs
Q: How do we know whether a package uses a remote dependency?
A: Search package.json for git+https, direct URLs, or VCS specifiers. Then resolve the dependency in a sandbox to observe the fetched code.
Q: Should we block all lifecycle scripts?
A: Block them in production builds. Allow only the minimal set needed for native compilation inside controlled images.
Q: How fast should we rotate tokens after suspected exposure?
A: Rotate immediately, then reissue with the least privilege and shortest lifetime you can enforce. Monitor for reuse.
Q: What do we do with AI-suggested packages?
A: Require human review for new dependencies and verify existence, maintainer reputation, update cadence, and security posture before admission.
Q: How do we measure progress?
A: Track install-time egress blocks, the count of packages with lifecycle scripts, SBOM coverage, and mean time to token rotation after detection.
