Security Guardian

• Outcome: Review
• Latest audit: Sep 16, 2026 · 10:18 AM UTC
• Version: 1.0.3

Overview

This security skill is purpose-aligned but needs review because its advertised 2FA and unlock controls are too weak for the privileged actions it is meant to guard.

Review this carefully before installing. It is not showing exfiltration or destructive intent, but it should not be relied on as a strong security control unless the approval flow is changed to an authenticated, one-time, operation-specific approval and lockdown.status is protected against tampering.

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

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:11

Finding

Ineffective Two-Factor Authentication Handshake

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 11-14
Vulnerability Type: Authentication bypass caused by an unverified acknowledgment
Risk Level: High

Vulnerable Code

markdown

### 1. Two-Factor Authentication (2FA) Handshake
*   **Trigger:** Execution of high-risk tools (e.g., `exec`, `gateway.config.patch`, `file_write` to system paths, `rm`).
*   **Step 1 (Alert):** Send `system.notify` to the paired `openclaw-ios` device.
*   **Step 2 (Handshake):** Monitor for a user message containing `ok` on the same channel.
*   **Step 3 (Verification):** Once the handshake is confirmed, use `canvas.present` to display a unique 4-digit code on the user's primary device.

The same ineffective handshake is reused by the recovery workflow at SKILL.md, lines 31-35:

markdown

### Recovery Protocol
*   **Step 1:** User issues the `/unlock` command.
*   **Step 2:** Agent triggers a 2FA handshake via `openclaw-ios`.
*   **Step 3:** Upon successful 2FA, set `lockdown.status` to `false`.

Technical Analysis

The procedure treats any message containing ok on the same channel as successful authentication. It does not require proof that the response originated from the paired iOS device or the legitimate owner. It also does not define an exact-match requirement, authenticated device identity, challenge binding, expiration, replay prevention, rate limiting, or cryptographic verification.

The four-digit code does not repair this weakness because it is displayed only after the handshake has already been considered successful. The playbook never instructs the user to return that code and never validates it before authorizing the protected operation.

The repository contains documentation rather than executable enforcement code. Therefore, the vulnerability exists in the prescribed security workflow: an Agent implementing these instructions literally would provide an ineffective second factor despite presenting it as 2FA.

Attack Path

...[truncated 1380 chars]

Remediation

View remediation

Remediation Suggestions

1. Replace the plain-text ok acknowledgment with an approval generated by an authenticated, previously paired device.
2. Generate a cryptographically random, short-lived challenge before authorization and bind it to:
   • The exact privileged operation and normalized arguments.
   • The requesting session.
   • The authenticated user and paired device.
   • A creation time, expiration time, and unique nonce.
3. Require the mobile device to sign or explicitly approve the challenge through an authenticated channel, then verify that approval before executing the operation.
4. Mark every challenge as consumed after one successful verification and reject expired, replayed, mismatched, or unsolicited responses.
5. Do not treat substring matches such as messages containing ok as authorization.
6. If a numeric fallback code is retained, require the user to return it through a separately authenticated channel and validate it before authorization. Use sufficient entropy, a short expiration period, strict attempt limits, and one-time use.
7. Apply the same controls to /unlock, and require explicit confirmation of the specific transition from locked to unlocked.
8. Enforce authorization in a trusted runtime policy layer rather than relying solely on natural-language Agent compliance. Privileged tools should remain technically unavailable until the verifier produces a valid authorization token.
9. Record security events without storing reusable authentication secrets, including challenge creation, approval identity, expiration, rejection, and the exact authorized action.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• 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

Findings (2)

Vague Triggers

Medium

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

Finding

Using a generic ok message as the 2FA approval signal is an insecure authorization design because it can be accidentally triggered by normal conversation or replayed out of context. In a skill that gates high-risk actions such as exec, gateway patching, destructive file writes, and rm, this ambiguity can lead to unauthorized approval of privileged operations.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The skill persists security state by writing lockdown.status in the workspace without any explicit warning, consent, or integrity controls around that state change. Because the file influences whether privileged actions are blocked or re-enabled, silent workspace mutation can surprise users and may be tampered with, deleted, or spoofed by other workspace-capable actions.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.