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.
At a glance
What this is: Corgea describes a dependency-confusion campaign in npm that turned package installation into a build-time trust failure and exposed how postinstall scripts can profile developer and CI environments.
Why it matters: It matters because IAM, NHI, and secrets teams need to treat package resolution and lifecycle execution as security controls, not just developer convenience, when build systems can expose tokens and environment variables.
Context
Dependency confusion is a package-resolution problem, not a code-quality problem. It occurs when a private-looking package name can be satisfied from a public registry, or when public versions out-rank private ones, so build tooling trusts the wrong source before application code ever runs.
In this case, the governance gap is in build-time trust. The article shows how npm install can execute attacker-controlled lifecycle scripts, which means environment variables, CI context, and local developer state can be exposed during dependency installation rather than during runtime.
That makes the issue relevant to IAM and NHI programmes because build systems often hold secrets, service tokens, and automation credentials. The starting position is unfortunately typical: many teams trust package managers to resolve namespaces safely without explicitly locking them to private registries.
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. The failure is not just installation risk. It is trust inversion, where the registry decides what runs inside your build environment.
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. A malicious package does not need direct application access to be dangerous. It only needs enough execution context during npm install to read what the build system has exposed.
Q: How should teams reduce risk from malicious npm package installs?
A: Treat package installation as a controlled operation, not an implicit trust event. Restrict secret exposure in build environments, separate publish rights from routine development access, and make secret rotation and revocation part of incident response, especially for systems that handle CI/CD credentials.
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.
Technical breakdown
How dependency confusion hijacks package resolution
Dependency confusion exploits the way package managers decide whether to fetch a name from a private registry or a public one. If namespace ownership is not enforced, or if version selection prefers the highest available release regardless of source, a public package can masquerade as internal software. The problem is not only the package name. It is the trust decision made during resolution, before any source code is reviewed or executed. In build systems, that trust decision happens automatically and repeatedly, which makes it a supply-chain control issue rather than a one-off developer mistake.
Practical implication: lock internal namespaces to a private registry and make public fallback impossible for packages that are meant to be private.
Why npm postinstall turns installation into execution
npm lifecycle scripts such as postinstall run as part of dependency installation, which means a malicious package can execute before an application starts. That execution context is powerful because it can read process environment variables, host details, working directories, and CI markers without needing explicit application permissions. In other words, install-time code runs with the same ambient trust granted to the build pipeline or developer workstation. That is why postinstall abuse is so effective in dependency-confusion campaigns: the package does not need to break into production. It only needs to be installed.
Practical implication: treat lifecycle scripts as an execution boundary and restrict them by default in CI and on developer systems.
Why build pipelines become secret-exposure targets
Build systems often hold the credentials attackers want most, including npm tokens, cloud keys, GitHub tokens, database URLs, and deployment secrets. A package that profiles the environment during installation can collect those values even if it never reaches production runtime. This is why build-time compromise is distinct from application compromise. The attacker is not after application logic alone. They are after the trust context of the build environment, where secrets are frequently present but poorly isolated from third-party code execution.
Practical implication: separate build credentials from developer workstations and assume any environment reached during installation may expose sensitive secrets.
Threat narrative
Attacker objective: The attacker objective is to reach build-time secrets and environment data by making malicious public packages execute inside trusted developer or CI workflows.
- Entry occurred through dependency confusion, where attacker-controlled npm packages were resolved as if they were internal dependencies during installation.
- Credential harvesting followed when postinstall scripts profiled developer and CI environments and collected process environment data, host details, and package metadata.
- Impact was build-time secret exposure and the possibility of further compromise through stolen tokens, keys, and deployment credentials.
Breaches seen in the wild
- LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Postinstall execution creates an identity problem as well as a supply-chain problem: build pipelines and developer environments frequently carry non-human identities in the form of tokens, service credentials, and automation secrets. When third-party package code runs during installation, it inherits access to those identities before any downstream application controls can intervene. The practical conclusion is that install-time execution must be governed as tightly as any privileged automation path.
Dependency confusion is really resolution-policy debt: many organisations rely on implicit package-manager behaviour rather than explicit registry scoping, script restrictions, and provenance checks. That leaves them exposed to the same failure pattern across multiple ecosystems. The named concept here is build-time trust break, and it means teams need fail-closed resolution policies before they can claim supply-chain resilience.
Secret exposure during build is often the first measurable consequence, not the last: the article’s reconnaissance-first framing should not soften the risk assessment. Recon payloads are useful precisely because they collect the material for later compromise, including environment variables and workstation context. Security teams should assume that any successful install-time execution on a privileged runner can turn into credential abuse.
Private package names are not private unless the registry policy makes them private: this is the central operational lesson. A package manifest that references an internal namespace is only as trustworthy as the registry and script policy behind it. Practitioners should therefore audit the trust chain from manifest to registry to lifecycle execution as one continuous control surface.
What this signals
Build-time trust break: the important shift is that package installation is now part of the attack surface, not just a delivery mechanism. When public registry code can satisfy private-looking names, dependency governance has to extend into registry scoping, lifecycle script policy, and build provenance.
Security teams should expect this pattern to keep recurring across ecosystems because the underlying failure is architectural, not vendor-specific. The practical response is to treat package managers, CI runners, and developer workstations as identity-bearing execution environments that require explicit trust boundaries.
For practitioners
- 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.
- Rotate secrets from a trusted host Assume environment variables may have been exposed if install-time execution occurred, and rotate tokens, keys, and credentials from a clean system.
- Rebuild compromised runners and workstations Reimage developer and CI environments that executed the malicious packages, then restore them only from trusted base images and vetted dependencies.
Key takeaways
- Dependency confusion turns package resolution into a security control, because public code can satisfy private-looking names when registries are not locked down.
- The dangerous part is not only the malicious package, but the install-time script that runs before the application ever starts.
- Fail-closed registry policy and restricted lifecycle scripts are the controls that change the outcome, while secrets rotation only limits the fallout after exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, MITRE ATT&CK and OWASP API Security Top 10 address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Install-time package execution can expose secrets from developer and CI environments. |
| NHI-07 — Long-Lived Secrets | The campaign becomes more dangerous when build credentials persist long enough to be harvested. | |
| Recommendation — Scan build systems for exposed NHI secrets and block install-time access to high-value credentials. Reduce credential lifetime in CI and developer tooling so stolen secrets expire quickly. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The campaign uses execution during install to gather secrets and move data out through the payload channel. |
| Recommendation — Map install-time script abuse to credential access and exfiltration techniques in your detections. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Registry fallback and script execution defaults create a misconfiguration-driven trust failure. |
| Recommendation — Harden package and build defaults so insecure registry behaviour cannot resolve private dependencies from public sources. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Build-time credentials and automation tokens need tightly scoped authorisation in CI and developer environments. |
| Recommendation — Limit build identities to the minimum permissions needed for dependency installation and artifact creation. | ||
Key terms
- Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
- Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
- Build-Time Trust Boundary: A build-time trust boundary is the line that separates dependency installation and compilation from access to sensitive credentials or production systems. When that boundary is weak, malicious packages can turn routine automation into a path for broader compromise.
- Registry Scoping: The practice of binding package namespaces to a specific registry so resolution cannot silently fall back to public sources. In mature environments, this is a fail-closed control that prevents private names from being satisfied by untrusted code.
Deepen your knowledge
NHI Mgmt Group's NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the build and automation systems their programmes depend on.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org