Multi User Workspace
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: multi-user-workspace Version: 1.0.0 The `SKILL.md` file contains instructions for the AI agent that introduce a significant path traversal vulnerability. Specifically, the agent is instructed to extract a `userId` from the session key and then use this `userId` directly in file paths (e.g., `FRIENDS/{userId}.md`, `RELATIONS/*{userId}*.md`). If an attacker can control the `userId` portion of the session key (e.g., via a crafted session ID like `agent:main:../../etc/passwd`), the agent would be instructed to read arbitrary files on the host system, leading to potential information disclosure.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Profile and relationship files may contain personal details or behavioral instructions that the assistant will reuse across sessions.
The skill intentionally loads persistent user profile and relationship files into the assistant's context at session start.
Read `FRIENDS/{userId}.md` for user profile; Read `RELATIONS/*{userId}*.md` for all relationships involving this userKeep FRIENDS/ and RELATIONS/ private, avoid storing secrets or unnecessary sensitive details, and review these files regularly for outdated or unsafe instructions.
If role assignments or session bindings are wrong, a user could receive more access than intended.
The skill's permission model depends on user roles and session routing, with administrators receiving unrestricted workspace access.
Use `Role` to determine sandbox configuration in `openclaw.json` ... Administrator: no sandbox, all tools allowed
Use precise session-to-user bindings, keep administrator sessions limited to trusted users, and test guest sessions to confirm they cannot access shared or private files.
Command execution is expected for a workspace, but a misconfigured bind mount or sandbox could let guest activity affect files outside the intended directory.
The guest configuration still permits file writes and command/process execution inside the sandboxed guest workspace.
tools: { allow: ["read", "write", "edit", "exec", "process"], deny: ["browser", "canvas", "nodes", "cron", "gateway"] }Keep guest bind mounts narrow, verify `workspaceAccess` and Docker bind settings, and deny `exec` or `process` for guests who do not need them.