Back to skill

Security audit

Dingtalk Setup

Security checks for vulnerabilities and agentic risk

Overview

This setup skill is mostly purpose-aligned, but it publishes a realistic DingTalk secret and gives unsafe credential and dependency-installation examples.

Review before installing. Replace the published-looking DingTalk credentials with your own values, rotate them if they were ever real, avoid putting secrets on the command line, restrict access to OpenClaw config files, and prefer pinned plugin versions or a reviewed installation source.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:125
Finding

Credential-Like DingTalk Secret Embedded in Configuration Example

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:125-126
Vulnerability Type: Hardcoded application credentials
Risk Level: High

json
"clientId": "ding3ti4ahg82dsfkwld",
"clientSecret": "FrpMFcI30c0STvaJJWyMSZoyeb2Hkm9YqXY-6mJ0dGwdN8Xux7mgT_Xn7qnpvO-F",

Technical Analysis

The complete configuration example contains a realistic DingTalk Client ID and Client Secret rather than unmistakable placeholder values. Secrets committed to documentation are exposed to every person or system with repository access and may remain recoverable from repository history even after the current file is changed.

The audit could not verify whether this credential remains valid. Nevertheless, its format and presentation require it to be treated as potentially compromised. If valid, the secret could be used to authenticate as the associated DingTalk internal application. The exact operations available to an attacker would depend on the permissions granted to that application in DingTalk.

Attack Path

  1. An attacker obtains the public Skill file or a copy of its repository history.
  2. The attacker extracts the embedded Client ID and Client Secret.
  3. The attacker submits those credentials to the relevant DingTalk authentication endpoint.
  4. If the credentials are active, the attacker obtains application authentication tokens.
  5. The attacker invokes APIs or bot functions authorized for the associated DingTalk application.

Impact Assessment

Successful exploitation could permit impersonation of the DingTalk application, unauthorized API access, bot abuse, and access to enterprise information available under the application's assigned scopes. The compromise would be constrained by the application's DingTalk permissions, tenant configuration, and whether the displayed credential is still active.

Remediation
View remediation

Remediation Suggestions

  1. Immediately revoke and rotate the displayed Client Secret if it was ever a real credential.
  2. Replace both values with unmistakable placeholders such as YOUR_DINGTALK_CLIENT_ID and YOUR_DINGTALK_CLIENT_SECRET.
  3. Search the complete repository history, releases, mirrors, logs, and published package versions for the exposed values.
  4. Remove the values from repository history where feasible, while recognizing that history rewriting does not replace credential rotation.
  5. Store operational secrets in a dedicated secret manager or protected environment variables rather than documentation or source control.
  6. Restrict local configuration permissions so that only the service account operating OpenClaw can read the credentials.
  7. Enable automated secret scanning in pre-commit hooks and continuous integration.
  8. Review DingTalk authentication and audit logs for use of the exposed application credentials.
  9. Apply least-privilege scopes to the DingTalk application and remove permissions not required for the bot.

T08 · Insecure Dependencies

Warning
Location
SKILL.md:41
Finding

Unpinned Third-Party Plugin and Dependency Installation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md:41-47 and SKILL.md:195-202
Vulnerability Type: Unpinned third-party dependencies and mutable package sources
Risk Level: Medium

powershell
$env:NPM_CONFIG_REGISTRY="https://registry.npmmirror.com"
openclaw plugins install @soimy/dingtalk
bash
openclaw plugins install @soimy/dingtalk
bash
cd ~/.openclaw/extensions/dingtalk
rm -rf node_modules package-lock.json
NPM_CONFIG_REGISTRY=https://registry.npmmirror.com npm install
openclaw gateway restart

Technical Analysis

The installation instructions identify @soimy/dingtalk without an exact version or integrity digest. Consequently, the code installed when a user follows the instructions can differ from the code that existed when this Skill was audited.

The troubleshooting procedure further deletes package-lock.json before running npm install. Removing the lockfile discards the resolved dependency graph and integrity metadata, allowing npm to resolve newer transitive dependency versions. The procedure also uses a registry mirror, adding another mutable distribution path that users must trust.

No malicious package content was found in the supplied project, and the referenced plugin itself was not included in the audit artifact. The risk arises from executing future, unaudited package versions or dependencies.

Attack Path

  1. An attacker compromises the plugin package, one of its transitive dependencies, a maintainer account, or a package-distribution path.
  2. The attacker publishes a malicious version while retaining the expected package name.
  3. A user follows the Skill and installs the package without specifying an audited version.
  4. Alternatively, the user deletes the lockfile during troubleshooting and causes npm to resolve a compromised transitive dependency.
  5. Package lifecycle scripts or subsequently loaded plugin code execute under the account running ...[truncated 634 chars]
Remediation
View remediation

Remediation Suggestions

  1. Pin the plugin to a reviewed exact version, for example @soimy/dingtalk@X.Y.Z, rather than relying on the latest published release.
  2. Record and verify the expected package integrity digest or cryptographic signature.
  3. Retain a reviewed lockfile and use reproducible installation commands such as npm ci; do not instruct users to delete package-lock.json.
  4. Pin and audit transitive dependencies before publishing installation guidance.
  5. Prefer the canonical npm registry unless a mirror is operationally required and explicitly trusted.
  6. If a mirror is required, document its trust assumptions and validate downloaded package integrity against independently obtained metadata.
  7. Disable package lifecycle scripts during installation where compatible, then explicitly review and run only required setup operations.
  8. Install the plugin using a dedicated, least-privileged service account or isolated environment.
  9. Add dependency vulnerability, provenance, and maintainer-change monitoring to the release process.
  10. Update the troubleshooting procedure to restore dependencies from a trusted lockfile instead of performing unconstrained resolution.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (3)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The skill directs users to place DingTalk Client ID and especially Client Secret into persistent configuration and example snippets without any warning about protecting secrets, file permissions, redaction, or avoiding committing the file to source control. In this context, those values are authentication credentials for an enterprise bot integration, so exposing them could allow unauthorized access to the DingTalk application or abuse of the channel integration.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
98% confidence
Finding

The automation examples pass the Client Secret directly on the command line, which can leak through shell history, process listings, PowerShell transcription, CI logs, or endpoint monitoring tools. Because this skill is specifically for configuring a live DingTalk enterprise bot, leaked secrets could be reused to impersonate or reconfigure the integration.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
81% confidence
Finding

SQP-3 applies to all file types and covers language/locale policy violations. Although the title includes English, the invocation description and most operational guidance are in Chinese, with no indication that users may choose another language or that the skill is intentionally restricted to Chinese-language operation for compliance reasons.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.