T08 · Insecure Dependencies
Error
- Location
- references/cli-guide.md:5
- Finding
- Unpinned npm Package Is Downloaded and Executed at Runtime<![CDATA[ ## Vulnerability Details **File Location**: `references/cli-guide.md:5-10`; repeated throughout `SKILL.md:34-318` and the reference documentation **Vulnerability Type**: Runtime execution of a mutable third-party dependency **Risk Level**: High ### Vulnerable Code ```bash npx @lark-project/meegle@latest <resource> <method> [flags] --format json ``` Representative invocation from `SKILL.md`: ```bash npx @lark-project/meegle@latest project search ``` Authentication operations use the same mutable dependency: ```bash npx @lark-project/meegle@latest auth status --format json ``` ```bash npx @lark-project/meegle@latest auth login --device-code --phase init --host $host --format json ``` ### Technical Analysis The Skill directs the Agent to execute `@lark-project/meegle@latest` through `npx` for nearly every operation. The `latest` npm distribution tag is mutable and does not identify the package version that was reviewed when this audit was performed. When the package is absent from the local npm cache, `npx` can retrieve it from the configured npm registry and immediately execute its entry point. Consequently, the effective executable payload can change without any modification to this Skill. Even if the current package release is legitimate, a compromised maintainer account, malicious future publication, registry compromise, or unintended release can introduce arbitrary code into subsequent Skill runs. This is particularly sensitive because the invoked package handles Device Code authentication, token storage, local attachment paths, signed object-storage URLs, project records, comments, users, and workflow mutations. The remotely resolved npm package was not included in the audited project, so its implementation and transitive dependencies could not be verified. ### Attack Path 1. An attacker compromises the npm publisher account, publication pipeline, package registry, or another component capable of changing the `latest` release of `@lark- ...[truncated 1470 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace every use of `@lark-project/meegle@latest` with an exact, reviewed version: ```bash npx --yes @lark-project/meegle@0.1.1 <resource> <method> [flags] --format json ``` 2. Prefer installing the dependency through a committed lockfile rather than downloading it during each operation: ```bash npm install --save-exact @lark-project/meegle@0.1.1 npm ci ``` 3. Invoke the lockfile-resolved local executable: ```bash ./node_modules/.bin/meegle <resource> <method> [flags] --format json ``` 4. Commit `package-lock.json` and enforce lockfile integrity in deployment and CI. Reject dependency changes that are not explicitly reviewed. 5. Audit the resolved package source, lifecycle scripts, CLI entry point, and transitive dependency tree before deployment. 6. Use an approved registry and package allowlist. Where supported, verify package provenance and registry signatures. 7. Disable or tightly control npm lifecycle scripts unless the audited package explicitly requires them. 8. Run the CLI with least privilege in a sandbox that restricts filesystem access, environment variables, network destinations, and child-process execution. 9. Keep authentication storage isolated from unrelated Agent tools and ensure token files have restrictive operating-system permissions. 10. Establish a controlled update process in which new versions are reviewed, tested, pinned, and deliberately promoted rather than automatically selected through `latest`. ]]>