T08 · Insecure Dependencies
Warning
- Location
- references/installation.md:80
- Finding
- Unverified npm Package Retrieval and Execution Through npx## Vulnerability Details **File Location**: `references/installation.md`, lines 80-86 **Vulnerability Type**: Supply-chain exposure caused by fetching and executing an npm package without prior verification **Risk Level**: Medium ### Vulnerable Code ```text ### The `npx` route is pinned but unverified The repo's committed `.mcp.json` launches the server with `npx -y -p hostinger-api-mcp@1.8.2` (Step 4). That needs no global install and keeps your PATH clean, and the version is pinned — but npx fetches and executes in one step, **every run**, so there is no point at which the bytes can be compared first. ``` ### Technical Analysis The documented `npx` route downloads and executes `hostinger-api-mcp@1.8.2` in a single operation. Pinning the version reduces unintended version drift, but it does not independently authenticate the package bytes before execution. It also does not lock or verify the complete transitive dependency tree resolved by npm. Consequently, a compromised npm registry response, compromised package release, or malicious transitive dependency could execute code under the local user's account. npm package lifecycle behavior and imported dependency code may run before the MCP server begins normal operation. This exposure is particularly significant because the launched process receives `HOSTINGER_API_TOKEN`. The project states that this token grants full Hostinger account access without per-tool restrictions. A malicious dependency executing in the same process context could read the token from the environment and transmit it externally. The document acknowledges this limitation and supplies a safer tarball-verification alternative, but the unverified route remains documented as a supported zero-setup path. The referenced committed `.mcp.json` was not present in the submitted artifact, so its exact command and configuration could not be independently verified. ### Attack Path 1. An attacker compromises t ...[truncated 1667 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the unverified `npx` route as the default or recommended setup method. Present it only as an explicitly insecure convenience option, if retained at all. 2. Require the existing fetch-verify-install workflow before execution: - Pin the exact package version. - Obtain the expected digest through a trusted out-of-band channel. - Run `npm pack` without executing package code. - Verify the downloaded tarball against the trusted digest. - Install and execute only the verified local artifact. 3. Install the MCP package inside a dedicated project with a committed lockfile rather than relying on global installation or runtime dependency resolution. 4. Verify and lock the full transitive dependency graph. Use `npm ci` against a reviewed lockfile and monitor dependency integrity changes. 5. Disable lifecycle scripts during installation where compatible, such as with `npm install --ignore-scripts`, and explicitly review any scripts that must subsequently be enabled. 6. Run the MCP server under a dedicated, minimally privileged OS account or sandbox with access only to required resources. 7. Supply only the required account token and category binary. Avoid exposing unrelated credentials or sensitive environment variables to the MCP process. 8. Restrict outbound network access to the minimum necessary Hostinger API endpoints after installation. Package-registry access should not be required during routine MCP startup. 9. Add automated dependency scanning, provenance verification, and alerts for unexpected package or lockfile changes. 10. Include verified configuration files in the auditable artifact so the actual startup command can be reviewed rather than relying on documentation claims.