T09 · Insecure Skill Coding Practices
- Location
scripts/publish.sh:6- Finding
Execution of an Untrusted Validator Outside the Audited Project
- Content
View full analysis
Vulnerability Details
File Location:
scripts/publish.sh:6-8, 52-54
Vulnerability Type: Untrusted external script execution
Risk Level: MediumVulnerable Code
sh WORKSPACE_ROOT="$(CDPATH= cd -- "$ROOT/../.." && pwd)" CLAWHUB_JSON="$ROOT/clawhub.json" VALIDATOR="$WORKSPACE_ROOT/tmp/validate_clawhub_skill_dir.sh"sh if [ -f "$VALIDATOR" ]; then bash "$VALIDATOR" "$PUBLISH_ROOT" fiTechnical Analysis
The publishing script constructs a validator path outside the project root and executes the file whenever it exists. The validator is not part of the audited artifact, and the script does not verify its ownership, permissions, canonical path, provenance, or cryptographic integrity.
The existence check using
-fonly confirms that the path resolves to a regular file. It does not establish that the file is trusted. A user or process capable of writing to the workspace-leveltmpdirectory can place attacker-controlled shell code at the expected path. That code will then execute with the privileges of the user runningscripts/publish.sh.The validator receives
PUBLISH_ROOTas an argument and runs immediately before publication, giving it an opportunity to read or modify the publication contents in addition to running arbitrary local commands.Attack Path
- An attacker obtains write access to the workspace-level
tmpdirectory derived from"$ROOT/../..". - The attacker creates or replaces
tmp/validate_clawhub_skill_dir.shwith a malicious shell script. - A maintainer runs
sh scripts/publish.sh. - The script confirms only that the external validator path resolves to a file.
bashexecutes the attacker-controlled validator with the maintainer's privileges.- The malicious validator can execute arbitrary commands and alter
PUBLISH_ROOTbeforeclawhub publishruns.
Impact Assessment
Successful exploitation provides arbitrary command execution under the account invoking the publishing script ...[truncated 661 chars]
- An attacker obtains write access to the workspace-level
- Remediation
View remediation
Remediation Suggestions
- Store the validator inside the audited repository and invoke it through a fixed project-relative path.
- If an external validator is required, accept its path only through an explicit, trusted configuration rather than deriving it from a writable workspace directory.
- Resolve the validator to its canonical path and verify that it remains within an approved directory.
- Verify ownership and permissions before execution. Reject validators or parent directories writable by untrusted users.
- Pin and verify a cryptographic hash or signature for the validator before invoking it.
- Avoid silently skipping validation when it is a required publishing control; fail closed if the trusted validator is missing.
- Run validation in a constrained environment with the minimum filesystem and credential access required.
- Ensure the publication directory cannot be modified by the validator unless modification is explicitly necessary; otherwise validate a read-only copy and verify its integrity again immediately before publication.