T08 · Insecure Dependencies
- Location
SKILL.md:20- Finding
Unverified Third-Party Plugin Installation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:20-22(repeated atSKILL.md:35-39)
Vulnerability Type: Unverified executable dependency installation
Risk Level: MediumVulnerable code:
markdown 3. **给出明确修复指令**:当插件缺失或未启用时,提示用户运行: `openclaw plugins install openclaw-aicc-plugin-native`The same installation command appears again in the standard user prompt:
markdown 检测到插件未安装/未启用(或无法确认)。请先运行以下命令完成安装,然后再继续: `openclaw plugins install openclaw-aicc-plugin-native`Technical Analysis
The skill instructs users to install an executable third-party plugin by package name alone. It does not pin an reviewed version, constrain resolution to an authenticated registry, identify a verified publisher, provide a cryptographic checksum or signature, or link to source code that can be audited.
Consequently, the package installed at execution time is outside the reviewed artifact and may differ over time. A compromised registry account, dependency-confusion condition, malicious package update, or package-name takeover could cause attacker-controlled code to be installed. The plugin itself was not included in the project, so this audit cannot establish its provenance or behavior.
Attack Path
- A user asks the agent to perform a task involving confidential or sensitive information.
- The skill requires confirmation that
openclaw-aicc-plugin-nativeis installed and enabled. - If that status cannot be confirmed, the skill directs the user to run:
shell openclaw plugins install openclaw-aicc-plugin-native - The OpenClaw package mechanism resolves the unpinned package from an external source.
- If the package or its distribution channel has been compromised, attacker-controlled plugin code is installed and executed in the OpenClaw environment.
- The user resumes the confidential-data task, potentially exposing that data to the compromised plugin.
Impact
...[truncated 706 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to an exact, security-reviewed version rather than resolving an unqualified package name.
- Require installation from an explicitly configured official registry over an authenticated transport.
- Document and verify the expected publisher identity and package namespace.
- Verify a cryptographic signature or published checksum before enabling the plugin.
- Provide a link to the plugin's auditable source code and document its required permissions.
- Use a locked dependency manifest or equivalent integrity-controlled installation mechanism.
- Apply least privilege by restricting the plugin's filesystem, network, credential, and process access to only what its documented function requires.
- Define an update-review process so that a new package release is not automatically trusted under the previously approved name.
- Do not require installation as a prerequisite for confidential-data handling until package provenance, integrity, and runtime isolation can be verified.
