T08 · Insecure Dependencies
- Location
SKILL.md:162- Finding
Unpinned and Unverified Third-Party Plugin Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, line 162
Vulnerability Type: Insecure third-party dependency installation
Risk Level: SuspiciousVulnerable Code Snippet:
markdown ## Works great with - **OpenClaw** — install the native plugin: `openclaw plugins install snapapi` - **LangChain** — use as a tool via the REST API - **n8n** — HTTP Request node pointing to any endpoint - **AutoGPT / any agent** — standard REST, no SDKs requiredTechnical Analysis
The documented command installs the
snapapiplugin through the OpenClaw package-resolution mechanism without specifying an immutable version, digest, checksum, verified source repository, or signature. Consequently, the code ultimately installed and executed is determined by mutable external registry state rather than by the contents reviewed in this project.The plugin implementation is not included in the audited project, so its provenance, installation hooks, runtime behavior, and requested permissions cannot be verified. This creates a supply-chain exposure: compromise of the registry, takeover of the package or publisher account, dependency confusion, or publication of a malicious future release could cause the same documented command to retrieve attacker-controlled code.
Attack Path
- An attacker compromises the relevant registry entry, publisher account, distribution infrastructure, or upstream package source for
snapapi. - The attacker publishes a malicious release under the package name resolved by
openclaw plugins install snapapi. - A user follows the installation instruction in
SKILL.md. - Because no trusted version or immutable digest is specified, OpenClaw resolves the current externally supplied package.
- The malicious plugin is installed and may execute through installation hooks, plugin initialization, or later invocation.
- The payload operates with the permissions available to the OpenClaw proc ...[truncated 743 chars]
- An attacker compromises the relevant registry entry, publisher account, distribution infrastructure, or upstream package source for
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to a specific, previously audited version rather than resolving the latest release implicitly.
- Prefer an immutable package digest or commit identifier when supported.
- Document the authoritative registry namespace and official source repository so users can verify package provenance.
- Require cryptographic signature or checksum verification before installation.
- Review and document installation hooks, runtime permissions, filesystem access, environment-variable access, and network destinations.
- Publish a lockfile or equivalent integrity metadata for reproducible installation.
- Consider vendoring the reviewed plugin implementation when practical, allowing its behavior to be audited together with the skill.
- Run the plugin with least privilege in an isolated environment, exposing only the credentials and files required for its documented functions.
