ClawHub
Back to skill

Security audit

Feishu Auto Reply

Security checks for vulnerabilities and agentic risk

Overview

The package asks users to prepare sensitive Feishu chat permissions for an auto-reply bot, but the shipped code only tests local rules and does not implement Feishu message handling.

Review before installing. Do not grant Feishu message, chat, or user permissions for this version unless you separately verify an implemented integration, because the reviewed code does not actually connect to Feishu or send replies. Treat it as a local config generator/rule tester, and require clearer permission mapping, privacy guidance, and dependency updates before production use.

A.I.G

Vulnerability Patterns
  • Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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)

T05 · Unauthorized Access and Privilege Escalation

Warning
Location
README.md:64
Finding

Unnecessary Feishu Permissions Violate Least Privilege

Content
View full analysis

Vulnerability Details

File Location: README.md:64-68; SKILL.md:43-48
Vulnerability Type: Excessive and currently unused application permissions
Risk Level: Medium

Vulnerable Code Snippet

README.md:64-68:

markdown
## 权限要求
使用前需要确保飞书应用有以下权限：
- `im:message:read` - 读取消息
- `im:message:send` - 发送消息
- `im:chat:read` - 读取群组信息
- `im:user:read` - 读取用户信息

SKILL.md:43-48:

markdown
## Required Permissions
- `im:message:read`
- `im:message:send`
- `im:chat:read`

Technical Analysis

The documentation directs users to grant permissions for reading messages, sending messages, reading chat information, and, in the README, reading user information. However, the current implementation contains no Feishu API client, event subscription, authentication flow, or message-sending logic.

The start command explicitly states at index.js:108-112 that message event subscription remains under development:

javascript
// 这里需要对接飞书消息事件订阅
// 实际实现需要配合 OpenClaw 的事件系统
console.log('⚠️  消息事件订阅功能开发中，即将推出...');
console.log('目前版本仅支持规则测试功能');

Therefore, none of the documented Feishu permissions are required by the code currently shipped. The im:user:read permission is also inconsistent because it appears in README.md but not in SKILL.md. Requesting permissions before the corresponding functionality exists violates the principle of least privilege.

Attack Path

  1. An administrator follows the installation documentation.
  2. The administrator grants the listed Feishu scopes to an application or future integration.
  3. The current package does not use those scopes, but they remain assigned to the application.
  4. If the application credentials, a future package version, or a substituted integration is compromised, the attacker can exercise the unnecessarily granted scopes.
  5. Depending on Feishu's scope enforcement and tenant configuration, the attacker could read messa ...[truncated 708 chars]
Remediation
View remediation

Remediation Suggestions

  1. Remove all Feishu permission requirements from the current documentation until Feishu connectivity is implemented.
  2. When integration is added, map every requested scope to a specific implemented operation and document that mapping.
  3. Request only the minimum scopes necessary for enabled features.
  4. Do not request im:user:read or im:chat:read unless the implementation demonstrably needs user or chat data.
  5. Keep README.md, SKILL.md, application manifests, and deployment instructions synchronized.
  6. Add an automated check that compares documented scopes with the scopes used by the implementation.
  7. Advise existing users to revoke any scopes already granted to the nonfunctional integration.

T08 · Insecure Dependencies

Note
Location
package-lock.json:18
Finding

Dependencies Are Locked to a Third-Party Registry Mirror

Content
View full analysis

Vulnerability Details

File Location: package-lock.json:18-34
Vulnerability Type: Third-party dependency source and supply-chain exposure
Risk Level: Low

Vulnerable Code Snippet

json
"node_modules/commander": {
  "version": "12.1.0",
  "resolved": "https://registry.npmmirror.com/commander/-/commander-12.1.0.tgz",
  "integrity": "sha512-Vw8qHK3bZM9y/P10u3Vib8o/DdkvA2OtPtZvD871QKjy74Wj1WSKFILMPRPSdUSx5RFK1arlJzEtA4PkFgnbuA==",
  "license": "MIT",
  "engines": {
    "node": ">=18"
  }
},
"node_modules/yaml": {
  "version": "2.8.2",
  "resolved": "https://registry.npmmirror.com/yaml/-/yaml-2.8.2.tgz",
  "integrity": "sha512-mplynKqc1C2hTVYxd0PU2xQAc22TI1vShAYGksCCfxbn/dFwnHTNi1bvYsBTkhdUNtGIf5xNOg938rrSSYvS9A==",
  "license": "ISC",

Technical Analysis

The lockfile instructs package managers to retrieve both direct dependencies from registry.npmmirror.com, a third-party mirror, rather than the official npm registry. This adds another infrastructure operator to the dependency trust chain and creates additional availability and artifact-delivery risk.

SHA-512 integrity values are present for both dependencies. These hashes materially reduce the likelihood that modified package bytes could be installed silently because a conforming package manager should reject an artifact whose digest differs from the lockfile. Consequently, the evidence does not establish that either dependency is malicious, and the finding is limited to the unsafe-source and additional trust-boundary concern.

Attack Path

  1. A user or CI job executes dependency installation using the committed lockfile.
  2. The package manager contacts registry.npmmirror.com for the locked tarballs.
  3. A compromise, misconfiguration, or outage at the mirror affects dependency delivery.
  4. If altered bytes are returned, integrity verification should reject them unless the lockfile or installation controls are also compr ...[truncated 872 chars]
Remediation
View remediation

Remediation Suggestions

  1. Configure npm to use https://registry.npmjs.org/.
  2. Delete and regenerate package-lock.json using the official npm registry, then review the resulting changes.
  3. Retain cryptographic integrity hashes and use deterministic installation through npm ci.
  4. Enforce the approved registry in CI and deployment environments through project or organization-level npm configuration.
  5. Add dependency vulnerability and provenance checks to CI.
  6. Review lockfile changes during pull requests, especially changes to resolved, version, and integrity fields.
  7. Where supported, verify package provenance or signatures before release.

SkillSpector

Vulnerability Patterns
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (10)

Tp4

High
Category
MCP Tool Poisoning
Confidence
96% confidence
Finding

The skill metadata and documentation claim an automatic Feishu auto-reply bot, but the described implementation appears limited to local CLI testing/config usage and does not demonstrate actual Feishu message subscription or reply handling. This mismatch is dangerous because operators may grant chat read/send permissions and deploy the skill under false assumptions about its behavior, weakening review controls and creating a path for hidden or later-added functionality to be trusted without proper scrutiny.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The README documents a bot that reads and automatically processes Feishu messages, but it does not warn users about privacy, consent, retention, or compliance implications of monitoring chat content. In a messaging automation skill, this omission can lead operators to deploy it in ways that unintentionally expose sensitive employee or customer data or violate internal policy.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

This code file contains multiple natural-language strings for the command description, logs, and generated config content entirely in Chinese. Under the stated policy, forcing a specific language without user opt-in is a locale policy violation unless the regional constraint is clearly documented and justified.

Content

No source excerpt is available for this finding.

Description-Behavior Mismatch

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The manifest describes a bot that automatically replies to Feishu messages based on rules. However, the start command explicitly states that Feishu event subscription is still under development and that the current version only supports rule testing, so the implemented behavior falls short of the described functionality.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
84% confidence
Finding

The skill documentation forces a specific language for user-facing instructions and examples, and there is no indication that this is optional or justified as a region-specific tool. Under the stated policy, natural-language content should not impose a language or locale without opt-in or clear documentation.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low
Category
Not specified by scanner
Confidence
82% confidence
Finding

The command is documented as '启动自动回复服务' and logs that it is starting the Feishu auto-reply bot, which suggests operational auto-reply behavior. In reality, the code only loads config and prints that message event subscription is not yet implemented, creating a direct contradiction between the command intent/documentation and actual behavior.

Content

No source excerpt is available for this finding.

Known Vulnerable Dependency: yaml==2.8.2 — 1 advisory(ies): CVE-2026-33532 (yaml is vulnerable to Stack Overflow via deeply nested YAML collections)

Low
Category
Supply Chain
Confidence
93% confidence
Finding

The lockfile pins yaml to version 2.8.2, and the supplied advisory indicates this version is vulnerable to stack overflow when parsing deeply nested YAML collections. In a Feishu auto-reply bot, YAML is likely used for configuration, so if an attacker can influence the YAML input or config source, they could trigger denial of service by crashing the process or exhausting the call stack.

Content

No source excerpt is available for this finding.

Unpinned Dependencies

Low
Category
Supply Chain
Confidence
93% confidence
Finding

The dependency is version-ranged with a caret, which allows automatic installation of newer minor/patch releases instead of a fully pinned version. This creates supply-chain risk and reduces build reproducibility, though by itself it is not evidence of active compromise.

Content

Scanner excerpt · package.json (reported line 19)May include surrounding context.

json
"author": "铲子",
  "license": "MIT",
  "dependencies": {
    "commander": "^12.0.0",
    "yaml": "^2.3.4"
  }
}

Unpinned Dependencies

Low
Category
Supply Chain
Confidence
94% confidence
Finding

The yaml dependency is specified with a caret range, so installations may resolve to different releases over time. For a bot that may process external configuration or message-related data, this increases supply-chain and reproducibility risk if an upstream release is vulnerable or compromised.

Content

Scanner excerpt · package.json (reported line 20)May include surrounding context.

json
"license": "MIT",
  "dependencies": {
    "commander": "^12.0.0",
    "yaml": "^2.3.4"
  }
}

Known Vulnerable Dependency: yaml==2.8.2 — 1 advisory(ies): CVE-2026-33532 (yaml is vulnerable to Stack Overflow via deeply nested YAML collections)

Low
Category
Supply Chain
Confidence
88% confidence
Finding

The resolved dependency version yaml==2.8.2 is reported vulnerable to stack overflow from deeply nested YAML collections. If this skill parses attacker-controlled or untrusted YAML, a crafted payload could crash the process and cause denial of service; the bot context makes this somewhat more relevant because automation often consumes configuration files and may run unattended.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.