Weclaw Installer

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:14 AM UTC
• Version: 1.0.0

Overview

The skill is a WeClaw installer, but its setup wrapper can load unaudited Python code from outside the packaged skill while handling an API key.

Review before installing. Only run this in a trusted checkout where you can inspect setup_package.py, avoid passing real API keys on the command line, and enable macOS Accessibility only if you are comfortable granting the terminal or agent desktop automation control for WeClaw setup.

A.I.G

Vulnerability Patterns

• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/run_setup.py:6

Finding

Unsafe External Module Loading from a Shared Writable Directory

Content

View full analysis

Vulnerability Details

File Location: scripts/run_setup.py:6-7, 22-30
Vulnerability Type: Python module search-path hijacking
Risk Level: High

Vulnerable Code

python

def _repo_root() -> Path:
    return Path(__file__).resolve().parents[3]

python

    repo_root = _repo_root()
    sys.path.insert(0, str(repo_root))

    try:
        from setup_package import setup_openclaw_package  # type: ignore
    except Exception as e:
        print(f"STATUS: FAILED. Could not import setup_package.py: {e}")
        return 1

    result = setup_openclaw_package(
        api_key=args.api_key,
        mac_permission_confirmed=bool(args.mac_permission_confirmed),
    )

Technical Analysis

In the audited directory layout, the script is located at:

text

/tmp/clawhub-codex-scan-v57bx59bfkbyn5fe24xvwrtktx8egd74-n00wnX/artifact/scripts/run_setup.py

Path(__file__).resolve().parents[3] therefore resolves to /tmp, rather than the project or Skill root. The script inserts this shared temporary directory at index zero of sys.path, giving it precedence during Python module resolution.

The subsequent import of setup_package can consequently load /tmp/setup_package.py. This module is not included in the audited project, and its integrity, origin, and behavior are not verified. Importing a Python module executes its top-level code immediately.

The imported function also receives the API key supplied by the user. A malicious module can therefore execute arbitrary Python code and directly capture the secret.

Attack Path

1. An attacker obtains the ability to create /tmp/setup_package.py, such as through another compromised process or an unsafe temporary-file workflow.
2. The attacker defines malicious top-level code or a malicious setup_openclaw_package function in that file.
3. The user follows SKILL.md and invokes python3 scripts/run_setup.py, potentially ...[truncated 862 chars]

Remediation

View remediation

Remediation Suggestions

• Package setup_package.py inside the audited project and import it through a package-relative import.
• Derive the project root from the actual package layout rather than using a fixed and incorrect parent depth.
• Do not prepend /tmp or any other shared writable directory to sys.path.
• Resolve the expected module path explicitly and verify with Path.resolve() that it remains within the trusted project directory.
• Fail closed when the trusted installer module is missing instead of searching external locations.
• If dynamic module loading is unavoidable, verify the module against a pinned cryptographic hash or trusted signature before execution.
• Add a regression test that asserts the calculated root equals the expected project directory and that imports cannot resolve from /tmp.
• Avoid passing secrets to unaudited extension modules; keep secret handling inside a trusted, packaged implementation.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:60

Finding

API Key Exposed Through Command-Line Arguments

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:60-66 and scripts/run_setup.py:12
Vulnerability Type: Sensitive data exposure through process arguments and shell history
Risk Level: Medium

Vulnerable Code

SKILL.md instructs users to place the API key directly in the command line:

bash

python3 scripts/run_setup.py --api-key "<KEY>"

bash

python3 scripts/run_setup.py --api-key "<KEY>" --mac-permission-confirmed

The script accepts the secret as a normal command-line argument:

python

    parser.add_argument("--api-key", default=None, help="API key for setup")

Technical Analysis

Command-line arguments are not an appropriate channel for long-lived secrets. Depending on operating-system configuration, process arguments may be visible to other local processes or users through process-inspection tools while the installer is running. The complete command may also be retained in shell history, terminal logs, automation logs, diagnostic captures, or command auditing systems.

Although argparse does not print the argument value in standard help output, it cannot prevent exposure caused by the operating system or shell because the secret is already present in the process invocation.

Attack Path

1. A user follows the documented setup command and substitutes a real API key for the placeholder.
2. The shell records the command in history, or the operating system exposes the process argument while the installer is running.
3. A local attacker, support utility, monitoring agent, log collector, or later user of the same account reads the recorded command or process information.
4. The exposed API key is reused against the service for which it is valid.

Impact Assessment

Exploitation can disclose the WeClaw-related API credential. The resulting access is limited by the permissions assigned to that key, but may include unauthorized API calls, access to as ...[truncated 186 chars]

Remediation

View remediation

Remediation Suggestions

• Remove examples that place API keys directly in command-line arguments.
• Read the key from an environment variable with a clearly documented name, while warning users not to store it in shell startup files or committed configuration.
• Prefer an interactive hidden prompt using getpass.getpass() when a key is not supplied through a protected secret provider.
• For automation, support reading the key from standard input, an inherited file descriptor, or an operating-system credential store.
• If a .env file is required, create it with owner-only permissions, ensure it is excluded from version control, and avoid printing its content.
• Retain temporary compatibility for --api-key only with a security warning and deprecate the option.
• Ensure exception messages, status output, and logs never include the supplied key.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.