T08 · Insecure Dependencies
- Location
installation.md:6- Finding
Conflicting and Unpinned npm Package Identity
- Content
View full analysis
Vulnerability Details
File Location:
installation.md:6-10;core.md:12-16
Vulnerability Type: Supply-chain ambiguity and unsafe dependency installation
Risk Level: HighVulnerable Code
installation.md:6-10:bash To install the Nimrobo CLI globally via npm: ```bash npm install -g @nimrobo/clitext `core.md:12-16`: ```bash ## Installation ```bash npm install -g nimrobo-clitext ### Technical Analysis The documentation identifies two different npm packages as the same Nimrobo CLI: - Scoped package: `@nimrobo/cli` - Unscoped package: `nimrobo-cli` No explanation establishes whether both packages are official, equivalent, or maintained by the same publisher. Neither installation command pins a reviewed version or provides an integrity value. Because npm installation can execute package lifecycle scripts, globally installing the unintended package allows that package to run code with the privileges of the user performing the installation. This creates a dependency-confusion or package-spoofing opportunity. The audit did not establish that either package is currently malicious; the vulnerability is the conflicting package identity and lack of verification that can direct users to an unintended dependency. ### Attack Path 1. A user or automated Agent follows `core.md` instead of `installation.md`. 2. npm resolves the unscoped `nimrobo-cli` package rather than the documented scoped package. 3. An attacker publishes, takes control of, or compromises the unintended package or a future version. 4. The user runs `npm install -g nimrobo-cli`. 5. Malicious package lifecycle scripts execute under the installing user's account. 6. The package can access local files and credentials available to that account, including the documented Nimrobo API-key configuration. 7. The attacker may subsequently impersonate the user or perform authenticated Nimrobo operations. ### Imp ...[truncated 654 chars]- Remediation
View remediation
Remediation Suggestions
- Select one canonical, publisher-verified npm package and use it consistently in every document.
- Remove the conflicting package name from
core.mdor explicitly document why both names are valid. - Pin installation instructions to a reviewed version, for example:
bash npm install -g @nimrobo/cli@X.Y.Z - Publish the expected npm organization, package owner, registry URL, and package signature or integrity-verification procedure.
- Prefer project-local installation with a lockfile over global installation where operationally possible.
- Disable lifecycle scripts during initial inspection where supported, and review the package before enabling them.
- Add automated documentation tests that fail when installation instructions reference inconsistent package names.
- Establish dependency provenance controls such as npm provenance attestations, protected publisher accounts, mandatory multifactor authentication, and release signing.
