dingtalk-link

• Outcome: Review
• Latest audit: Sep 15, 2026 · 1:24 AM UTC
• Version: 1.0.0

Overview

This DingTalk setup guide is purpose-aligned, but it asks users to install mutable external code and store DingTalk secrets locally without enough safety guidance.

Review before installing. Pin and verify connector and OpenClaw versions where possible, avoid running global npm installs with elevated privileges, restrict ~/.openclaw/openclaw.json to the owning user, keep it out of repositories and support bundles, and rotate the DingTalk AppSecret if it may have been exposed.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:20

Finding

Unpinned Third-Party Connector Installation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 20-22
Vulnerability Type: Unpinned third-party dependency installation
Risk Level: Medium

bash

openclaw plugins install @dingtalk-real-ai/dingtalk-connector

Technical Analysis

The installation command does not specify a connector version or an integrity digest. Consequently, the package resolved at installation time can differ from the package originally reviewed by the Skill author. The package is also retrieved from an external package registry whose contents are not part of this repository and therefore cannot be validated by auditing this Skill alone.

This creates a supply-chain risk: compromise of the publisher account, package registry, release process, or a future package version could cause users following the instructions to install attacker-controlled code.

Attack Path

1. An attacker compromises the package publisher, registry account, or release pipeline.
2. The attacker publishes a malicious version under @dingtalk-real-ai/dingtalk-connector.
3. A user follows the Skill and runs the unpinned installation command.
4. The package manager resolves the compromised release.
5. Malicious installation hooks or connector runtime code execute in the context of the user running OpenClaw.

Impact Assessment

Successful exploitation could execute code with the permissions of the OpenClaw user. Depending on that account's access, the malicious connector could read OpenClaw configuration and credentials, alter message processing, access files available to the user, or transmit sensitive data externally. This finding does not establish that the current package is malicious; it identifies the absence of controls that bind installation to a reviewed artifact.

Remediation

View remediation

Remediation Suggestions

• Pin the connector to a specific version that has been reviewed and tested.
• Where supported, verify the package against a documented cryptographic integrity digest or signed provenance record.
• Document the expected package scope, publisher identity, source repository, and release provenance.
• Review the package's installation scripts and transitive dependencies before recommending it.
• Use a controlled package registry or lockfile-based deployment process where possible.
• Establish a deliberate upgrade procedure instead of implicitly accepting newly published releases.

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:86

Finding

Mutable Global Installation of the Latest OpenClaw Release

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 86-90
Vulnerability Type: Unpinned global dependency installation
Risk Level: Medium

bash

npm install -g openclaw@latest
openclaw gateway restart

Technical Analysis

The troubleshooting procedure installs the mutable latest release globally and immediately restarts the OpenClaw gateway. The latest tag can resolve to different artifacts over time, so the executed software is not bound to a reviewed or tested version.

Global package installation may have broader effects than a project-local installation and is sometimes performed using an elevated account. Restarting the gateway immediately after installation can load the newly installed code without a separate verification or approval step.

Attack Path

1. An attacker compromises the OpenClaw package publisher, registry account, or release pipeline.
2. The attacker publishes a malicious package and assigns it the latest distribution tag.
3. A user follows the troubleshooting instructions and globally installs openclaw@latest.
4. Package installation scripts execute, if present, with the invoking user's permissions.
5. The user restarts the gateway, causing the newly installed runtime to be loaded.
6. The malicious release operates within the gateway's access scope.

Impact Assessment

Successful exploitation could result in code execution under the account performing the installation or running the gateway. If the command is run with administrative privileges, the potential impact may extend to system-wide files and configuration. Otherwise, the scope is limited to resources accessible to the invoking user and gateway process. A compromised or merely incompatible release could also disrupt gateway availability.

Remediation

View remediation

Remediation Suggestions

• Replace openclaw@latest with a specific, tested version.
• Verify package integrity, publisher identity, signatures, and release provenance before installation.
• Review release notes and security advisories before upgrading.
• Avoid administrative global installation where a user-scoped or managed installation is sufficient.
• Separate installation, validation, and gateway restart into distinct steps.
• Validate the installed version and perform a controlled rollback if health checks fail.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:44

Finding

DingTalk Secret Stored Directly in a Plaintext Configuration File

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 44-56
Vulnerability Type: Plaintext sensitive credential storage
Risk Level: Medium

json5

{
  "channels": {
    "dingtalk-connector": {
      "enabled": true,
      "clientId": "你的AppKey",
      "clientSecret": "你的AppSecret"
    }
  }
}

Technical Analysis

The guide permits users to place the DingTalk AppSecret directly in ~/.openclaw/openclaw.json. It does not require restrictive file permissions, recommend a secret manager, warn against source-control inclusion, or describe credential rotation.

Although local configuration files commonly contain secrets, the absence of explicit access controls increases the possibility of disclosure through permissive filesystem permissions, backups, support archives, accidental repository commits, or other processes running under the same user account.

Attack Path

1. A user places a real DingTalk AppSecret in ~/.openclaw/openclaw.json as instructed.
2. The file is created with overly broad permissions, copied into an insecure backup or support bundle, or accidentally committed to source control.
3. An unauthorized local user or external party gains access to the file.
4. The attacker extracts the DingTalk application credentials.
5. The attacker attempts to authenticate to DingTalk APIs within the permissions assigned to the compromised application.

Impact Assessment

Exposure could allow unauthorized use of the DingTalk application identity and any API operations granted to that application. The exact impact depends on DingTalk-side permissions and policy, but it may include unauthorized message-related actions or access to application-authorized data. This issue does not expose a hardcoded real credential in the repository; the risk arises from the recommended credential-storage practice.

Remediation

View remediation

Remediation Suggestions

• Prefer a supported secret manager, operating-system credential store, or environment-backed secret reference rather than embedding the secret directly in JSON.
• If file-based storage is unavoidable, require owner-only permissions, such as mode 0600 on Unix-like systems.
• Ensure the parent configuration directory is accessible only to the intended account.
• Explicitly exclude the configuration file from source control, support bundles, and insecure backups.
• Avoid printing credential values in commands, diagnostics, or logs.
• Document immediate secret revocation and rotation procedures for suspected exposure.
• Apply least-privilege permissions to the DingTalk application to reduce the impact of credential compromise.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The skill explicitly instructs users to place DingTalk AppKey and AppSecret into a plaintext local configuration file, but provides no warning about protecting that file, restricting permissions, avoiding source control, or preferring a secret store/environment variables. This increases the likelihood of accidental credential exposure through backups, logs, screenshots, shared home directories, or repository commits, which could allow unauthorized access to the DingTalk integration.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.