T09 · Insecure Skill Coding Practices
- 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: Highjson "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
- An attacker obtains the public Skill file or a copy of its repository history.
- The attacker extracts the embedded Client ID and Client Secret.
- The attacker submits those credentials to the relevant DingTalk authentication endpoint.
- If the credentials are active, the attacker obtains application authentication tokens.
- 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
- Immediately revoke and rotate the displayed Client Secret if it was ever a real credential.
- Replace both values with unmistakable placeholders such as
YOUR_DINGTALK_CLIENT_IDandYOUR_DINGTALK_CLIENT_SECRET. - Search the complete repository history, releases, mirrors, logs, and published package versions for the exposed values.
- Remove the values from repository history where feasible, while recognizing that history rewriting does not replace credential rotation.
- Store operational secrets in a dedicated secret manager or protected environment variables rather than documentation or source control.
- Restrict local configuration permissions so that only the service account operating OpenClaw can read the credentials.
- Enable automated secret scanning in pre-commit hooks and continuous integration.
- Review DingTalk authentication and audit logs for use of the exposed application credentials.
- Apply least-privilege scopes to the DingTalk application and remove permissions not required for the bot.
