T09 · Insecure Skill Coding Practices
- Location
source/composer.py:67- Finding
Arbitrary Code Execution Through Unsafe Workflow Condition Evaluation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This workflow-composer skill has a coherent purpose, but it can invoke any installed skill and evaluates workflow conditions as Python code, creating review-worthy execution risk.
Install only if you trust the workflow files you will run and are comfortable with a skill that can invoke any installed OpenClaw skill. Prefer previewing workflows first, avoid third-party workflow YAML, and treat this as needing fixes before broad use: replace eval with a strict condition parser, fail closed on invalid conditions, pin dependencies, and restrict callable skills.
source/composer.py:67Arbitrary Code Execution Through Unsafe Workflow Condition Evaluation
install.sh:20Unpinned PyYAML Installation Creates Supply-Chain and Reproducibility Risk
The workflow file is attacker-controlled input, and this code evaluates its if condition with Python eval(). Even with __builtins__ removed, eval on untrusted expressions is unsafe and can often be abused for denial of service or sandbox escape techniques, while the fallback except: return True also causes malformed or malicious conditions to execute steps by default.
condition = condition.replace(placeholder, str(var_value))
# 安全评估
try:
return eval(condition, {"__builtins__": {}})
except:
return True # 默认执行
The skill is explicitly designed to orchestrate execution of other skills and its documentation shows shell-based invocation of a Python runner, yet the manifest declares no tool scope such as permissions or allowed-tools. That means a user or platform cannot easily understand or constrain the file-read and command-execution capabilities implied by the workflow engine, increasing the chance of unexpected downstream file access or side effects from composed skills.
This skill is a workflow composer that chains arbitrary skills, including examples that publish content externally, but the user-facing description does not warn that execution can trigger file writes, external publishing, or other side effects through downstream skills. In this context, missing disclosure is security-relevant because users may treat the composer as a harmless planner when it actually acts as a privileged orchestrator.
The file’s human-readable title and step descriptions are entirely in Chinese, and the pipeline is specifically oriented to Chinese platforms like WeChat and Xiaohongshu without offering a language or locale choice. Under the policy rule, forcing a specific language or locale without user opt-in is a natural-language policy concern unless the regional constraint is explicitly documented and justified.
This manifest contains user-facing natural language almost entirely in Chinese, including the title, step names, and usage notes. Because it does not offer an opt-in language choice or state that the skill is intentionally limited to Chinese-speaking users or a China-specific workflow, it may violate language/locale policy requirements.
This YAML file includes only a high-level description of automating a data report and lists related skills, but it does not specify any explicit trigger phrases, scope limits, or exclusion conditions. In a manifest-style file, that ambiguity can cause the skill to be invoked for loosely related requests about reports or stocks without clear boundaries.
The manifest explicitly declares "skills": ["*"], allowing this composer skill to invoke or orchestrate any installed skill without scope restriction. In an automation/orchestration context, that broad capability increases blast radius: a malicious or unsafe workflow file could chain together high-privilege skills, access sensitive operations indirectly, or bypass intended least-privilege boundaries between skills.
The module docstring is written in Chinese and presents the skill description and inline documentation in that language without any indication that the user can choose another language. This is a natural-language locale policy concern because the file appears to impose a language preference rather than documenting an optional or region-specific constraint.
The workflow engine expands variables into manifest-supplied conditions and then evaluates them as Python expressions, introducing code-execution-like behavior into a data file that should only describe orchestration. This is especially risky because the tool is explicitly designed to compose multiple skills automatically, so a bypassed or malicious condition can trigger unintended downstream actions across the workflow.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
print(f" Args: {args}")
try:
result = subprocess.run(cmd, capture_output=True, text=True, timeout=300)
if result.returncode == 0:
return 'success', result.stdout
else:
The manifest description forces a specific language/locale in user-facing natural language without indicating user choice or that the skill is restricted to a Chinese-speaking audience. Under the policy, locale-specific language should be optional or clearly justified.
The entire SKILL.md is presented in Chinese, and there is no note that the skill is region- or locale-specific, nor any offer of alternative language support. This can violate language/locale policy when users are not given a choice.
The file's user-facing descriptive comments are entirely in Chinese, which implicitly fixes the skill's language context without offering any user choice or documenting a justified locale restriction. This can conflict with organizational language/locale policy when users have not opted into that language.
The natural-language description is written solely in Chinese, and the manifest does not indicate that language choice is optional or region-specific. This can violate language/locale policy expectations when a skill is presented to a broader user base without opt-in or justification.