Dingtalk
Security checks across malware telemetry and agentic risk
Overview
The DingTalk integration mostly matches its stated messaging purpose, but its inbound webhook handling appears to accept messages without visible DingTalk signature/origin or allowlist enforcement.
Review this plugin before installing. It appears to be a normal DingTalk messaging channel, but only use it if your OpenClaw Gateway or the plugin verifies DingTalk callback authenticity and enforces user/group allowlists. Configure a least-privilege DingTalk app or robot, avoid broad permissions, and confirm the source/version mismatch is acceptable for your environment.
VirusTotal
64/64 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.
If the public callback endpoint is not protected elsewhere, someone could spoof DingTalk-style webhook messages and cause the agent to process commands as if they came from DingTalk.
The receive handler trusts the incoming payload fields and turns them into an OpenClaw inbound message without visible DingTalk signature verification, callback decryption, webhook secret validation, or allowlist checks in this code path.
async receive(ctx: ChannelPluginContext<DingTalkConfig>, payload: unknown) { ... if (data.msgtype === "text" && data.text) { ... return { ... authorId: String(data.senderStaffId || data.staffId || "unknown"), ... } }Only expose the callback if OpenClaw Gateway verifies DingTalk signatures/encryption and enforces dmPolicy/groupPolicy allowlists before messages reach the agent; otherwise add those checks to the plugin or keep the channel disabled.
Installing and configuring the skill gives OpenClaw the ability to act through the configured DingTalk app, including sending messages according to that app's permissions.
The plugin uses DingTalk app credentials from config or environment variables to obtain access tokens. This is necessary for the stated integration, but it is sensitive account authority.
const clientId = cfg.clientId?.trim() || cfg.appKey?.trim() || process.env.DINGTALK_CLIENT_ID?.trim() || process.env.DINGTALK_APP_KEY?.trim(); const clientSecret = cfg.clientSecret?.trim() || cfg.appSecret?.trim() || process.env.DINGTALK_CLIENT_SECRET?.trim() || process.env.DINGTALK_APP_SECRET?.trim();
Use a dedicated DingTalk app or robot with the minimum required permissions, rotate the secret if exposed, and avoid broad organization-wide permissions unless needed.
The agent can send messages to DingTalk targets configured for the channel, which may be visible to coworkers or groups.
Outbound agent messages can be posted to DingTalk via a configured webhook URL, or via the DingTalk API fallback. This is central to a channel plugin but gives the agent external posting capability.
if (cfg.webhookUrl) { const success = await sendWebhookMessage(cfg.webhookUrl, cfg.webhookSecret, content); if (success) return; }Configure only intended webhook URLs and target IDs, prefer allowlisted groups/users, and review whether autonomous message sending is acceptable for your workspace.
It may be harder to confirm exactly which release or upstream project this plugin came from.
The package/plugin artifacts report version 0.1.0 while registry metadata reports version 1.0.0, and the registry source/homepage are listed as unknown/none. No malicious install behavior is shown, but provenance is less clear.
"version": "0.1.0"
Verify the package contents and maintainer before installing, especially in production workspaces.