Topic starter
20/08/2026 5:55 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “oob.moika.tech npm campaign used dependency confusion to profile developer environments”.
Key questions
Q: What breaks when internal npm scopes are not locked to a private registry?
A: Package resolution can fall back to public code that only looks internal, which means a build can execute untrusted software before any application control sees it.
Q: Why does dependency confusion often become a secret-exposure event?
A: Because install-time code runs in environments that already hold secrets, including CI variables, developer tokens, and deployment credentials.
Q: How should teams reduce risk from malicious npm package installs?
A: Treat package installation as a controlled operation, not an implicit trust event.
Practitioner guidance
- Fail closed on internal package scopes Bind internal namespaces to private registries and block public fallback for packages that are intended to be internal only.
- Disable lifecycle scripts by default Use npm ci --ignore-scripts in CI and allow install-time scripts only for reviewed packages with a documented build need.
- Inventory exposed package scopes and versions Search lockfiles, manifests, caches, and build logs for the affected scopes and any republished versions tied to the campaign.
Bottom line: Dependency confusion turns package resolution into a security control, because public code can satisfy private-looking names when registries are not locked down.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:36 pm
Build-time trust is now a governance boundary: dependency resolution belongs in the same control conversation as authentication and secrets handling. Once package managers can choose public code for private names, the supply chain no longer has a reliable trust boundary. Practitioners should treat namespace resolution as a privileged decision point, not an operational convenience.
A question worth separating out:
Q: Should organisations prioritise registry scoping or secrets rotation first after this kind of issue?
A: Registry scoping comes first because it removes the trust failure that lets public packages stand in for private ones. Secrets rotation is then the containment step after exposure is suspected. Without fail-closed resolution, rotation alone only cleans up the aftermath of the same control gap.
👉 Read our full editorial: Dependency confusion in npm shows how build-time trust breaks