T08 · Insecure Dependencies
Warning
- Location
references/mcp-setup.md:18- Finding
Unpinned Third-Party Packages Executed Through npx
- Content
View full analysis
``` ### Technical Analysis Both setup methods instruct users to download and execute third-party registry packages without pinning them to reviewed versions or verifying their integrity. The first command explicitly selects `xcodebuildmcp@latest`, allowing the executed package contents to change after this Skill has been audited. The second command does not specify a version for `@smithery/cli`, so the package manager resolves the current registry version at execution time. In both cases, `npx -y` suppresses the normal confirmation prompt. This creates a time-of-use supply-chain risk. A compromised maintainer account, malicious package release, registry compromise, dependency confusion event, or compromised transitive dependency could cause different and potentially malicious code to execute under the same documented command. The documentation provides no exact version, integrity hash, signature, lockfile, or canonical source URL that users can use to verify the retrieved artifacts. This finding does not establish that either named package is currently malicious. It identifies that the installation process does not constrain or authenticate the code that will be executed. ### Attack Path 1. An attacker compromises a package maintainer account, registry publication process, package release, or transitive dependency. 2. The attacker publishes a malicious version under the package name used by the documented command. 3. A user follows the setup instructions afte ...[truncated 1421 chars]- Remediation
View remediation
"] } } } ``` Similarly, pin the Smithery CLI: ```text npx @smithery/cli@ install xcodebuildmcp --client ``` 2. Remove `-y` where interactive confirmation is practical so unexpected package installation is not silently approved. 3. Record and verify package integrity hashes or signatures before execution. Where possible, use a committed lockfile and a reproducible installation process. 4. Add canonical package registry and source-repository URLs so users can verify package identity and provenance. 5. Review the pinned package and its dependency tree before recommending it, and use automated dependency monitoring to identify compromised or vulnerable releases. 6. Prefer installing packages in a constrained environment with only the filesystem and credentials required for setup. Do not run these commands with elevated privileges. 7. Document a controlled upgrade procedure requiring review and integrity verification before changing the pinned versions. ]]>