T08 · Insecure Dependencies
- Location
SKILL.md:20- Finding
Unpinned Package Download and Execution Through npx
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill appears to provide the promised NOAA marine-weather MCP tool, but its documented setup runs an unpinned third-party package through npx, so users should review the package source and version before installing.
Install only after pinning the npx command to a reviewed exact package version and confirming the package identity. The weather functionality itself is narrow and NOAA-focused, but the current setup gives the npm registry-selected package normal local code execution authority.
SKILL.md:20Unpinned Package Download and Execution Through npx
Yes, this is a mismatch. The declared description promises a functioning marine weather integration using NOAA's api.weather.gov, but the provided code chunk contains no such logic. It is essentially an empty declaration file and does not demonstrate any of the stated capabilities, resources, or behavior. Based on the supplied code alone, the actual behavior does not match the declared purpose.
The skill invokes an MCP server via npx, which inherently enables outbound network access and may expose environment data, yet the manifest declares no permissions or allowed-tools scope. This weakens least-privilege controls and makes it harder for operators or automated policy systems to understand and constrain what the skill can do at runtime.
The setup uses npx -y @vbotholemu/mcp-marine-weather without pinning an exact package version. This creates a supply-chain risk because future package updates—or a compromised published version—could execute different code than the reviewed skill, including arbitrary malicious behavior at install/run time.
The dependency uses a caret range (^1.12.1), which allows automatic installation of newer minor/patch releases. This weakens build reproducibility and can unexpectedly introduce vulnerable or malicious upstream changes through the supply chain, especially for a network-facing MCP SDK dependency.
"author": "velocibot",
"license": "MIT",
"dependencies": {
"@modelcontextprotocol/sdk": "^1.12.1",
"zod": "^3.23.0"
},
"devDependencies": {
The manifest references @modelcontextprotocol/sdk with a non-exact version while known advisories exist for that package, so the actual installed version may be affected and cannot be verified from this file alone. In an MCP skill, the SDK is a core runtime component handling protocol and transport behavior, which makes known issues such as data leakage, ReDoS, or DNS rebinding more relevant than in a non-networked package.
The zod dependency is specified with a caret range, so different installs may resolve to different package versions over time. While common in JavaScript projects, this creates avoidable supply-chain and reproducibility risk if an upstream release introduces a security issue or regression.
"license": "MIT",
"dependencies": {
"@modelcontextprotocol/sdk": "^1.12.1",
"zod": "^3.23.0"
},
"devDependencies": {
"typescript": "^5.7.0",
zod has a known DoS advisory, and because the manifest uses a version range instead of an exact version, it is not possible to confirm whether deployed installations are patched. Since this skill likely validates external NOAA-derived or user-supplied inputs, a vulnerable parser could make malformed input a denial-of-service vector, though the overall impact is limited by the simple weather-tool context.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"zod": "^3.23.0"
},
"devDependencies": {
"typescript": "^5.7.0",
"@types/node": "^22.0.0"
}
}
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
},
"devDependencies": {
"typescript": "^5.7.0",
"@types/node": "^22.0.0"
}
}