NAS Agent Sync

• Outcome: Review
• Latest audit: Sep 10, 2026 · 7:00 PM UTC
• Version: 1.1.0

Overview

This is a legitimate NAS file-sync guide, but it needs Review because it centralizes broad SSH-backed agent file access and scheduled memory backups without clear access controls or path validation.

Install only after adding concrete controls: use a dedicated low-privilege NAS account, restrict each agent to approved directories, validate and canonicalize all requested paths, reject absolute paths, '..', control characters, and shell metacharacters, prefer SFTP or a constrained storage API over raw shell interpolation, and avoid blind memory backups unless data is reviewed, encrypted at rest, access-controlled, and subject to retention limits.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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:95
• Finding: Unvalidated Cross-Agent Input Reaches Privileged SSH Commands## Vulnerability Details **File Location**: `SKILL.md`, lines 95–102 **Vulnerability Type**: Command injection and path traversal through unvalidated request parameters **Risk Level**: High **Vulnerable Code**: ```markdown When another agent sends a file request via sessions_send: ### Store a file: ssh USER@NAS-IP "mkdir -p ~/_agents/[agent]/[subfolder]/" # Copy/create file there ### Retrieve a file: ssh USER@NAS-IP "cat ~/_agents/[agent]/[file]" ``` ### Technical Analysis The File Master is instructed to incorporate the requesting agent's `agent`, `subfolder`, and `file` values into shell commands executed through SSH. The instructions do not require an allowlist, shell escaping, canonical-path validation, or containment beneath an approved storage root. If the File Master translates incoming natural-language requests directly into these command templates, a malicious or compromised agent could supply shell metacharacters or path traversal sequences. For example, separators, substitutions, or redirection syntax could alter the intended remote command. A path containing `../` could escape the expected agent directory even without successful shell injection. The vulnerability is especially significant because the command executes under the NAS account held by the centralized File Master. ### Attack Path 1. An attacker controls or compromises an agent permitted to communicate with the File Master. 2. The attacker sends a storage or retrieval request containing a crafted agent name, subfolder, or filename. 3. The File Master interpolates the supplied value into the documented `mkdir` or `cat` SSH command. 4. The remote shell interprets traversal sequences or injected shell syntax. 5. The attacker causes unauthorized file access or remote command execution with the NAS user's privileges. 6. Retrieved information or command output may be returned through the agent communication channel. ### Impact Assessment ...[truncated 553 chars]
• Remediation: ## Remediation Suggestions - Do not construct shell commands from free-form agent messages. - Define a strict request schema with separate operation, agent identifier, and relative-path fields. - Allow only predefined agent identifiers and reject all unknown values. - Reject absolute paths, `..` components, control characters, and shell metacharacters. - Resolve the requested path to its canonical form and verify that it remains beneath the authorized agent root before every read or write. - Pass validated values as safely quoted arguments rather than concatenating them into a remote shell command. - Prefer a constrained storage service or SFTP library that does not invoke a shell. - Run the NAS connection under a dedicated, non-administrative account with access limited to the required storage root. - Record normalized operation details and reject ambiguous natural-language requests instead of attempting to infer executable commands.

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:95
• Finding: Missing Authorization Controls Permit Cross-Agent File Access## Vulnerability Details **File Location**: `SKILL.md`, lines 95–119 **Vulnerability Type**: Broken access control between agent storage domains **Risk Level**: High **Vulnerable Code**: ```markdown When another agent sends a file request via sessions_send: ### Store a file: ssh USER@NAS-IP "mkdir -p ~/_agents/[agent]/[subfolder]/" # Copy/create file there ### Retrieve a file: ssh USER@NAS-IP "cat ~/_agents/[agent]/[file]" # Send content back to requesting agent ### Confirm back: sessions_send(sessionKey="agent:[requester]:main", message="Done! File at [path]") ``` ```markdown ## File Operations → File Master I do NOT access files directly. ALL file ops go through the File Master: sessions_send(sessionKey="agent:techops:main", message="Store: [details]") sessions_send(sessionKey="agent:techops:main", message="Retrieve: [path]") ``` ### Technical Analysis The File Master possesses access to all agent directories, but the documented workflow does not authenticate the requester or bind a requester's session identity to a permitted directory. It accepts a requested path and performs the operation using a shared privileged NAS identity. No access-control list, requester-to-directory mapping, ownership validation, read/write distinction, or approval mechanism is specified. Consequently, possession of messaging access to the File Master may effectively grant access to every directory readable or writable by the File Master's NAS account. Merely centralizing credentials in the File Master does not enforce least privilege. Without server-side authorization, the File Master becomes a confused deputy that can use its broader authority on behalf of a less-privileged agent. ### Attack Path 1. A regular or compromised agent sends a `Retrieve` request to the File Master. 2. The request identifies another agent's file, such as a finance report, contract, configuration, or memory backup. 3. The File Master p ...[truncated 860 chars]
• Remediation: ## Remediation Suggestions - Authenticate the originating session and derive requester identity from trusted session metadata, not request text. - Maintain an explicit mapping from each authenticated agent identity to its authorized directory root. - Enforce separate read, write, list, and sharing permissions before executing every operation. - Deny requests targeting another agent's directory unless an explicit, auditable sharing policy permits them. - Use separate NAS accounts, restricted SSH keys, chroot environments, or filesystem ACLs for distinct trust domains. - Treat `_shared` as a separately governed resource with explicit membership and write permissions. - Return file contents only to the authenticated originating session; never trust a requester-supplied callback session key. - Log requester identity, normalized target path, operation, outcome, and authorization decision. - Require approval for sensitive cross-agent transfers and alert on repeated denied requests.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:176
• Finding: Unrestricted Agent Memory Backups May Centralize Sensitive Data## Vulnerability Details **File Location**: `SKILL.md`, lines 176–198 **Vulnerability Type**: Overbroad backup of potentially sensitive agent state **Risk Level**: Medium **Vulnerable Code**: ```json5 // Cron job config { "schedule": { "kind": "cron", "expr": "0 3 * * *", "tz": "UTC" }, "payload": { "kind": "agentTurn", "message": "Backup all agent workspaces to NAS. For each agent: rsync workspace memory/ folder to NAS _agents/{agent}/memory-backup/. Report any failures." }, "sessionTarget": "isolated" } ``` ```bash # Backup specific agent rsync -avz ~/.openclaw/workspace-finance/memory/ user@nas-ip:~/_agents/finance/memory-backup/ # Backup all agents (customize list to your team) for agent in coordinator techops finance sales marketing; do rsync -avz ~/.openclaw/workspace-$agent/memory/ user@nas-ip:~/_agents/$agent/memory-backup/ done ``` ### Technical Analysis The backup procedure copies complete agent `memory/` directories to centralized NAS storage. It does not define a data-classification policy, inclusion allowlist, secret exclusion rules, retention period, deletion procedure, encryption-at-rest requirement, or per-agent access controls. SSH and `rsync` protect data in transit when configured correctly, but they do not establish that the destination data is encrypted at rest or appropriately isolated. Memory directories can contain conversation state, operational details, personal information, internal documents, tokens, or credentials accidentally persisted by an agent. The scheduled `agentTurn` also relies on a broad natural-language instruction to back up every workspace, rather than a deterministic, reviewed backup manifest. ### Attack Path 1. Sensitive information is stored in an agent's `memory/` directory during normal operation. 2. The scheduled or manual backup copies the complete directory to the NAS without filtering. 3. The NAS retains the copied informat ...[truncated 874 chars]
• Remediation: ## Remediation Suggestions - Replace whole-directory backups with an explicit inclusion manifest containing only approved files. - Exclude credentials, tokens, SSH material, temporary files, raw conversation logs, and other sensitive state. - Scan backup inputs for secrets before transfer and fail closed when sensitive material is detected. - Encrypt backups at rest with keys managed separately from the NAS account and File Master. - Apply restrictive per-agent filesystem ACLs so one agent cannot read another agent's backup. - Define retention, rotation, secure deletion, restoration, and incident-response procedures. - Obtain explicit authorization before backing up memory containing personal or regulated information. - Use a deterministic, reviewed backup script rather than delegating broad backup interpretation to an agent turn. - Periodically test access controls and restoration while ensuring tests do not expose production data.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Rogue Agent: Self-Modification, Session Persistence
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Session Persistence

Medium

• Category: Rogue Agent

Content

- SSH access with key-based auth
- VPN or Tailnet (recommended) for secure remote access

### 2. Create Folder Structure

```bash
SSH_HOST="user@your-nas-ip"

• Confidence: 60% confidence
• Finding: Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The backup section instructs users to copy entire agent memory/workspace data to a NAS, but it does not warn that these directories may contain sensitive information such as credentials, personal data, internal notes, or regulated business content. In a multi-agent environment with centralized storage, this increases the chance of unnecessary retention, broader access, and accidental disclosure if the NAS or SSH account is misconfigured or compromised.

Static analysis

No suspicious patterns detected.