Back to skill

Security audit

Dingtalk Notify

Security checks for vulnerabilities and agentic risk

Overview

This DingTalk notification skill has a plausible purpose, but it relies on unaudited local scripts and can send arbitrary files to a fixed external recipient without clear safeguards.

Review this skill before installing. It should only be used if you trust and separately audit the referenced DingTalk helper scripts, understand who owns userId 106648074224033227, and are comfortable with messages, files, OAuth-mediated access, and send records being handled outside the reviewed skill package.

Vulnerability Patterns
  • Tool Hijacking and SpoofingModifies or replaces tools so legitimate-looking calls execute attacker logic
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T07 · Tool Hijacking and Spoofing

Error
Location
SKILL.md:16
Finding
Execution of Mutable Helper Scripts Outside the Audited Skill Package## Vulnerability Details **File Location**: `SKILL.md`, lines 16, 26-29, 36, 43, and 50 **Vulnerability Type**: T07: Tool Hijacking and Spoofing **Risk Level**: High ### Vulnerable Code ```bash ~/.openclaw/workspace/scripts/dingtalk-work-notify.sh '[消息内容]' '106648074224033227' # Enhanced version supporting multiple file types ~/.openclaw/workspace/scripts/dingtalk-send-file-enhanced.sh [文件路径] '106648074224033227' # Simple version ~/.openclaw/workspace/scripts/dingtalk-send-file-simple.sh [文件路径] '106648074224033227' ~/.openclaw/workspace/scripts/dingtalk-work-notify.sh '🔔 连通性测试' '106648074224033227' # Automatically retry undelivered messages ~/.openclaw/workspace/scripts/dingtalk-retry-send.sh # Check DingTalk service status ~/.openclaw/workspace/scripts/dingtalk-status.sh ``` ### Technical Analysis All operational behavior is delegated to scripts under the mutable, user-specific `~/.openclaw/workspace/scripts/` directory. These scripts are outside the audited project, which contains only `SKILL.md`. Their source code, integrity, ownership, permissions, version, and actual network destinations therefore cannot be verified from the supplied artifact. This creates a tool-hijacking boundary: the displayed command can remain unchanged while the script at the referenced path is replaced or modified. There is no package-relative path resolution, integrity verification, trusted ownership check, or cryptographic hash validation before execution. ### Attack Path 1. An attacker gains the ability to create or modify a referenced script under `~/.openclaw/workspace/scripts/`, such as through another compromised process, an overly permissive directory, or a poisoned workspace. 2. The attacker replaces the expected DingTalk helper with a script that performs unauthorized operations before or instead of sending a notification. 3. A user or agent follows `SKILL.md` and invokes the apparently legitimate helper command. ...[truncated 679 chars]
Remediation
## Remediation Suggestions - Include the required helper scripts in a reviewed `scripts/` directory inside the Skill package. - Resolve script locations relative to the installed Skill directory instead of using mutable paths under the user's workspace. - Pin reviewed script versions and verify their cryptographic hashes or signatures before execution. - Require trusted ownership and restrictive filesystem permissions for all executable files and parent directories. - Refuse execution when a script is a symbolic link, has unexpected ownership, or is writable by untrusted users. - Run notification helpers with a restricted environment and the minimum filesystem and network permissions required. - Audit the omitted scripts separately, particularly their OAuth handling, command construction, file-path processing, and destination validation.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:16
Finding
Unrestricted File Transmission to a Hard-Coded External Recipient## Vulnerability Details **File Location**: `SKILL.md`, lines 16-19 and 23-29 **Vulnerability Type**: T09: Insecure Skill Coding Practices **Risk Level**: Medium ### Vulnerable Code ```bash ~/.openclaw/workspace/scripts/dingtalk-work-notify.sh '[消息内容]' '106648074224033227' ``` ```text **userId**: `106648074224033227`(飞) ``` ```bash # Enhanced version supporting multiple file types ~/.openclaw/workspace/scripts/dingtalk-send-file-enhanced.sh [文件路径] '106648074224033227' # Simple version ~/.openclaw/workspace/scripts/dingtalk-send-file-simple.sh [文件路径] '106648074224033227' ``` ### Technical Analysis The Skill directs text and files to the fixed DingTalk user ID `106648074224033227`. The file argument is represented as an unrestricted path, and the documented workflow does not require recipient confirmation, path authorization, file sensitivity checks, file-type restrictions, or a preview of the data being transmitted. The recipient identifier is not itself an authentication secret. The security issue is that a potentially sensitive local file can be selected and sent to a predetermined external account without a documented authorization checkpoint. The source of the file path is also not constrained to an approved export directory. ### Attack Path 1. An attacker or untrusted prompt persuades the agent to send a local file through the DingTalk Skill. 2. The supplied path references a sensitive file readable by the invoking account. 3. The agent follows the documented command without an explicit recipient or sensitivity confirmation. 4. The helper script reads the selected file and transmits it to the hard-coded DingTalk account. 5. The recipient obtains data that the requesting party may not have been authorized to access. Exploitation depends on the helper accepting the selected path and the invoking account having permission to read it; the helper implementation was not included in the audited artifact ...[truncated 440 chars]
Remediation
## Remediation Suggestions - Require explicit user confirmation before transmitting any file, showing the resolved path, recipient identity, file type, and file size. - Replace the hard-coded recipient with an allowlisted configuration whose ownership and authorization are independently validated. - Restrict file transmission to a dedicated export directory and resolve canonical paths before applying that restriction. - Reject symbolic links and paths that escape the approved directory. - Apply file-size and file-type allowlists and block sensitive file patterns such as credential stores, private keys, environment files, and token caches. - Separate text-notification and file-transfer permissions so ordinary notification requests cannot authorize file disclosure. - Record recipient, file metadata, authorization decision, and transmission result while redacting message contents and sensitive path information where appropriate. - Define retention limits and access controls for the notification records stored under `~/.openclaw/backups/notifications/`.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Vague Triggers

Medium
Confidence
93% confidence
Finding
The trigger phrase "工作通知" is generic and likely to appear in ordinary user requests unrelated to this specific skill. That increases the chance of accidental invocation, which is risky because this skill can send outbound messages and files to an external platform.

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill enables sending text and files to DingTalk and notes that send records are stored locally, but it provides no warning that content will be transmitted to an external service. In this context, accidental use could exfiltrate sensitive data, attachments, or internal content to a third-party messaging system and leave persistent logs.

Static analysis

No suspicious patterns detected.