OpenClaw LLM Tools

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

Overview

The skill is not malicious, but it asks for broad read/write/exec authority and includes unsafe integration examples that users should review carefully before installing.

Review this skill before installing. It appears intended for tool schema conversion and registration, not hidden abuse, but it requests broad authority and its examples include unsafe patterns. Do not copy the eval() handler into production, constrain any file-reading handlers to approved paths, and consider removing exec permission or installing only in a sandboxed environment with pinned dependencies.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:188

Finding

Documentation Encourages Arbitrary Code Execution Through eval()

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:188-196
Vulnerability Type: Unsafe evaluation of potentially LLM-controlled input
Risk Level: High

Vulnerable Code

python

tool = Tool(
    name="calculate",
    description="Perform mathematical calculation",
    parameters={
        "type": "object",
        "properties": {
            "expression": {"type": "string"}
        },
        "required": ["expression"]
    },
    handler=lambda expr: eval(expr)  # optional
)

Technical Analysis

The documented tool handler passes its expr argument directly to Python's eval() function. Tool arguments commonly originate from an LLM response and therefore must be treated as untrusted input.

eval() does not restrict input to arithmetic. It can evaluate Python expressions that import modules, access application objects, read files, or invoke operating-system functionality. The registry's validation only confirms that expression is a string; it does not inspect or constrain the content of that string.

This code is documentation rather than an automatically registered handler in the reviewed implementation. Exploitation therefore depends on a user adopting the example. Nevertheless, it presents an unsafe integration pattern as part of the Skill's API documentation.

Attack Path

1. A developer follows the documented example and registers the calculate tool.
2. An attacker influences an LLM prompt or tool call and supplies a malicious Python expression as expression.
3. ToolRegistry.validate_call() accepts the value because it is a string.
4. ToolRegistry.execute() invokes the registered handler with the supplied expression.
5. The handler calls eval(expr).
6. The expression executes with the privileges and environment access of the Agent process.

Impact Assessment

Successful exploitation can result in arbitrary Python code execution within the hosting pro ...[truncated 342 chars]

Remediation

View remediation

Remediation Suggestions

• Remove the eval() example from the documentation.
• For arithmetic expressions, use a dedicated expression parser that cannot access Python names, attributes, imports, function calls, or application objects.
• If implementing an AST-based evaluator, explicitly allow only numeric constants and required arithmetic operators. Reject every node type not on the allowlist.
• Apply input length, nesting-depth, and computational-complexity limits to prevent resource-exhaustion attacks.
• Add tests proving that imports, attribute traversal, function calls, comprehensions, and excessively complex expressions are rejected.
• Run tool handlers in a sandbox with minimal filesystem, credential, process, and network access as a defense-in-depth measure.

T09 · Insecure Skill Coding Practices

Warning

• Location: lib/registry.py:121

Finding

Incomplete Tool Argument Validation Allows Schema Constraint Bypass

Content

View full analysis

Vulnerability Details

File Location: lib/registry.py:121-145 and lib/registry.py:185-200
Vulnerability Type: Incomplete and fail-open input validation
Risk Level: Medium

Vulnerable Code

python

def validate_call(self, name: str, arguments: Dict[str, Any]) -> tuple[bool, Optional[str]]:
    """Validate tool call arguments"""
    tool = self._tools.get(name)
    if not tool:
        return False, f"Tool not found: {name}"
    
    # Check required parameters
    required = tool.parameters.get("required", [])
    for param in required:
        if param not in arguments:
            return False, f"Missing required parameter: {param}"
    
    # Check parameter types
    properties = tool.parameters.get("properties", {})
    for key, value in arguments.items():
        if key in properties:
            expected_type = properties[key].get("type")
            if expected_type and not validate_type(value, expected_type):
                return False, f"Invalid type for {key}: expected {expected_type}"
    
    return True, None

python

def validate_type(value: Any, expected_type: str) -> bool:
    """Validate value matches expected type"""
    type_map = {
        "string": str,
        "integer": int,
        "number": (int, float),
        "boolean": bool,
        "array": list,
        "object": dict
    }
    
    expected = type_map.get(expected_type)
    if expected is None:
        return True  # Unknown type, allow
    
    return isinstance(value, expected)

Technical Analysis

The validator only checks required property names and a small set of top-level Python types. It does not implement the JSON Schema validation advertised by the project.

The following constraints can be bypassed:

• Unknown schema types are accepted because validate_type() returns True when no type mapping exists.
• Arguments not declared unde ...[truncated 1780 chars]

Remediation

View remediation

Remediation Suggestions

• Use the declared jsonschema dependency to validate arguments against the complete registered schema.
• Select and document an explicit JSON Schema draft and use the corresponding validator class.
• Validate each tool schema during registration with check_schema() and reject malformed or unsupported schemas.
• Default object schemas to rejecting unexpected properties where appropriate, or require tool authors to make the additionalProperties policy explicit.
• Reject unknown schema types rather than allowing them.
• If custom type validation remains, explicitly exclude bool from integer and number checks.
• Enforce nested object schemas, array item schemas, enumerations, length limits, numeric bounds, and other declared constraints.
• Return normalized validation errors without exposing unnecessary internal details.
• Add regression tests for unknown types, extra arguments, invalid enum values, nested schema failures, and Boolean-as-integer inputs.

T08 · Insecure Dependencies

Note

• Location: requirements.txt:1

Finding

Unbounded and Unlocked Third-Party Dependency

Content

View full analysis

Vulnerability Details

File Location: requirements.txt:1-4 and SKILL.md:142-146
Vulnerability Type: Non-reproducible dependency installation and avoidable supply-chain exposure
Risk Level: Low

Vulnerable Code

text

# LLM Tools Dependencies

# JSON Schema validation
jsonschema>=4.0.0

bash

pip3 install -r requirements.txt

Technical Analysis

The dependency specification has only a lower version bound and does not use a lockfile or package hashes. Following the installation instructions may therefore install any future compatible release selected by the package resolver, together with changing transitive dependencies.

This makes builds non-reproducible and allows dependency behavior to change without review of this project. The current implementation does not import or use jsonschema, so the installation expands the dependency and supply-chain attack surface without currently delivering the advertised schema validation.

No evidence was found that jsonschema is malicious or typosquatted. The finding concerns unsafe dependency management rather than a confirmed malicious package.

Attack Path

1. A user follows the installation instructions.
2. The package resolver selects the latest release satisfying the unbounded jsonschema>=4.0.0 constraint and resolves its transitive dependencies.
3. A future compromised, vulnerable, or behaviorally incompatible release can be installed without changes to this repository.
4. Installation-time or runtime package behavior executes in the user's Python environment when the dependency is installed or used.

Impact Assessment

The primary impacts are reduced build integrity, non-reproducible environments, unexpected compatibility changes, and unnecessary supply-chain exposure. If a selected package or transitive dependency were compromised, impact would be governed by the privileges used during installation and execution. Th ...[truncated 74 chars]

Remediation

View remediation

Remediation Suggestions

• Remove jsonschema until the implementation actually uses it, or integrate it into argument validation.
• Pin an audited version rather than using only a lower bound.
• Maintain a lockfile that includes resolved transitive dependency versions.
• Use cryptographic hashes for reproducible installation, such as a requirements file generated with pip-compile --generate-hashes.
• Run dependency vulnerability and license scans in continuous integration.
• Review and deliberately update pinned dependencies on a controlled schedule.
• Install dependencies in an isolated virtual environment using an unprivileged account.

SkillSpector

Vulnerability Patterns

• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Behavioral AST: exec() Call, eval() Call, Dynamic Import
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration

Findings (5)

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 90% confidence

Finding

The skill metadata declares broad tools (read, write, exec) but does not document a constrained permission model such as allowed paths, execution limits, or explicit scope boundaries. In a tool-definition skill that also demonstrates file access and callable handlers, this omission increases the risk of downstream over-privileged use, accidental unsafe integration, or abuse by an LLM-driven agent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

The skill advertises write and exec capabilities in metadata without any user-facing warning that the skill may modify files or run commands. This can mislead users or orchestrators into enabling a potentially destructive skill without understanding the operational risk, especially because the purpose is generic and reusable across many contexts.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 84% confidence

Finding

The examples show dynamic tool registration and file-reading behavior in an integration context without any safety notes about validating paths, limiting accessible resources, or guarding execution handlers. Although presented as sample code, such examples normalize unsafe patterns and may be copied directly into production agent skills, enabling arbitrary file access or dangerous tool execution flows.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The skill documentation is predominantly in Chinese while also targeting multiple providers and general usage, but it does not offer a language choice or explain a region-specific requirement. This is a natural-language locale policy issue because the skill appears to impose a specific language without user opt-in.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low

• Category: Supply Chain
• Confidence: 93% confidence

Finding

The dependency is only minimally constrained with a lower bound, which makes builds non-reproducible and allows future versions of jsonschema to be pulled in automatically. If an upstream release is compromised, vulnerable, or introduces unsafe breaking behavior, downstream users may unknowingly install it.

Content

Scanner excerpt · requirements.txt (reported line 4)May include surrounding context.

text

# LLM Tools Dependencies

# JSON Schema validation
jsonschema>=4.0.0

# Optional: YAML support
# PyYAML>=6.0