T08 · Insecure Dependencies
- Location
SKILL.md:47- Finding
Unpinned Third-Party Plugin Installation and Enablement
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 47–49; equivalent configuration commands are repeated at lines 283–284
Vulnerability Type: Unpinned third-party dependency loaded into the OpenClaw gateway
Risk Level: MediumVulnerable Code Snippet:
bash openclaw plugins install clawhub:clawlink-plugin openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartThe configuration and restart commands are repeated in the troubleshooting instructions:
bash openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartTechnical Analysis
The Skill instructs users to install an executable third-party plugin by package name without specifying an immutable version, cryptographic digest, or explicit signature-verification procedure. It then adds the plugin to the permitted tool list and restarts the gateway, causing the downloaded component to be loaded.
Consequently, the effective executable implementation is not contained in the audited project and may change independently after this
SKILL.mdfile has been reviewed. A compromise of the publisher account, registry, release process, or distribution channel could replace a legitimate plugin release with malicious code.This finding is limited to supply-chain exposure. The audited file openly discloses that ClawLink handles OAuth credentials and proxies GitLab requests; no evidence in the inspected project proves malicious credential exfiltration or an existing compromise.
Attack Path
- An attacker compromises the plugin publisher, package registry entry, release pipeline, or another relevant distribution component.
- The attacker publishes a modified
clawlink-pluginunder the same mutable package reference. - A user follows the Skill's installation command, which does not pin a known-good version or digest.
- The user adds the downloaded plugi ...[truncated 984 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to an immutable, reviewed version rather than installing a mutable package reference.
- Verify a publisher signature and cryptographic digest before enabling the plugin.
- Publish the expected version, digest, signing identity, source repository, and reproducible-build provenance in the Skill documentation.
- Require users to review the plugin's requested permissions and the
tools.alsoAllowchange before installation. - Apply least privilege by exposing only the GitLab operations necessary for the requested task.
- Sandbox the plugin and restrict its filesystem, process, network, credential, and unrelated tool access.
- Use narrowly scoped and revocable GitLab authorization, and document token revocation and plugin-removal procedures.
- Avoid automatically restarting the gateway until package verification and permission review have completed.
- Add integrity monitoring and an update policy that requires renewed review when the pinned plugin version changes.
