T08 · Insecure Dependencies
- Location
SKILL.md:46- Finding
Unpinned Third-Party Plugin Is Installed and Granted Tool Access
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 46-48
Vulnerability Type: Unpinned and unaudited third-party dependency
Risk Level: Mediumbash openclaw plugins install clawhub:clawlink-plugin openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartTechnical Analysis
The documented setup installs
clawlink-pluginfrom a mutable package identifier without specifying a version, immutable digest, checksum, or signature-verification procedure. It then explicitly adds the plugin to the tool allowlist and restarts the gateway, activating code that is not included in the audited project.The project calls the plugin “verified,” but the installation workflow provides no locally verifiable integrity evidence. Consequently, the effective plugin code may change independently after this Skill has been reviewed. This creates a supply-chain trust boundary: compromise of the package publisher, registry, distribution channel, or a future plugin release could cause users to install code different from the version originally assessed.
This audit does not establish that the external plugin is malicious. The vulnerability is the unsafe, unpinned installation and activation process combined with the plugin's privileged role in brokering Hostinger credentials and API operations.
Attack Path
- An attacker compromises the plugin publisher account, package registry, release pipeline, or another component serving the mutable
clawlink-pluginpackage. - The attacker publishes a modified package under the same unversioned package identifier.
- A user follows the instructions and runs
openclaw plugins install clawhub:clawlink-plugin. - OpenClaw resolves and installs the attacker-controlled package because no trusted version, digest, or checksum is specified.
- The next command adds the installed plugin to
tools.alsoAllow. - Restarting the gateway loads and a ...[truncated 1084 chars]
- An attacker compromises the plugin publisher account, package registry, release pipeline, or another component serving the mutable
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to a specifically reviewed version rather than installing a mutable latest release.
- Prefer an immutable package digest or content hash when supported.
- Publish an expected cryptographic checksum or signature and verify it before installation.
- Document the authoritative publisher identity, package repository, release provenance, and verification procedure.
- Separate installation from allowlisting: require the user or administrator to verify package integrity and review requested permissions before enabling the plugin.
- Apply least privilege to the plugin, limiting filesystem, network, credential, tool, and Hostinger API access to capabilities strictly required for the requested operation.
- Enforce write confirmation in a trusted layer outside the third-party plugin so a compromised plugin cannot bypass approval requirements.
- Provide rollback, uninstall, credential-revocation, and account-disconnection instructions for incident response.
- Audit the exact pinned plugin source and its transitive dependencies before representing it as verified.
- Establish a controlled update process that requires integrity verification and security review before moving to a newer plugin release.
