Oc Call

• Outcome: Review
• Latest audit: Sep 16, 2026 · 6:25 AM UTC
• Version: 1.0.1

Overview

This skill is a remote OpenClaw relay, but it sends prompts and credentials over plaintext HTTP and ships a reusable hard-coded bearer token, so users should review it before installing.

Install only if you trust the internal gateway and network path, and assume every prompt sent through this skill leaves the local environment. The publisher should remove the bundled token, implement real configuration overrides, require HTTPS for credential-bearing requests, and protect or make optional the ~/.oc_session session file before broad use.

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 (3)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/oc_call.py:40

Finding

Bearer Token, Session Identifier, and User Prompts Transmitted over Plaintext HTTP

Content

View full analysis

Vulnerability Details

File Location: scripts/oc_call.py, lines 40-41 and 106-115
Vulnerability Type: Sensitive-data transmission over an unencrypted channel
Risk Level: High

Vulnerable code:

python

OC_URL = "http://192.168.123.106:28789/v1/chat/completions"
OC_TOKEN = "87654321"

python

payload = {
    "model": "openclaw/default",
    "messages": [{"role": "user", "content": question}],
    "max_tokens": 4096
}
data = json.dumps(payload).encode("utf-8")
headers = {
    "Authorization": f"Bearer {OC_TOKEN}",
    "Content-Type": "application/json",
    "x-openclaw-session-key": session_key
}
req = urllib.request.Request(OC_URL, data=data, headers=headers, method="POST")
try:
    with urllib.request.urlopen(req, timeout=120) as resp:

Technical Analysis

The gateway URL uses plaintext HTTP. The request contains the bearer token in the Authorization header, a persistent session identifier in the x-openclaw-session-key header, and the user's prompt in the request body. HTTP provides neither confidentiality nor authenticated transport.

An attacker capable of observing or modifying traffic between the host and 192.168.123.106 can read these values or alter the request and response. Relevant attack positions include a compromised device on the local network, a malicious wireless access point, ARP-spoofing malware, or a compromised router. Because no TLS authentication is performed, the client also cannot cryptographically verify that it is communicating with the intended gateway.

Attack Path

1. The user invokes the Skill with a question.
2. The script creates an HTTP request containing the static bearer token, persistent session key, and prompt.
3. An attacker obtains a network-path position, such as through ARP spoofing or control of a local router.
4. The attacker captures the plaintext request and extracts the bearer token and session key.
5. If the ...[truncated 808 chars]

Remediation

View remediation

Remediation Suggestions

• Replace the HTTP endpoint with an HTTPS endpoint using a certificate valid for the gateway hostname.
• Preserve Python's default TLS certificate and hostname verification; do not install an unverified SSL context.
• Reject non-HTTPS URLs whenever authorization credentials or session identifiers will be transmitted.
• Store the endpoint in an explicitly configured environment variable, but validate that its scheme is https.
• Rotate the currently embedded bearer token because it has been stored in source code and transmitted without encryption.
• Consider short-lived, narrowly scoped credentials rather than a reusable bearer token.
• Avoid transmitting sensitive prompts unless users have been informed that their content is sent to a remote service.
• Apply network controls so the gateway accepts connections only from authorized systems, as defense in depth.

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/oc_call.py:41

Finding

Reusable Authentication Token Hard-Coded in the Skill Package

Content

View full analysis

Vulnerability Details

File Location: scripts/oc_call.py, line 41; also documented in SKILL.md, line 18
Vulnerability Type: Hard-coded credential
Risk Level: High

Vulnerable code:

python

OC_TOKEN = "87654321"  # Auth token / 认证 Token

The same credential is published in the Skill documentation:

markdown

| `OC_TOKEN` | `87654321` | Auth token / 认证 Token |

Technical Analysis

The authentication token is embedded directly in both source code and documentation. Consequently, every recipient of the Skill package can recover it without executing the script. The value is also short and predictable, making it unsuitable as a bearer credential.

A bearer token grants access based on possession. Embedding it in a distributable package prevents meaningful secrecy and complicates independent credential rotation between deployments. The risk exists even if the gateway is only available on a private network, because users, compromised internal systems, source archives, backups, or package mirrors may expose the credential.

Attack Path

1. An attacker obtains a copy of the Skill package, repository, archive, or documentation.
2. The attacker reads OC_TOKEN = "87654321" from the script or configuration table.
3. The attacker identifies or gains network access to the configured gateway.
4. The attacker submits requests with Authorization: Bearer 87654321.
5. If the default token remains valid, the gateway processes requests with the permissions assigned to that credential.

Impact Assessment

Exploitation may allow unauthorized use of the OpenClaw gateway and consumption of associated computational resources. It may also permit access to capabilities exposed by the gateway under this credential. The exact privilege level depends on server-side authorization and was not available in the audited files. The affected scope includes every deployment that retains the published default ...[truncated 6 chars]

Remediation

View remediation

Remediation Suggestions

• Remove the default token from source code and documentation.
• Require OC_TOKEN to be supplied through a protected environment variable or secret-management system.
• Fail closed with a clear error when no token has been configured; do not fall back to a bundled credential.
• Generate a cryptographically strong, unique token for each deployment.
• Rotate or revoke the published token immediately.
• Restrict each replacement credential to the minimum gateway capabilities required by this Skill.
• Avoid logging or printing authentication tokens, and ensure deployment files containing secrets have restrictive permissions.
• Add automated secret scanning to the development and release process.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/oc_call.py:37

Finding

Documented Security Configuration Overrides Are Not Implemented

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 16-22; scripts/oc_call.py, lines 37-42
Vulnerability Type: Misleading and ineffective security configuration
Risk Level: Medium

Documented configuration behavior:

markdown

| Variable / 变量 | Default / 默认值 | Description / 说明 |
|----------------|-----------------|-------------------|
| `OC_URL` | `http://192.168.123.106:28789/v1/chat/completions` | Remote Gateway address / 远程 Gateway 地址 |
| `OC_TOKEN` | `87654321` | Auth token / 认证 Token |
| `OC_SESSION_FILE` | `~/.oc_session` | Session key storage path / Session Key 存储路径 |

> **Note / 注意:** Sensitive values (URL, token) should be overridden via environment variables in production.

Actual implementation:

python

# Configuration / 配置
# Override via environment variables if needed.
# 如需修改请通过环境变量覆盖以下默认值。
OC_URL = "http://192.168.123.106:28789/v1/chat/completions"
OC_TOKEN = "87654321"
SESSION_FILE = os.path.expanduser("~/.oc_session")

Technical Analysis

The documentation and source comments claim that OC_URL, OC_TOKEN, and OC_SESSION_FILE can be overridden using environment variables. The implementation assigns constants directly and never reads these environment variables with os.environ or os.getenv.

This creates a security-relevant configuration failure: an operator may set a secure HTTPS endpoint and a unique production token, verify that the environment variables exist, and reasonably assume they are active. The script silently ignores them and continues using the bundled plaintext endpoint, published token, and fixed session-file location.

Attack Path

1. An operator follows the documentation and exports a secure OC_URL and replacement OC_TOKEN.
2. The script ignores those values because it never reads the process environment.
3. Calls continue to use http://192.168.123.106:28789/v1/chat/completions and the token 87654321.
4. Sens ...[truncated 716 chars]

Remediation

View remediation

Remediation Suggestions

• Implement the documented environment-variable overrides explicitly:

python

OC_URL = os.environ.get("OC_URL")
OC_TOKEN = os.environ.get("OC_TOKEN")
SESSION_FILE = os.path.expanduser(
    os.environ.get("OC_SESSION_FILE", "~/.oc_session")
)

if not OC_URL or not OC_TOKEN:
    raise RuntimeError("OC_URL and OC_TOKEN must be configured")

if not OC_URL.lower().startswith("https://"):
    raise ValueError("OC_URL must use HTTPS")

• Do not provide a production credential as a fallback.
• Validate the effective URL, including its scheme and expected host.
• Update the documentation so variable names and fallback behavior exactly match the implementation.
• Add tests that set each environment variable and verify that the resulting request and session path use the supplied value.
• Consider displaying the effective destination hostname without exposing the token, allowing operators to verify routing safely.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (9)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence

Finding

The documentation materially understates behavior by claiming no local history file is needed while also describing persistence of a session key in ~/.oc_session and extra local session-management commands. This mismatch can mislead users and reviewers about what data is stored locally and what operational capabilities the skill has, undermining informed consent and security review.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium

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

Finding

The skill documents network access to an internal host and local file persistence, but it does not declare any explicit tool scope or permissions boundary. In agent environments, missing scope declarations can cause overbroad execution or make reviewers unaware that the skill can write files and send user data over the network.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The skill sends user prompts to a remote internal service but does not prominently warn that user content leaves the current environment. This creates privacy and data-handling risk, especially because users may submit sensitive prompts assuming local processing.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The skill stores and reuses a session key locally without an explicit warning about persistence, which can surprise users and create session-hijacking or privacy issues on shared systems. A locally persisted session token may also allow unintended continuation of prior conversations across users or contexts.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium

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

Finding

The skill description explicitly claims session context is maintained without local history, but the code stores a session key in ~/.oc_session. This creates an integrity and privacy mismatch: users or operators may believe nothing is persisted locally when in fact a durable identifier is written to disk, enabling unintended session continuity, local disclosure, or reuse by other local processes/users with filesystem access.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

User prompts are sent to a remote service on an internal host over plain HTTP, with no encryption and no explicit user-facing warning that their input leaves the local environment. In this skill context, users may disclose sensitive internal data to what is effectively another machine on the network, and HTTP exposes both prompt contents and the bearer token to interception or tampering by any party with network visibility.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low

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

Finding

The activation description is primarily defined through Chinese trigger phrases such as 用 oc 回答 and oc 回答, which can impose a language-specific interaction requirement. Under the language/locale policy, such constraints should either be optional, user-selectable, or clearly justified as region-specific.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low

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

Finding

The session-persistence section contradicts itself by saying no local history file is needed while also stating the session key is stored in a local file. Contradictory security-relevant documentation increases the chance that users mishandle persisted credentials or fail to delete local state when expected.

Content

No source excerpt is available for this finding.

Missing User Warnings

Low

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

Finding

The session key is saved to a predictable file in the user's home directory without an explicit warning or consent flow. While the key is not a password by itself, it is a persistent conversation identifier that can allow unintended linkage, session hijacking within the remote service context, or local privacy leakage if other users/processes can read the file.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.