OpenClaw WhatsApp
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
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.
A maliciously crafted WhatsApp name or message could potentially alter the local command invocation if the bridge runs this through a shell or weak command parser.
The documented command template places WhatsApp-supplied name/message values into a shell-style command string. The bridge executor code is not provided, so safe escaping cannot be verified.
agent: mode: "command"; command: "/usr/local/bin/wa-notify.sh '{name}' '{message}' '{chat_jid}' '{message_id}'"Use an argument-vector, JSON/stdin handoff, or strict placeholder escaping; review the bridge binary/source before enabling command mode.
A remote WhatsApp sender can try to prompt-inject the auto-reply agent into ignoring instructions, sending unintended replies, or using available tools.
Untrusted WhatsApp messages and chat history are inserted into the prompt sent to the main OpenClaw agent.
Latest incoming message: "$msg" ... timeout 45s openclaw agent --agent main --session-id "$sid" --message "$prompt"
Treat inbound messages as untrusted data, use a restricted no-tools reply agent, and require approval for anything beyond a simple reply.
Remote contacts could cause the agent to send WhatsApp replies or, if configured, perform calendar or messaging actions in connected services.
The documented workflow lets inbound WhatsApp messages drive agent actions, and the customization example encourages external account/tool mutations without showing per-action approval.
WhatsApp DM → Bridge → wa-notify-worker.sh ... → openclaw agent ... → openclaw-whatsapp send <JID> <reply>; Book via: mcporter call composio.GOOGLECALENDAR_CREATE_EVENT ... Notify team via: message action=send channel=telegram ...
Default to an allowlist, disable unrelated tools for the WhatsApp agent, and require user confirmation for calendar, team-message, payment, or other account mutations.
The skill can act through the linked WhatsApp identity and may respond to anyone who DMs the account by default.
QR pairing delegates a WhatsApp account to the bridge, and the documented allowlist behavior means auto-replies can cover all DMs unless the user restricts it.
Open QR page: `http://localhost:8555/qr` ... WhatsApp → Settings → Linked Devices → Link a Device ... allowlist: ["971586971337"] # only these (empty = all)
Use a dedicated WhatsApp account if possible, configure a strict allowlist before enabling auto-reply, and know how to stop the service and unlink the device.
Running this command executes whatever code is served from that URL at install time.
The setup uses an unpinned remote installer from a mutable GitHub branch, and that installer is not included in the reviewed artifacts.
curl -fsSL https://raw.githubusercontent.com/0xs4m1337/openclaw-whatsapp/main/install.sh | bash
Review the installer first, pin to a trusted commit or release, and prefer a packaged install with checksums.
Sensitive chat content and agent instructions may remain on disk and could be readable by other local users or processes depending on system permissions.
The relay queues WhatsApp message content, JIDs, message IDs, and the system prompt in a /tmp directory by default without explicit private permissions or retention controls.
DATA_DIR="${OC_WA_AGENT_DATA_DIR:-/tmp/openclaw-wa-agent}" ... "message": msg, "jid": jid, "message_id": message_id, "system_prompt": system_promptSet OC_WA_AGENT_DATA_DIR to a private directory, chmod the directory/files to 700/600, and add retention/cleanup for queues and logs.
This is expected bridge plumbing, but any local process able to reach the API may be able to interact with sensitive WhatsApp functions if the implementation has no auth.
The documented local API exposes WhatsApp send, message-search, and contact-list operations; the reference does not describe an authentication token or caller boundary.
Base URL: `http://localhost:8555`; POST /send/text; GET /messages/search?q=keyword; GET /contacts
Keep the service bound to localhost, add an auth token if supported, and avoid exposing port 8555 beyond the local machine.
The WhatsApp bridge and auto-reply behavior can continue running after setup until the user stops, disables, or unlinks it.
The skill clearly documents a persistent user service that restarts automatically.
ExecStart=/usr/local/bin/openclaw-whatsapp start -c %h/.openclaw-whatsapp/config.yaml; Restart=always; systemctl --user enable openclaw-whatsapp.service
Only enable the service if continuous operation is intended; document stop/disable/logout steps for users.