Back to skill

Security audit

node-connect

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent troubleshooting guidance, but it recommends approving the latest pending device pairing without verifying the device identity.

Review this skill before installing. Its diagnostics are ordinary for OpenClaw connection troubleshooting, but do not approve a device solely because it is the latest pending request. Compare the pending request with the intended device using a stable request ID, displayed code, fingerprint, or other identifier, and reject unknown or ambiguous requests before approving anything.

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T05 · Unauthorized Access and Privilege Escalation

Error
Location
SKILL.md:99
Finding

Unverified Approval of the Latest Pending Device

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 99–102
Vulnerability Type: Unauthorized device pairing
Risk Level: High

The vulnerable instruction is:

bash
openclaw devices list
openclaw devices approve --latest

Related guidance at lines 119 and 127 also encourages approving pending requests without explicitly requiring device identity verification:

text
- `openclaw devices list` shows pending requests: stop changing network config and approve first.

Technical Analysis

The openclaw devices approve --latest command selects a pending pairing request according to request timing rather than a verified device identifier, fingerprint, or pairing code. Although the skill first tells the operator to list devices, it does not require them to validate the selected request against information displayed on the intended companion device.

This creates a race condition in the authorization workflow. If an attacker can reach the pairing endpoint and submit a request shortly before the operator runs the approval command, the attacker-controlled request may become the latest request. The operator could consequently authorize the wrong device while following the documented troubleshooting procedure.

Attack Path

  1. The gateway or device-pairing endpoint is reachable by an attacker, such as through a LAN, tailnet, public URL, or reverse proxy.
  2. A legitimate user attempts to pair a companion device and encounters a pairing-required message.
  3. The attacker submits a competing pairing request immediately before approval.
  4. The operator follows the skill and runs openclaw devices approve --latest.
  5. The command selects the attacker-controlled request based on recency.
  6. The attacker's device becomes paired without its identity being validated by the operator.

Impact Assessment

Successful exploitation could grant an unauthorized companion device the access assigned to pair ...[truncated 496 chars]

Remediation
View remediation

Remediation Suggestions

  1. Remove the recommendation to use openclaw devices approve --latest.
  2. Require the operator to inspect all pending requests and identify the intended device using a stable request ID, device identifier, cryptographic fingerprint, and user-visible pairing code where supported.
  3. Approve only the exact verified request ID rather than selecting a request by submission order.
  4. Instruct the operator to reject unknown or ambiguous pending requests before continuing.
  5. If the expected device cannot be distinguished from other requests, invalidate the existing setup token, generate a fresh short-lived token, and restart pairing.
  6. Keep pairing endpoints restricted to the minimum necessary network scope and avoid exposing them publicly unless required.
  7. Update the guidance to use a verification-focused flow, for example:
bash
openclaw devices list
# Compare the pending request's ID, fingerprint, and pairing code
# with the values shown on the intended device.
openclaw devices approve <verified-request-id>

Approval should be aborted if the device identity cannot be independently confirmed.

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • 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

Static analysis

No suspicious patterns detected.