让飞书可以发图片消息
AdvisoryAudited by Static analysis on Apr 30, 2026.
Overview
No suspicious patterns detected.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Anyone or any agent process with these environment variables can send messages through the Feishu app within its granted permissions.
The script uses Feishu app credentials to obtain a tenant access token. This is expected for the stated Feishu integration, but it gives the script whatever message-related authority the Feishu app has.
"app_id": "${FEISHU_APP_ID}", "app_secret": "${FEISHU_APP_SECRET}" ... jq -r '.tenant_access_token'Use a dedicated Feishu app with only the minimum required permissions, protect and rotate the app secret, and avoid exposing these variables in shared shells, logs, or repositories.
Accidental or autonomous invocation could send an unintended image or message to a Feishu recipient.
The script directly posts messages to Feishu. This is the core advertised purpose, but a wrong recipient, image, or text argument would send an unwanted workspace message.
response=$(curl -s -X POST "${FEISHU_MESSAGE_ENDPOINT}?receive_id_type=open_id" ... -d "$request_body")Review the receiver ID, image, and text before running the script; consider adding an approval prompt if an agent will invoke it automatically.
Users may not be warned by metadata that Feishu credentials and local tools such as curl and jq are needed.
The registry metadata does not advertise the credential and dependency requirements that the scripts and SKILL.md require. This is an under-declaration issue, not hidden behavior in the provided code.
Required env vars: none ... Primary credential: none ... No install spec — this is an instruction-only skill.
Declare FEISHU_APP_ID, FEISHU_APP_SECRET, curl, jq, and bash in the skill metadata or installation requirements.
Attempts to send to a group chat ID or user_id may fail or behave differently than the documentation suggests.
The implementation hardcodes receive_id_type=open_id, while SKILL.md says the receiver can be open_id, user_id, or chat_id. This appears to be a documentation/functionality mismatch rather than malicious behavior.
"${FEISHU_MESSAGE_ENDPOINT}?receive_id_type=open_id"Document that only open_id is supported, or add a receive_id_type parameter for chat_id and user_id use cases.