T03 · Remote Payload Retrieval and Execution
Error
- Location
SKILL.md:16- Finding
Execution of Mutable Remote Code Without Version Pinning
- Content
View full analysis
npx @larksuite/cli@latest install lark-cli auth login --recommend ``` ### Technical Analysis The Skill directs users and AI Agents to retrieve and execute `openapi-lark` directly from a mutable GitHub repository reference. It does not specify an immutable commit hash or a cryptographically verified release. It also installs the Lark CLI through the mutable `@latest` package tag. Consequently, the code executed at runtime may differ from the code that existed when this Skill was reviewed. The implementation of the downloaded `openapi-lark` package is not included in the audited artifact, so its actual behavior cannot be independently verified from this project. This is particularly sensitive because the downloaded program is expected to run inside project repositories and authenticated CI environments. The documented environment can contain: - Lark application IDs and application secrets. - Lark authentication tokens and document permissions. - OpenAPI authorization headers. - Repository files and configuration. - CI credentials and other environment variables. - Permission to modify Lark wiki and docx content. The use of an official package name for the Lark CLI reduces some provenance risk but does not mitigate the mutable-version problem created by `@latest`. ### Attack Path 1. An attacker compromises the referenced GitHub repository, its maintainer account, the relevant package publication channel, or an upstream dependency. 2. The attacker modifies the payload referenced by the repository default branch or the `@latest` package tag. 3. A user, Agent, developer hook, or CI job follows the Skill instructions and invokes the documented `npx` command. ...[truncated 1081 chars]- Remediation
View remediation
openapi-lark ``` 2. Pin the Lark CLI to an exact reviewed version instead of using `@latest`. 3. Prefer signed releases and verify release signatures or checksums before execution. 4. Use a package lockfile and integrity metadata where supported. 5. Vendor or include the executable implementation in the audited project when feasible. 6. Review dependency changes before updating the pinned revision. 7. Run the synchronization process in a restricted CI environment with: - Minimal filesystem access. - Repository-scoped credentials. - Narrow Lark scopes. - No unrelated secrets in the process environment. - Restricted outbound network access. 8. Separate read-only lookup credentials from document synchronization credentials. 9. Require explicit review before allowing a dependency update to execute in CI. ]]>