OpenClaw WhatsApp
Security checks across malware telemetry and agentic risk
Overview
The skill matches its WhatsApp bridge purpose, but it installs unreviewed remote code and can run persistent auto-reply agents that send WhatsApp messages from a linked account without per-message approval.
Review the remote installer and binary provenance before installing. If you proceed, start with auto-reply disabled or restricted to an allowlist, require approval before sending, protect the local WhatsApp data/log directories, and know how to stop the systemd service and unlink the WhatsApp device.
VirusTotal
63/63 vendors flagged this skill as clean.
Risk analysis
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.
Installing the skill could run unreviewed shell code and install an unreviewed WhatsApp bridge binary on the user's machine.
The documented setup executes a remote installer from a mutable branch, and the provided artifacts do not include the installer, a pinned version, or a checksum for the Go binary.
curl -fsSL https://raw.githubusercontent.com/0xs4m1337/openclaw-whatsapp/main/install.sh | bash
Inspect the installer and binary source before running it, prefer a pinned release with a checksum or signature, and avoid curl-to-bash installation for account-linked tools.
A specially crafted incoming WhatsApp message could potentially influence local command execution, depending on how the bridge expands and runs the template.
The command-mode template places untrusted WhatsApp fields into a shell-style command string; the artifacts do not show escaping or safer argv-based execution, so messages containing shell metacharacters could be dangerous if the bridge invokes this through a shell.
mode: "command"
command: "/usr/local/bin/wa-notify.sh '{name}' '{message}' '{chat_jid}' '{message_id}'"Use an argv-based execution API or robust shell escaping for placeholders, and document how untrusted message text is safely passed to scripts.
External WhatsApp senders can trigger an autonomous agent run that may send messages from the user's WhatsApp account.
The worker starts the main OpenClaw agent from queued WhatsApp messages; the constructed prompt tells the agent to send a reply through openclaw-whatsapp, with no per-message human approval shown.
timeout 45s openclaw agent \
--agent main \
--session-id "$sid" \
--message "$prompt"Default to approval-before-send, use a restricted reply-only agent instead of the main agent, and require an allowlist before enabling auto-replies.
A contact could send instructions that try to override the assistant's behavior or cause inappropriate replies or tool use.
Untrusted WhatsApp history and the latest sender message are inserted into the same prompt as the agent's operational instructions, creating a prompt-injection path.
Recent conversation (latest 10): $history Latest incoming message: "$msg" Task: 1) Write a concise, natural reply. 2) Send it by executing exactly:
Treat chat content strictly as data, isolate it from system/tool instructions, constrain allowed tools, and add output validation before sending replies.
The bridge can act through the linked WhatsApp account, including reading chats/contacts and sending messages as the user.
QR pairing is expected for a WhatsApp bridge, but it grants the local bridge a linked-device session for the user's WhatsApp account.
Open QR page: `http://localhost:8555/qr` On your phone: WhatsApp → Settings → Linked Devices → Link a Device Scan the QR code
Only link an account you are comfortable automating, monitor linked devices, and use the logout/unlink flow when finished.
Private WhatsApp message history may be stored locally, searched, and reused in future agent replies.
The bridge indexes WhatsApp messages for search and the worker also reuses recent chat history as agent context, which is expected but sensitive.
GET /messages/search?q=keyword Full-text search across all messages using SQLite FTS5.
Protect the data directory and logs, set retention limits if available, and avoid linking highly sensitive chats unless storage and access controls are clear.
Auto-replies and message processing can continue after setup until the service is stopped or disabled.
The documented setup creates a user-level service that restarts automatically, which is appropriate for an always-on bridge but means automation continues in the background.
Restart=always RestartSec=5 ... systemctl --user enable openclaw-whatsapp.service systemctl --user start openclaw-whatsapp.service
Enable the service only when you want continuous automation, and document clear stop, disable, logout, and data-cleanup steps.