T08 · Insecure Dependencies
- Location
main.js:268- Finding
Unverified GitHub Repositories Can Be Installed as Trusted Skills
- Content
View full analysis
Vulnerability Details
File Location:
main.js:268-290
Vulnerability Type: Unsafe third-party component installation
Risk Level: HighVulnerable Code
javascript async function installFromGitHub(repo, name) { log(`\nInstalling ${name} from GitHub...`, 'cyan'); const skillsDir = path.join(__dirname, '..'); const targetDir = path.join(skillsDir, name); if (fs.existsSync(targetDir)) { log(`Skill "${name}" already exists`, 'yellow'); return false; } const cmd = `git clone https://github.com/${repo}.git "${targetDir}"`; return new Promise((resolve) => { exec(cmd, (error) => { if (error) { err(`Failed to install: ${error.message}`); resolve(false); return; } log(`Installed to ${targetDir}`, 'green');Technical Analysis
The application searches GitHub for repositories based on user-supplied keywords and allows a selected repository to be cloned directly into the active skills directory. Before installation, it does not:
- Restrict repositories to trusted owners or an approved registry.
- Pin the installation to an immutable commit.
- verify a signature, checksum, or release provenance.
- Inspect executable files or skill instructions.
- Require a security review before making the downloaded repository available as a skill.
The search relevance threshold is only a textual similarity measure and provides no assurance about repository authenticity or safety. An attacker can create a repository whose name and description contain expected OpenClaw keywords so that it appears in search results.
Although this function clones rather than directly executes the repository, installed skills are components intended to be loaded or invoked later. Consequently, mutable, unverified remote content is introduced into a trusted execution environment.
Attack Path
- An attacker publishes a GitHub repository with a name and description matching a commonly searched ...[truncated 1190 chars]
- Remediation
View remediation
Remediation Suggestions
- Restrict installation to an allowlist of verified repository owners and repositories, or use a curated skill registry.
- Resolve the selected repository to an immutable commit and clone or check out that exact revision.
- Display the complete repository owner, URL, commit hash, and verification status before requesting explicit installation approval.
- Verify signed commits or releases where available and validate downloaded content against trusted checksums.
- Stage repositories in a quarantine directory instead of immediately placing them in the active skills directory.
- Scan staged content for executable scripts, dangerous lifecycle hooks, suspicious instructions, symbolic links, and secret-access behavior.
- Require a separate activation step after review.
- Run third-party skills in a sandbox with minimal filesystem, network, environment-variable, and tool permissions.
- Prefer
spawnorexecFilewith separate arguments over constructing a shell command, even after repository validation.
