T08 · Insecure Dependencies
Warning
- Location
- SKILL.md:9
- Finding
- Execution of an Unpinned Third-Party npm Package## Vulnerability Details **File Location**: `SKILL.md`, lines 9-11 **Vulnerability Type**: Unpinned third-party dependency execution **Risk Level**: Medium ### Vulnerable Code ```yaml allowed-tools: - "Bash(npx agnic@latest status*)" - "Bash(npx agnic@latest email *)" ``` The same mutable package reference is used throughout the documented commands, including: ```bash npx agnic@latest status --json npx agnic@latest email setup --display-name "My Agent" --json npx agnic@latest email address --json npx agnic@latest email inbox --limit 10 --json npx agnic@latest email send --to <address> --subject "<subject>" --body "<body>" npx agnic@latest email reply --message-id <id> --body "<reply text>" ``` ### Technical Analysis The Skill authorizes direct execution of `agnic@latest` through `npx`. The `latest` npm distribution tag is mutable, so the code executed during a future invocation is not necessarily the code that existed when the Skill was audited. The project provides neither a fixed package version nor lockfile integrity metadata. If the package publisher, npm account, release pipeline, package namespace, or registry resolution path is compromised, an attacker could publish a malicious version under the `latest` tag. A subsequent Skill invocation could download and execute that version with the privileges and environment of the Agent process. This risk is particularly relevant because the CLI handles authentication and email operations. Its process may receive `AGNIC_TOKEN` through the environment or command line and may process email addresses, subjects, message bodies, inbox contents, and message identifiers. ### Attack Path 1. An attacker compromises the `agnic` npm publisher account, package release pipeline, or another relevant dependency-distribution component. 2. The attacker publishes a malicious release and assigns it to the mutable `latest` tag. 3. A user as ...[truncated 1154 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `agnic@latest` with a specifically reviewed and approved version, such as `agnic@X.Y.Z`. 2. Install the package as a project dependency using a lockfile that records exact transitive versions and registry integrity hashes. 3. Invoke the locally installed, locked binary rather than allowing `npx` to resolve and download a package dynamically on every use. 4. Verify npm package ownership, release provenance, signatures or attestations, and integrity before approving upgrades. 5. Perform dependency and package-content review whenever the pinned version is changed. 6. Run the CLI in a restricted environment with minimal filesystem permissions, a network allowlist, and only the environment variables required for the requested operation. 7. Supply `AGNIC_TOKEN` through a scoped secret manager and avoid the `--token` command-line option, which may expose the token through process listings or shell history. 8. Use a narrowly scoped, revocable token where supported, and rotate it immediately if package compromise is suspected.