T08 · Insecure Dependencies
- Location
scripts/deploy.sh:82- Finding
Unpinned Vercel CLI Is Downloaded and Executed at Runtime
- Content
View full analysis
/dev/null 2>&1 || { echo "error: npx not found — install Node.js first" >&2 exit 1 } if ! npx --yes vercel whoami >/dev/null 2>&1; then echo "error: not logged into the Vercel CLI." >&2 echo "run: npx vercel login" >&2 echo "then re-run this script." >&2 exit 1 fi VERCEL_ARGS=(deploy --yes --cwd "$DEPLOY_DIR") $PROD && VERCEL_ARGS+=(--prod) URL="$(npx --yes vercel "${VERCEL_ARGS[@]}" 2>&1 | tail -n1)" ``` The same general pattern also appears in `SKILL.md`, including unversioned commands for `@presentation-md/install`, `skills`, `@presentation-md/render`, and theme packages. ### Technical Analysis The deployment script invokes `npx --yes vercel` without specifying an immutable package version. If the package is not already cached locally, `npx` can retrieve the current release from the configured npm registry and execute it immediately. The `--yes` option suppresses the normal installation prompt. Consequently, the code that executes during deployment is not necessarily the code that existed when this Skill was audited. Its behavior can change due to a compromised package release, compromised maintainer credentials, registry manipulation, or changes to the user's npm registry configuration. The script also invokes the package twice, first for authentication status and then for deployment. Either invocation represents a remote code execution boundary because npm packages and their dependencies execute with the permissions of the current user. ### Attack Path 1. An attacker compromises the `vercel` npm package, one of its dependencies, or the npm account used to publish it. An equivalent attack could target a malicious registry configured through the user's npm settings. 2. The victim or agent invokes `scripts/dep ...[truncated 1286 chars]- Remediation
View remediation
