Kim Msg Account Skill

• Outcome: Review
• Latest audit: Sep 11, 2026 · 3:31 AM UTC
• Version: 1.0.2

Overview

This Kim/OpenClaw setup skill appears purpose-built, but it handles live credentials too casually and installs a mutable plugin, so it should be reviewed before use.

Install only if you trust the @ks-openclaw/kim package source and can verify the intended version. Avoid pasting secretKey or verificationToken into agent chat or shared/recorded terminals; prefer a secure local secret store or masked input path, and rotate credentials if they may have been exposed through the documented setup or troubleshooting commands.

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: scripts/setup.sh:14
• Finding: Unpinned Plugin Installation from an External Package Registry## Vulnerability Details **File Location**: `scripts/setup.sh:14-18`, `scripts/interactive-setup.sh:27-31`, `SKILL.md:153-156`, `README.md:52-57` **Vulnerability Type**: Supply-chain exposure through an unpinned external dependency **Risk Level**: Medium ### Vulnerable Code ```bash if [[ $REPLY =~ ^[Yy]$ ]]; then echo "正在安装插件..." export npm_config_registry="https://npm.corp.kuaishou.com" openclaw plugins install @ks-openclaw/kim ``` The same unpinned installation pattern appears in the alternate setup script: ```bash if [[ $REPLY =~ ^[Yy]$ ]]; then echo "正在安装插件..." export npm_config_registry="https://npm.corp.kuaishou.com" openclaw plugins install @ks-openclaw/kim echo "✅ 插件安装完成" ``` ### Technical Analysis The scripts install `@ks-openclaw/kim` from an external corporate npm registry without specifying an exact version or verifying a cryptographic integrity digest or signature. The repository also does not contain a lockfile, vendored plugin source, or other mechanism that binds installation to the code reviewed during this audit. Consequently, the effective code executed by the setup process can change independently of this Skill. Although no evidence indicates that the current package is malicious, compromise of the registry, package publisher account, package namespace, or a future package release could cause users to install attacker-controlled code. The installation is user-confirmed, but the prompt does not disclose the lack of version pinning or integrity verification. ### Attack Path 1. An attacker compromises the package publisher account, corporate registry, or package distribution process. 2. The attacker publishes a malicious release under the existing `@ks-openclaw/kim` package name. 3. A user runs either setup script and approves plugin installation. 4. `openclaw plugins install @ks-openclaw/kim` resolves the package version available at installation time. ...[truncated 719 chars]
• Remediation: ## Remediation Suggestions 1. Pin the plugin to a specific, reviewed version, such as an exact semantic version rather than the latest available release. 2. Verify the downloaded package against an approved cryptographic integrity digest or signature. 3. Maintain an internal allowlist of approved package versions and prevent automatic resolution to newer releases. 4. Review and archive the source of each approved plugin version. 5. Document the registry trust boundary and inform users which package version will be installed before requesting confirmation. 6. Use a lockfile or equivalent immutable dependency manifest where OpenClaw supports it. 7. Execute plugins with the least privileges necessary and restrict their access to unrelated credentials and workspace data.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/setup.sh:32
• Finding: Sensitive Credentials Are Entered with Terminal Echo and Partially Printed## Vulnerability Details **File Location**: `scripts/setup.sh:32-43,55-59`, `scripts/interactive-setup.sh:52-64,75-79` **Vulnerability Type**: Plaintext credential exposure through interactive terminal input, output, and process arguments **Risk Level**: Medium ### Vulnerable Code ```bash read -p "请输入 appKey: " APP_KEY read -p "请输入 secretKey: " SECRET_KEY read -p "请输入 verificationToken: " VERIFICATION_TOKEN read -p "请输入 webhookPath (默认 /kim): " WEBHOOK_PATH WEBHOOK_PATH=${WEBHOOK_PATH:-/kim} echo "" echo "即将配置以下内容：" echo " appKey: ${APP_KEY:0:8}..." echo " secretKey: ${SECRET_KEY:0:8}..." echo " verificationToken: ${VERIFICATION_TOKEN:0:8}..." echo " webhookPath: $WEBHOOK_PATH" ``` The complete configuration segment then passes the secrets as command-line arguments: ```bash echo "正在配置..." openclaw config set channels.kim.appKey "$APP_KEY" openclaw config set channels.kim.secretKey "$SECRET_KEY" openclaw config set channels.kim.verificationToken "$VERIFICATION_TOKEN" openclaw config set channels.kim.webhookPath "$WEBHOOK_PATH" ``` ### Technical Analysis Bash `read -p` leaves terminal echo enabled unless the `-s` option is used. Therefore, the full `secretKey` and `verificationToken` are visibly displayed while the user types them. The scripts subsequently print the first eight characters of both secrets to the terminal. The full credentials are also supplied to `openclaw config set` as process arguments. Depending on the operating system, process-monitoring permissions, shell instrumentation, endpoint monitoring, or command auditing configuration, those arguments may be observable while the command is executing. Partial secret disclosure is still sensitive. Prefixes can assist credential identification, correlation, targeted phishing, or validation of material obtained through another leak. The behavior also conflicts with the repository's own warning in `README.md:110` that application creden ...[truncated 1326 chars]
• Remediation: ## Remediation Suggestions 1. Read secrets without terminal echo by using `read -s`, followed by a separate newline: ```bash read -s -p "Enter secretKey: " SECRET_KEY printf '\n' read -s -p "Enter verificationToken: " VERIFICATION_TOKEN printf '\n' ``` 2. Never print secret prefixes or other secret fragments. Display only a neutral confirmation such as `secretKey: configured`. 3. Avoid passing secrets through command-line arguments. Prefer protected standard input, a dedicated file descriptor, or a supported secret-store integration. 4. Store credentials in an encrypted secret manager or the documented encrypted Kconf facility rather than ordinary plaintext configuration. 5. Ensure any necessary local configuration file is created with restrictive permissions, such as owner-only read/write access. 6. Clear secret variables after use with `unset APP_KEY SECRET_KEY VERIFICATION_TOKEN`. 7. Add warnings against running credential setup in recorded or shared terminal sessions. 8. Rotate credentials that may already have been entered through these scripts in exposed environments.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:223
• Finding: Verification and Troubleshooting Instructions Can Disclose Stored Secrets## Vulnerability Details **File Location**: `SKILL.md:223-228,253-255,276-278`, `README.md:179-181,214-217,229-231,243-246` **Vulnerability Type**: Plaintext secret retrieval into terminal, Agent, and diagnostic output **Risk Level**: Medium ### Vulnerable Code The Skill instructs the Agent to retrieve individual sensitive values during verification: ```bash # 检查配置 openclaw config get channels.kim.appKey openclaw config get channels.kim.secretKey openclaw config get channels.kim.verificationToken openclaw config get channels.kim.webhookPath ``` It also recommends retrieving the complete channel configuration: ```bash # 2. 检查配置 openclaw config get channels.kim ``` The README repeats direct secret retrieval during troubleshooting: ```bash openclaw config get channels.kim.appKey openclaw config get channels.kim.secretKey ``` ```bash openclaw config get channels.kim.verificationToken ``` ### Technical Analysis The documentation verifies configuration by reading secret values rather than checking whether a value exists through a redacted status mechanism. Unless OpenClaw automatically masks these fields, the commands can emit the complete `secretKey` and `verificationToken`. This is particularly risky in an Agent Skill because command output can be captured in tool results, conversation history, telemetry, execution logs, support transcripts, or downstream integrations. Retrieving the complete `channels.kim` object may expose multiple credentials in a single operation. The diagnostic shell script itself avoids printing the complete `secretKey` and verification token, but the Skill and README continue to recommend less-safe direct retrieval commands. ### Attack Path 1. A user asks the Agent to verify or troubleshoot the Kim configuration. 2. Following `SKILL.md`, the Agent runs `openclaw config get channels.kim.secretKey`, `openclaw config get channels.kim.verificationToken`, or retrieves th ...[truncated 1025 chars]
• Remediation: ## Remediation Suggestions 1. Replace direct secret retrieval with commands that only report whether each field is configured. 2. Use a supported redaction option, such as a `--redact` or status-only mode, if OpenClaw provides one. 3. Update the Skill instructions to explicitly prohibit displaying `secretKey`, `verificationToken`, or complete channel configuration in Agent responses. 4. Ensure tool output containing sensitive configuration is never copied into conversation messages or persistent diagnostic reports. 5. Update README troubleshooting examples to use the safer behavior already approximated by `scripts/diagnose.sh`, which reports presence without printing complete secret values. 6. Add output filtering as a defense-in-depth measure so fields named `secretKey`, `verificationToken`, and similar credential fields are masked before logging. 7. Restrict access to Agent transcripts, command telemetry, and diagnostic logs, and define a short retention period. 8. Rotate credentials if direct retrieval commands have previously exposed them in retained logs or conversations.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (13)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence
• Finding: The documented purpose is installation/configuration assistance, but the skill also performs diagnostics, reads existing configuration, checks gateway status, and tests webhook reachability. This mismatch reduces informed consent and can expose operational details or cause users to authorize actions they did not expect from the skill.

Missing User Warnings

High

• Confidence: 97% confidence
• Finding: The skill asks users to provide appKey, secretKey, and verificationToken for automatic configuration without explaining storage, masking, retention, or safer alternatives. This creates a direct secret-handling risk: credentials may be exposed in chat history, logs, transcripts, or downstream tooling, enabling unauthorized access to the Kim/OpenClaw integration.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The README explicitly warns that appKey and secretKey should not be exposed in code or shell scripts, but then instructs users to place them directly on the command line and in a plaintext JSON config file. This creates a real risk of credential exposure through shell history, process listings, terminal logs, backups, or accidental file disclosure, especially because these are live API credentials for a messaging integration.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The troubleshooting section tells users to print appKey and secretKey with `openclaw config get`, which can expose secrets in terminal scrollback, shared sessions, logs, screenshots, or support transcripts. Encouraging direct display of secrets during diagnostics is unsafe because it normalizes disclosure of sensitive credentials without any warning or masking.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 89% confidence
• Finding: The skill embeds shell-capable operational steps but declares no explicit tool scope or allowed-tools boundary. In an agent environment, this can lead to overbroad execution authority, making it easier for the skill to invoke shell actions unexpectedly or without policy review.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: The trigger guidance uses broad, non-exhaustive phrases, increasing the chance that the skill is invoked during unrelated conversations about Kim or messaging setup. Unintended invocation is dangerous here because the skill can lead to shell execution, credential collection, and service changes.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The instructions restart the gateway immediately after configuration without warning the user about service interruption or requiring confirmation. In production or shared environments, an unexpected restart can disrupt active traffic, cause temporary downtime, or interfere with other channels.

Natural-Language Policy Violations

Medium

• Confidence: 94% confidence
• Finding: This shell script's comments and all user-visible status messages are written in Chinese, with no indication that other languages are supported or that the user can choose a locale. That creates a language/locale policy issue because the skill imposes a specific language by default rather than offering opt-in or documenting a justified region-specific constraint.

Natural-Language Policy Violations

Medium

• Confidence: 96% confidence
• Finding: All user-facing prompts and instructions in the script are in Chinese, and there is no opt-in, fallback, or explanation that the skill is intended only for Chinese-speaking users. This creates a language-policy issue because the skill imposes a specific locale on all users by default.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The script interactively collects sensitive values including secretKey and verificationToken using plain `read -p`, which echoes input to the terminal and provides no warning about visibility, shell history, terminal logging, or where the values will be persisted. It then stores those secrets directly via `openclaw config set`, so shoulder-surfing, terminal recording, shared-session exposure, or insecure local config storage could leak credentials.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The script collects appKey, secretKey, and verificationToken using plain `read -p`, which echoes sensitive values to the terminal as they are typed and provides no warning about visibility or storage. This can expose credentials through shoulder surfing, terminal recording/logging tools, shared sessions, or shell session capture in administrative environments.

Natural-Language Policy Violations

Low

• Confidence: 86% confidence
• Finding: The README presents all user-facing instructions in Chinese and does not offer an alternative language or indicate that the locale is optional. Under the stated policy, forcing a specific language without user opt-in can be a natural-language policy violation unless the locale constraint is documented and justified.

Natural-Language Policy Violations

Low

• Confidence: 90% confidence
• Finding: All user-facing prompts and status messages in the script are written only in Chinese, with no option to choose another language or locale. This can violate language/locale policy when a skill enforces a single language without user opt-in or documented regional justification.

Static analysis

No suspicious patterns detected.