openclaw-wiki

This is documentation describing legitimate but highly privileged node features: remote command execution (system.run), arbitrary JS eval in node WebViews (canvas.eval), media capture (camera/screen), SMS sending, and location access. These primitives can be abused to exfiltrate data, spy on users (photos, screen, audio, location), or run arbitrary commands if an attacker gains Gateway access or if exec-approval files are tampered with. The document itself contains no executable malicious code or obfuscation, but it documents sensitive capabilities that present moderate-to-high security risk and require strict pairing/approval controls, secure token storage, and careful permissions. Recommend reviewing the actual node implementation for input sanitization, strict auth checks, secure storage of tokens/approvals, and hardening of WebSocket RPC handling before trusting these features in hostile environments.

This document is a runbook describing legitimate app functionality and operational procedures rather than source code containing malicious payloads. The design exposes significant attack surface: remote-served HTML/JS with live-reload, an exec-like canvas.eval command, default plaintext ws:// and HTTP examples, and persistent auto-reconnect after pairing. These features are functional for the app’s use cases but must be treated as high-risk in adversarial environments. Recommendations: prefer encrypted transports (wss://, https:// or enforced Tailscale/WireGuard), restrict and audit gateway file hosting and who can publish canvas content, enforce strict pairing approval workflows and revocation processes, log and monitor node approvals and canvas.eval usage, and limit camera commands to clearly consented, foreground-only flows. Operationally, avoid using plaintext defaults on untrusted networks.

The fragment describes token-based authentication for a gateway control UI with tokens sourced from configuration or environment and stored in browser localStorage. Primary security concerns center on token exposure via localStorage, potential misconfig leading to public exposure, and reliance on WebSocket handshake for auth. Recommended mitigations include using short-lived, scoped tokens; avoiding persistent localStorage storage when possible; enforcing strict access controls on the UI; preferring secure, ephemeral credentials; and ensuring tunnels (SSH/Tailscale) are correctly configured and restricted. Overall risk is moderate but controllable with proper deployment and token management practices.

The documented exec/process subsystem provides powerful primitives for executing arbitrary shell commands and managing long-running background sessions. The document contains no direct malicious code or hard-coded secrets, but the described functionality is high-risk if exposed to untrusted callers or misconfigured (notably arbitrary command execution, elevated mode, stdin injection, and buffered output that can be exfiltrated). Recommendations: enforce strict RBAC and input validation, disable or tightly control elevated mode, apply sandboxing or least-privilege execution, limit/monitor output retention and persistence to chat history, and ensure robust child-process bridging to avoid orphaned processes.

This file is documentation with several supply-chain and operational security risks but contains no obvious embedded malware in the text itself. Primary concerns: executing a remote installer via curl|bash, installing a global npm package (supply-chain risk), storing secrets in plaintext (including passwords in webhook query strings), and exposing Apple ID/iMessage traffic through third-party webhooks. Recommend verifying remote scripts, avoiding secrets in URLs, restricting network/SSH exposure, auditing the OpenClaw and BlueBubbles packages, and using checksums/signatures for downloads.

This document is product documentation for node features and CLI usage; it contains no direct malicious code or obfuscation. However it documents powerful remote capabilities (system.run, canvas eval, camera/screen capture, location, SMS) that, if misused or if the Gateway/node approvals and tokens are compromised or misconfigured, could lead to sensitive data exfiltration or remote command execution on node hosts. Treat the features as high-risk capabilities and enforce strict allowlists/approvals, protect tokens and config files, and limit node capabilities to the minimum required.

This fragment outlines a macOS deployment model where the gateway runtime is external to the app and managed via a per-user LaunchAgent with local WebSocket health checks. While enabling persistence and decoupling the gateway from the app can improve uptime, it introduces supply-chain risks and a persistent attack surface if the external CLI, LaunchAgent, or upgrade paths are compromised. The fragment shows no hardcoded secrets, but integrity, trust in the CLI source, and secure configuration of environment variables and logging are critical for secure operation.

This file is documentation for a high-privilege component (headless node) that intentionally exposes remote command execution to agents via a Gateway. The doc itself contains no malicious code or obfuscation, but it documents capabilities that, if misconfigured or if the Gateway/pairing tokens are compromised, present significant operational risk. Recommended actions: enforce TLS and fingerprint verification, restrict filesystem permissions on ~/.openclaw/node.json, harden exec-approvals to the minimum necessary, disable browser proxy unless required, and review service install steps before enabling persistence. Full security assessment requires review of the actual runtime implementation.

The fragment is benign documentation describing legitimate integration steps for the OpenClaw Teams plugin. The primary security considerations revolve around configuration hygiene and permission scoping rather than code-level vulnerabilities. To reduce risk, enforce minimal Graph permissions, avoid embedding real secrets in config manifests or public docs, implement secret vaults for APP_ID/APP_PASSWORD/TENANT_ID, and perform periodic reviews of team/channel whitelists and data access scopes.

The documentation describes a legitimate but high-risk feature: an MV3 extension plus local relay that allows remote agents to control an attached Chrome tab via chrome.debugger. The text contains sensible security guidance (use separate profile, keep relay loopback-only, use Tailscale, auth tokens, and origin checks). There is no evidence in the provided fragment of hardcoded secrets, obfuscation, or explicit malicious code. However, because the capability permits reading session state and controlling the browser, misconfiguration or a compromised Gateway/node would enable credential/session theft and arbitrary browser actions. Recommended next steps before trusting the package in a sensitive environment: review extension manifest and source (background/service worker) for permissions and message handling, audit relay implementation for strict loopback binding and token/origin enforcement, verify secure Gateway/node pairing and transport security, and prefer a dedicated profile for attachment. Treat the architecture as high-privilege and deploy with conservative defaults and network/isolation controls.

The documentation describes a multi-path installer with remote script execution (curl | bash) and configurable installation methods (npm or git). While common, this pattern elevates supply-chain and runtime risk if the remote installer is compromised or tampered with. No hardcoded secrets or backdoors are evident in the text, but reliance on remote code and non-interactive flows necessitates strong integrity guarantees (signing/checksums), explicit user confirmation, and safer installation paths (pinning to verified packages or local installers). Recommend enabling integrity verification, providing clear prompts in non-interactive contexts, and prioritizing npm/git source verification with restricted executor privileges.