Openclaw Team
WarnAudited by ClawScan on May 10, 2026.
Overview
This skill is review-worthy because it exposes a LAN web server with hardcoded OpenClaw gateway credentials, unsafe file/path handling, and security claims that are stronger than the code supports.
Do not install this as-is for a real team. If you still want to test it, run only on a trusted local machine, change the invite code, remove and rotate the hardcoded gateway token, restrict network exposure, disable or fix uploads, and treat the current zero-knowledge/encryption claims as unproven until the code is corrected.
Findings (7)
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.
Anyone who can access or copy this skill source may obtain a token intended to authorize OpenClaw gateway access, and all web users share that same authority.
A bearer token for the OpenClaw gateway is embedded directly in the shipped source even though the registry declares no primary credential.
GATEWAY_TOKEN = "9d2a452dbb739cbf940a5794181a280453dda9ed99367b6a" ... headers={"Authorization": f"Bearer {GATEWAY_TOKEN}"Remove the hardcoded token, rotate it if real, require it through a user-controlled secret or environment variable, and declare the credential requirement in metadata.
A registered LAN user may be able to operate the host's OpenClaw agent under the host's gateway privileges, not just within their own isolated chat history.
Each user's chat context is forwarded to the same local OpenClaw gateway/model using one shared token, with no artifact evidence of per-user gateway identity, tool scope, or action containment.
requests.post(f"{GATEWAY_URL}/v1/chat/completions", ... json={"model": "openclaw:main", "messages": messages, "stream": False}Use per-user authorization or a tightly scoped gateway token, document exactly what OpenClaw capabilities are exposed, and require approval for any high-impact agent/tool actions.
Uploaded private files may be reachable by other people on the LAN if they know or discover the URL, and unsafe filenames increase filesystem-write risk.
Uploaded filenames are not sanitized, files are saved in plaintext, and uploaded files are served back over an unauthenticated URL.
safe_filename = f"{timestamp}_{file.filename}" ... file.save(file_path) ... @app.route('/uploads/<username>/<filename>') ... return send_from_directory(...)Require authentication and ownership checks for downloads, sanitize filenames with a safe basename, restrict file types/sizes, and encrypt uploads if they are part of the promised isolated user data.
A user with the invite code could create or write skill files outside the intended ~/Desktop/alldata directory under the server user's permissions.
Username validation only checks length and spaces; path separators such as ../ are not blocked before creating user directories and files.
def get_user_dir(username: str) -> str:
safe_name = username.replace(" ", "_")
return os.path.join(DATA_DIR, safe_name) ... if len(username) > 15 or not username:Validate usernames with a strict allowlist such as letters, numbers, underscore, and hyphen; reject path separators; and verify resolved paths stay inside DATA_DIR.
If an encrypted history file is tampered with or crafted, opening a chat could execute Python code in the server process.
Persistent chat history is parsed with Python eval instead of a safe data parser.
decrypted = decrypt_data(f.read(), password) history = eval(decrypted)
Store history as JSON and parse it with json.loads; never use eval on persisted or user-influenced data.
Users may believe passwords, chat content, and uploads have stronger protection than they actually do on the local network and at rest.
The documentation claims end-to-end/in-transit encryption and PBKDF2, while the documented access URL is plain HTTP and the code derives keys directly with SHA-256.
🛡️ **端到端加密**：所有用户数据...在传输和存储全程加密 ... 访问: `http://<你的IP>:8888` ... PBKDF2 key derivation
Correct the security claims, use HTTPS for network access, implement a salted password KDF such as PBKDF2/Argon2, and clearly state which data is not encrypted.
Prior messages can influence future assistant responses and remain on disk until removed, which is expected for chat continuity but important for privacy.
The skill intentionally persists recent chat history and reuses it in later gateway calls.
history.append({"role": "user", "content": user_message}) ... history = history[-40:] ... f.write(encrypt_data(str(history), password))Provide clear controls to view, export, clear, and limit retained history, and avoid placing sensitive instructions in persistent chat history.