TL;DR: At least 179 malicious npm package-version records were tied to the oob.moika.tech dependency-confusion campaign, which used postinstall scripts to profile developer and CI environments and potentially expose secrets, according to Corgea. Build-time package resolution is part of the attack surface, and private namespaces must fail closed rather than fall back to public registry code.
NHIMG editorial — based on content published by Corgea: analysis of the oob.moika.tech npm dependency-confusion campaign
By the numbers:
- Public reporting tied at least 179 malicious npm package-version records to the oob.moika.tech dependency-confusion campaign.
- Systems with least-privileged AI access had a 17% incident rate versus 76% for over-privileged systems, showing how scope control changes incident likelihood.
Questions worth separating out
Q: What breaks when dependency confusion is allowed in CI/CD pipelines?
A: Build systems can install malicious public packages instead of trusted internal dependencies, which turns normal package installation into an execution path for secret theft.
Q: Why do malicious packages create identity risk as well as supply chain risk?
A: They become identity risk when install-time access includes cloud tokens, signing keys, or service credentials.
Q: How can security teams tell whether secret exposure from package installs is contained?
A: Containment is real only when exposed credentials are revoked, replacement identities are least privileged, and the build and repository estate has been searched for persistence markers.
Practitioner guidance
- Lock internal package scopes to private registries Map every internal namespace to a private registry and configure resolution to fail closed if the private source is unavailable.
- Disable lifecycle scripts in CI by default Use npm ci --ignore-scripts for pipeline installs, then allow lifecycle scripts only for packages with a documented build-time need and an approved owner.
- Audit lockfiles, caches, and install telemetry for affected scopes Search lockfiles, package caches, CI logs, and endpoint telemetry for the affected package scopes and suspicious postinstall execution.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Package-by-package affected scope mapping across the oob.moika.tech campaign and the overlapping public reporting slices
- Exact hunting commands for lockfiles, process telemetry, and dropped payload artefacts in developer and CI environments
- Remediation examples for npm scope-locking, private registry configuration, and script-control policy
- Campaign infrastructure details, including lure domains, report endpoints, and temporary file markers
👉 Read Corgea's analysis of the oob.moika.tech npm dependency-confusion campaign →
Dependency confusion in npm builds: what teams are missing?
Explore further
Dependency confusion is a namespace governance failure, not just a package hygiene issue. The attacker succeeds when an internal name can be satisfied by an untrusted public source, which means the control problem sits in registry policy and resolution order. OWASP-NHI thinking applies here because the build system is effectively handling machine identities and secrets on behalf of the software supply chain. The practitioner conclusion is simple: make internal package namespaces private by design, not by convention.
A question worth separating out:
Q: Who is accountable when malicious code enters through a package registry?
A: Accountability usually spans the package maintainer, the registry controls, and the consuming organisation’s build governance. The maintainer identity is the publishing control point, but the consumer still owns script restrictions, lockfile enforcement, and credential protection on build systems. The right question is who owned each control layer, not who noticed the attack first.
👉 Read our full editorial: Dependency confusion in npm shows how build-time trust breaks