Back to skill

Security audit

gateway-control-ui

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent OpenClaw login and pairing guide, but it handles credentials and device approval in ways that could expose secrets or approve the wrong device.

Review this skill before installing or following it. Use it only in a controlled OpenClaw environment, avoid putting passwords in URLs, avoid printing or sharing gateway tokens, and verify device identity before approving any pairing request. Rotate credentials or tokens if they were pasted into URLs, logs, screenshots, transcripts, or shared terminals.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:28
Finding

Gateway Token Disclosed Through Terminal Output

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 28–34
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: High

Vulnerable Code:

bash
cat /data/.openclaw/openclaw.json | grep -A 2 '"token"'

Token is under:

json
"gateway": { "auth": { "token": "YOUR_TOKEN_HERE" } }

Technical Analysis

The documented command reads the OpenClaw configuration and prints the gateway authentication token in plaintext. The secret can consequently remain in terminal scrollback, session recordings, centralized terminal logs, support transcripts, or AI agent tool output.

The broad grep -A 2 '"token"' expression is not restricted to the exact gateway.auth.token property. If the configuration contains multiple matching properties, it may disclose additional tokens or return the wrong credential.

Attack Path

  1. An operator follows the Skill and runs the documented command.
  2. The gateway token appears in plaintext in terminal or agent output.
  3. The output is retained in scrollback, a recording, a transcript, or diagnostic logs.
  4. An attacker or unauthorized user obtains access to that retained output.
  5. The attacker submits the exposed token to a reachable OpenClaw gateway.
  6. The attacker gains the gateway access authorized by that token.

Impact Assessment

Disclosure allows an attacker to impersonate a gateway-authenticated client. The exact accessible operations depend on the gateway's authorization model and network exposure, but may include access to gateway functionality, connected channels, status information, and device-management operations. The compromise persists until the exposed token is revoked or rotated.

Remediation
View remediation

Remediation Suggestions

  • Do not print the gateway token to standard output or include it in agent transcripts.
  • Use a trusted local credential handoff, protected secret manager, or UI integration that transfers the token without exposing it to terminal output.
  • If programmatic retrieval is unavoidable, use a structured JSON parser to select only the exact gateway.auth.token path and pass it directly to the intended consumer.
  • Disable command tracing and redact secrets from terminal recordings, diagnostic logs, and support bundles.
  • Restrict /data/.openclaw/openclaw.json to the minimum required account and permissions.
  • Rotate the gateway token if the documented command has been used in a logged or shared environment.
  • Ensure authentication failures and debugging output never echo the supplied token.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:24
Finding

Basic Authentication Credentials Embedded in a URL

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 24–25
Vulnerability Type: T09: Insecure Skill Coding Practices
Risk Level: High

Vulnerable Code:

text
Optional embedded form:
https://<user>:<pass>@<your-openclaw-domain>/

Technical Analysis

The Skill recommends an optional URL containing the OpenClaw service username and password. Credentials placed in a URL can be retained or exposed through browser history, copied links, screenshots, crash reports, application telemetry, proxy records, and other diagnostics. URL user-information syntax is also inconsistently supported by modern browsers, increasing the likelihood that operators will copy or troubleshoot the credential-bearing value through insecure channels.

HTTPS protects the network connection when correctly configured, but it does not prevent local software, logs, telemetry, or users with access to browser data from observing the complete URL before or after transmission.

Attack Path

  1. An operator replaces the placeholders with valid OpenClaw credentials.
  2. The operator enters or shares the resulting credential-bearing URL.
  3. A browser, diagnostic system, screenshot, copied message, or local record retains the URL.
  4. An attacker obtains that record and extracts the username and password.
  5. The attacker authenticates to the reachable OpenClaw Control UI using the exposed credentials.
  6. If the credentials are reused, the attacker may also attempt access to other services.

Impact Assessment

Successful exploitation provides the access assigned to the compromised service account, including unauthorized entry to the Control UI. Combined with a gateway token or an unsafe pairing workflow, this could contribute to broader gateway or device access. Reused credentials may increase the compromise scope beyond OpenClaw.

Remediation
View remediation

Remediation Suggestions

  • Remove the credential-bearing URL example from the Skill.
  • Instruct users to navigate to the ordinary HTTPS service URL and enter credentials only through the browser's authentication prompt or an approved identity-provider flow.
  • Prefer short-lived authentication, multifactor authentication, and scoped service accounts where supported.
  • Configure browsers, reverse proxies, telemetry, and support tooling to redact authentication data.
  • Warn operators not to place credentials in URLs, screenshots, tickets, chat messages, or scripts.
  • Rotate credentials if a populated URL has already been entered, logged, recorded, or shared.
  • Review the service account for credential reuse and replace reused passwords.

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:42
Finding

Device Pairing Approval Without Identity Verification

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 42–46
Vulnerability Type: T05: Unauthorized Access and Privilege Escalation
Risk Level: High

Vulnerable Code:

bash
openclaw devices list
openclaw devices approve <requestId>

Technical Analysis

The instructions direct the operator to list requests and approve a request ID without requiring validation of the requesting device's identity, fingerprint, origin, nonce, expected owner, or request time. A request ID alone is an identifier rather than proof that the request belongs to the intended device.

If an attacker can submit a concurrent pairing request, or if multiple legitimate and illegitimate requests are pending, the operator may approve an attacker-controlled device by mistake. This is a confused-deputy and authorization-workflow weakness: a privileged operator performs approval without sufficient authenticated context.

Attack Path

  1. An attacker reaches the gateway's device-pairing interface and submits a pairing request.
  2. The attacker times the request to coincide with a legitimate pairing operation or leaves it among pending requests.
  3. The operator follows the Skill and runs openclaw devices list.
  4. Because the Skill requires no fingerprint or out-of-band identity comparison, the operator selects the wrong or attacker-controlled request ID.
  5. The operator runs openclaw devices approve <requestId>.
  6. The attacker-controlled device becomes trusted and receives the permissions granted to paired devices.

Impact Assessment

Exploitation can authorize an untrusted device and grant it the access available to paired devices. Depending on gateway policy, this may expose gateway data, connected services or channels, device operations, and other authenticated functionality. The unauthorized access may continue until the pairing is discovered and revoked.

Remediation
View remediation

Remediation Suggestions

  • Require verification of the device fingerprint, device name, expected owner, request timestamp, and one-time pairing code before approval.
  • Compare the fingerprint or nonce through a trusted out-of-band channel controlled by the intended user.
  • Instruct operators to reject unexpected, stale, duplicate, or ambiguous requests and to abort when identity information is unavailable.
  • Display complete request metadata and obtain explicit confirmation before executing approval.
  • Limit pairing requests to short expiration periods and rate-limit repeated submissions.
  • Restrict the pairing endpoint to trusted networks where operationally feasible.
  • Audit all approval events and alert administrators when a new device is paired.
  • Periodically review paired devices and immediately revoke unknown entries and their associated credentials.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The skill explicitly instructs the user to retrieve a gateway authentication token from a local config file and to use service username/password values for HTTP Basic Auth, including an embedded-credentials URL format. This normalizes exposing and handling secrets in plaintext without warnings, masking guidance, or safer alternatives, which increases the risk of credential leakage through shell history, screen sharing, logs, browser history, and copied commands.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.