T08 · Insecure Dependencies
- Location
SKILL.md:31- Finding
Unpinned npm Package Is Downloaded and Executed
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:31,SKILL.md:65,SKILL.md:80, andSKILL.md:109
Vulnerability Type: Unpinned third-party dependency execution
Risk Level: MediumVulnerable Code
bash npm install -g @lark-project/meego-mcporterbash npx @lark-project/meego-mcporter auth meego_btd --config meego-config.jsonbash npx @lark-project/meego-mcporter auth meego_btd --config meego-config.json --oauth-timeout 1000bash npx @lark-project/meego-mcporter call meego_btd <tool_name> --config meego-config.jsonTechnical Analysis
The Skill instructs users or agents to install and execute
@lark-project/meego-mcporterwithout specifying an exact version or verifying package integrity. When no version is specified,npmandnpxordinarily resolve the package version through the configured registry. In particular,npxcan download and immediately execute a package that is not already installed.Consequently, the effective executable code is not fixed to the content reviewed in this Skill. A future package release, compromised publisher account, registry compromise, or unsafe registry configuration could cause different code to execute under the same documented command. The project provides no lockfile, integrity digest, signature verification procedure, or vendored source through which the executed dependency can be matched to an audited release.
This risk is amplified because the downloaded program is intentionally given access to OAuth operations and to
~/.mcporter/credentials.json. Although credential-file access is functionally necessary for the declared OAuth integration and the documentation includes reasonable user-confirmation requirements, those textual constraints cannot restrict a compromised npm package after it starts executing.Attack Path
- An attacker compromises the npm publisher account, package release process, registry ...[truncated 1527 chars]
- Remediation
View remediation
Remediation Suggestions
-
Pin the dependency to an exact reviewed version in every command, for example:
bash npx --yes @lark-project/meego-mcporter@1.0.10 auth meego_btd --config meego-config.jsonThe selected version must be independently reviewed rather than assumed safe from the example.
-
Prefer a normal project installation governed by a committed lockfile over downloading packages implicitly during each invocation.
-
Require integrity verification using a trusted package digest, signed release metadata, or an internally controlled package mirror.
-
Separate installation from execution. Inform the user when a package must be downloaded, obtain explicit approval, verify its source and version, and then invoke the already installed binary.
-
Disable lifecycle scripts during installation where compatible with the package:
bash npm install --ignore-scripts --save-exact @lark-project/meego-mcporter@<reviewed-version> -
Execute the MCP client with least privilege in a restricted environment that exposes only the required configuration and credential file. Do not grant administrative privileges.
-
Restrict
~/.mcporter/credentials.jsonto the owning user, avoid displaying authorized tokens in chat or logs, and use a secure file-transfer channel for the remote OAuth workflow. -
Re-audit dependency updates before changing the pinned version, including transitive dependencies and install scripts.
-
