T08 · Insecure Dependencies
- Location
SKILL.md:46- Finding
Unpinned Privileged Third-Party Plugin Dependency
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 46–48
Vulnerability Type: Unpinned third-party dependency with privileged tool access
Risk Level: MediumVulnerable Code
bash openclaw plugins install clawhub:clawlink-plugin openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartThe privileged configuration and restart commands are also repeated at lines 314–315:
bash openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartTechnical Analysis
The Skill instructs the user to install
clawhub:clawlink-pluginwithout specifying an immutable version, cryptographic digest, or verified signature. It then explicitly adds that plugin to the OpenClaw tool allowlist and restarts the gateway so the component becomes active.The plugin implementation is not included in the audited project, which contains only
SKILL.md; therefore, its behavior and security properties cannot be independently reviewed from this artifact. The documented architecture states that ClawLink proxies API requests, while line 70 states that it stores and injects the user's Kit OAuth token. Consequently, this mutable dependency operates across a sensitive authentication and data-access boundary.Exploitation depends on compromise, replacement, or malicious publication of the externally distributed plugin. There is no evidence in the audited file that the current plugin is malicious.
Attack Path
- An attacker compromises the plugin publisher, distribution account, registry entry, or mutable plugin release.
- The attacker publishes a modified build under the same unversioned
clawhub:clawlink-pluginidentifier. - A user follows the Skill instructions and installs the current mutable release.
- The user adds the plugin to
tools.alsoAllow. - Restarting the OpenClaw gateway loads the compromised component.
- The component can abuse its role in authenticated K ...[truncated 677 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to a specific, audited version rather than a mutable package identifier.
- Require a cryptographic digest or verified publisher signature and validate it before installation.
- Publish or vendor the plugin source and reproducible build instructions so its behavior can be independently audited.
- Grant only the minimum tools and permissions needed for Kit operations instead of broadly trusting the plugin.
- Isolate the plugin and restrict its filesystem, network, process, and credential access where the platform supports sandboxing.
- Document the external credential trust boundary, token storage protections, retention policy, revocation procedure, and incident-response process.
- Require explicit user approval before installation, allowlist modification, gateway restart, or credential connection.
- Monitor dependency updates and security advisories, and require security review before changing the pinned release.
