npm Dependency Confusion Hits Akamai, Fastly, Twilio Names

On August 15, 2026, a batch of npm packages was flagged as containing malicious code, and the most telling cluster in that batch is a set of dependency confusion packages built to shadow the internal namespaces of Akamai, Fastly, Twilio, and Google Cloud. The names give the intent away: akamai-sensor, akamaijs-sensor, fastly-vcl-language-client, upload-to-gcp, and twilio-hackerone-poc-afe6937c. Sitting next to them is a group of reconnaissance style packages such as hunterone-build-probe-9210, tw-pkgprobe-7731, and three depcruise-* entries. None of these are libraries you would install on purpose. They exist to be resolved by mistake, during a build, when a package manager reaches out to the public registry for a name that was supposed to stay private.

This is a dependency confusion story more than a typosquatting one. The packages are not trying to look like lodash or react. They are trying to look like the private, unpublished packages that live inside a specific company's monorepo or internal registry. That makes the target set narrow and the payoff high, because a single misconfigured build can leak credentials, tokens, and environment details straight out of a CI runner.

What happened

Our catalog recorded these packages as critical severity with an update date of 2026-08-15. The entries follow the automated "Malicious code in <package> (npm)" advisory format that scanners like Socket publish and mirror into OSV and GitHub Advisories. Detailed per-package write-ups are thin, which is normal for automated detections. The tooling flags behavior it can observe at scale (install-time network calls, environment variable collection, obfuscated payloads, or beaconing) and files an advisory before an analyst documents each package by hand. Treat the flags as a signal to check your own builds, not as a full reverse engineering report.

The vendor-named packages are the standout. akamai-sensor, akamaijs-sensor, and akamaijs-sensorv1 echo Akamai's client-side bot detection sensor tooling. fastly-vcl-language-client reads like tooling for Fastly's VCL configuration language. upload-to-gcp sounds like an internal deployment helper. twilio-hackerone-poc-afe6937c reads like a proof of concept tied to a HackerOne report. That last name matters, because dependency confusion is a well-worn bug bounty technique, and some packages with these names are published by researchers rather than criminals. Automated scanners do not make that distinction. If a package collects host data and phones home on install, it gets flagged as malicious code regardless of the author's intent.

None of this happened in a quiet week. npm has been under sustained pressure through the summer of 2026, from the self-replicating Shai-Hulud and ChainDrop worms that hit hundreds of packages, to a separate wave that, according to The Hacker News, planted a cross-platform RAT and infostealer across nearly 800 packages. Dependency confusion beacons are a quieter part of that same problem. They rarely make headlines on their own, but they are cheap to publish and hard to notice.

The packages flagged on August 15

It helps to group the batch by apparent purpose. The grouping below is based on the package names and the advisory pattern, not on a confirmed campaign attribution.

Vendor and cloud impersonation:

Reconnaissance and build-probe style names:

The same 2026-08-15 flag list also carried more conventional junk, including likely typosquats such as require-i18next and gunzip-js, the plugin-shaped tailwind-plugin-kit, and a spread of others (adxaa, autbank-core, @finaxis/common-js, @openrepl/shared, harmony-app-toolkit). Daily npm malware flagging is noisy, and most of those are one-off droppers. The dependency confusion cluster is the part worth reading closely, because it targets specific organizations rather than the general public.

We do not have reliable download counts for these packages, and that absence is expected. Dependency confusion packages usually show low direct downloads, because they depend on a victim build accidentally resolving a private name to the public registry. Low numbers do not mean low risk.

Why dependency confusion works

Dependency confusion abuses how package managers resolve a name. If your organization publishes a private package named internal-auth to an internal registry, and an attacker publishes a public internal-auth with a higher version number, a misconfigured resolver can pull the attacker's copy from the public npm registry instead of yours. Microsoft's research team documented this exact pattern earlier in 2026, describing npm packages that abused dependency confusion to profile developer environments and beacon details back to the author. The vendor-named packages in this batch fit that model. An attacker who guesses that Akamai, Fastly, or Twilio use internal packages with those names can publish public look-alikes and wait for a build to reach for them.

The reconnaissance names point at the first stage of that playbook. pkgprobe, build-probe, and depcruise-baseline read like tooling that measures what resolves and where, which is how a researcher or attacker maps an organization's internal namespace before weaponizing it. The typical payload for these packages is a preinstall or postinstall script that runs on npm install, collects hostname, username, working directory, DNS suffix, and environment variables, then sends them to an external endpoint. That is enough to confirm a name is live inside a target and to grab whatever secrets the build environment exposes.

Who is affected

The named vendors do not tell you who was breached. They tell you whose internal names an attacker was guessing. Publishing akamai-sensor on npm does not mean Akamai was compromised, and there is no public evidence that any of these vendors were. The real exposure is any organization whose builds reference an unscoped internal package with one of these names, or whose package manager is configured to fall back to the public registry for private names.

CI/CD pipelines are the highest-value target. A build runner usually holds cloud credentials, registry tokens, and signing material, and it installs dependencies automatically with scripts enabled. Developer laptops are next, for the same reason. If you maintain internal npm packages and have not reserved those names publicly or locked resolution to a private registry, assume you are in scope until you check.

How to check if you are affected

Start with your lockfiles. Search every repository, not just the ones you think are clean.

grep -E "akamai-sensor|akamaijs-sensor|akamaijs-sensorv1|fastly-vcl-language-client|upload-to-gcp|twilio-hackerone-poc-afe6937c|hunterone-build-probe-9210|tw-pkgprobe-7731|depcruise-baseline|depcruise-fmt|depcruise-wrap-stream-in-html" \
  package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

Check whether any of the names resolve in an installed tree:

npm ls akamai-sensor akamaijs-sensor fastly-vcl-language-client upload-to-gcp depcruise-baseline 2>/dev/null

Inspect your registry configuration for a public fallback on private names. Unscoped internal packages are the risk.

npm config get registry
cat .npmrc ~/.npmrc 2>/dev/null

Finally, look at your CI logs for the last week. Search for install-time network calls to unfamiliar hosts during npm install, and for preinstall or postinstall scripts you do not recognize.

Remediation

If you find any of these packages installed or resolved, treat the affected machine or runner as exposed. The install script runs with the permissions of whoever ran npm install, so assume anything readable in that environment is gone.

# 1. Remove and stop the build from reinstalling it
rm -rf node_modules
# remove the offending entry from package.json / lockfile, then:
npm ci --ignore-scripts

# 2. Rotate any secret that was present in the environment:
#    npm tokens, cloud keys (AWS/GCP/Azure), CI/CD secrets, signing keys

Then close the door on dependency confusion so this does not recur:

Move internal packages under a private scope (for example @yourorg/name) and pin that scope to your internal registry in .npmrc.
Reserve your internal package names on the public npm registry as empty placeholders so no one else can claim them.
Configure your package manager so private scopes never fall back to the public registry.
Disable install scripts by default in CI. npm 12 blocks install scripts out of the box, which is the direction to move toward (see our coverage of npm blocking install scripts).

Run installs without scripts where you can:

npm install --ignore-scripts
# or set it repo-wide:
npm config set ignore-scripts true

That last setting has tradeoffs, because some legitimate packages need build steps, so test it before enforcing it everywhere.

FAQ

Is akamai-sensor or fastly-vcl-language-client safe to use?

No. Both were flagged as containing malicious code on 2026-08-15 and neither is an official Akamai or Fastly package. If you see either name in a lockfile or install log, remove it, rebuild from a clean tree, and rotate any credentials that were reachable from that environment.

How do I know if I am affected by this npm dependency confusion wave?

Grep your lockfiles for the exact package names listed above, run npm ls against them, and review CI logs from the past week for unexpected install-time network calls. Dependency confusion packages rely on a misconfigured resolver pulling a private name from the public registry, so pay special attention to unscoped internal packages.

Does this mean Akamai, Fastly, or Twilio were breached?

No. There is no public evidence any of these vendors were compromised. The package names are guesses at internal namespaces, published on npm in the hope that a build somewhere resolves them by mistake. Naming a package twilio-hackerone-poc is an attacker (or researcher) targeting Twilio's build environment, not proof that Twilio was hacked.

How do I stop dependency confusion attacks in my builds?

Put internal packages under a private scope, pin that scope to your internal registry, and reserve the names publicly so no one else can register them. Disable install scripts in CI, prefer npm ci with a committed lockfile, and verify package provenance where your registry supports it.