Back to skill

Security audit

火一五企微

Security checks for vulnerabilities and agentic risk

Overview

The skill is for WeCom messaging rules, but it exposes credential material and directs automatic cross-user storage of personal profile data.

Do not install this version without review. The publisher should remove and rotate the exposed WeCom credentials and webhook material, replace examples with placeholders or a secure integration layer, require explicit confirmation before sending messages or files, and stop storing user profile data in shared memory.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:158
Finding
Hardcoded WeCom Application Credentials<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 158–164; duplicated at lines 235 and 275–280 **Vulnerability Type**: Hardcoded application secret **Risk Level**: Critical ### Evidence ```bash CORP_ID="wwd00a4d7e69fffdf1" SECRET="Jg7-sBKn1rhynH_NUgAf-C6dxmNrpUIxLz8qfQ109OQ" AGENT_ID=1000009 TOKEN=$(curl -s "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=$CORP_ID&corpsecret=$SECRET" | jq -r '.access_token') curl -s -X POST "https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token=$TOKEN" ``` The same secret is also published in the configuration table at line 235 and assigned to `SECRET` again at line 276. ### Technical Analysis A reusable WeCom application secret is embedded directly in the published Skill instructions. Any party that can read the package can copy the corporate ID and secret and attempt to obtain an access token from the official WeCom token endpoint. The secret is supplied through a URL query string. Depending on the execution environment, this can additionally expose it through shell history, process inspection, command telemetry, HTTP proxy records, or application logs. The resulting access token is likewise placed in message API URLs. The exact access available to an attacker depends on the permissions assigned to WeCom Agent ID `1000009`. The repository does not establish those permissions, so broader privileges must not be assumed; however, the instructions demonstrate user-information retrieval and application-message delivery. ### Attack Path 1. Obtain a copy of `SKILL.md`. 2. Extract the corporate ID and hardcoded application secret. 3. Submit them to the official WeCom access-token endpoint: `https://qyapi.weixin.qq.com/cgi-bin/gettoken`. 4. If the credential remains valid and the request satisfies applicable WeCom restrictions, receive an application access token. 5. Use the token with APIs authorized for Agent ID `1000009`. 6. Potentially query user details or send messages under the ent ...[truncated 749 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed WeCom application secret immediately. 2. Review token issuance and API audit logs for unauthorized activity. 3. Remove all copies of the secret from `SKILL.md`, package history, release artifacts, caches, and examples. 4. Load credentials at runtime from an approved secret manager or protected environment variable. 5. Ensure secret values are never rendered in prompts, logs, error messages, or generated command examples. 6. Apply least privilege to Agent ID `1000009`, limiting API permissions and recipient scope to operational requirements. 7. Enforce WeCom IP allowlisting where practical and regularly rotate credentials. 8. Avoid placing credentials or access tokens in logged command-line URLs. Use a protected integration layer that redacts sensitive query parameters. 9. Add automated secret scanning to the publishing pipeline and block releases containing credential patterns. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:232
Finding
Exposed WeCom Robot Webhook Credential Material<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 232–236 **Vulnerability Type**: Hardcoded webhook identifier **Risk Level**: High ### Evidence The configuration table publishes the following values: ```text Enterprise ID: wwd00a4d7e69fffdf1 Agent ID: 1000009 Secret: Jg7-sBKn1rhynH_NUgAf-C6dxmNrpUIxLz8qfQ109OQ Robot Webhook: 30e68984-0562-4d13-b3cc-16d0df7a382a ``` The document also supplies the corresponding webhook invocation pattern: ```bash curl -s -X POST "https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=ROBOT_KEY" \ -H "Content-Type: application/json" \ -d '{"msgtype": "text", "text": {"content": "MESSAGE_CONTENT"}}' ``` ### Technical Analysis The Skill exposes an identifier explicitly labeled as a robot webhook configuration value and documents how a webhook key is passed to the WeCom group-robot endpoint. Webhook keys function as bearer credentials: possession may be sufficient to submit messages to the associated group. The repository does not prove whether the published UUID is still active or whether it represents the complete valid key. The security defect is nevertheless confirmed as insecure publication of webhook credential material. Exploitability depends on its validity and any WeCom-side restrictions. ### Attack Path 1. Read the robot webhook value from `SKILL.md`. 2. Insert the value into the documented `key` query parameter. 3. Submit a crafted JSON message to the official WeCom webhook endpoint. 4. If the value is complete and active, the endpoint accepts the message for the associated group robot. 5. Use trusted-looking robot messages to distribute spam, false notices, phishing links, or misleading operational instructions. ### Impact Assessment If valid, the exposed webhook can permit unauthorized message delivery to the associated WeCom group. This does not inherently grant operating-system access or full enterprise administration, but it can compromise the integrity of a trusted communication ch ...[truncated 231 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Disable and rotate the published robot webhook immediately. 2. Remove the webhook value from the Skill, documentation, version history, and published artifacts. 3. Store webhook credentials in a secret manager and expose them only to the messaging integration that requires them. 4. Do not place webhook keys in prompts, examples, logs, command histories, or user-visible errors. 5. Restrict robot capabilities and group membership where supported. 6. Monitor webhook activity for unexpected messages, unusual timing, or abnormal request volume. 7. Introduce outbound-message authorization controls for sensitive or high-volume notifications. 8. Add repository and release-pipeline secret scanning for webhook URL and UUID patterns. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:257
Finding
Automatic Collection and Cross-User Storage of Personal Data<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 257–288 and 307–327 **Vulnerability Type**: Unsafe persistent storage of personal data in shared Agent memory **Risk Level**: High ### Evidence The Skill requires profile retrieval during new sessions, daily refreshes, and first conversations: ```text Trigger times: 1. New session startup 2. Scheduled refresh once every day 3. First conversation with any user Collected fields: - User name - User ID - Gender ``` It then requires persistent storage using the following structure: ```markdown ## {USER_NAME} - userid: xxx - name: xxx - gender: xxx ``` The designated storage location and sharing model are: ```text memory/shared/MEMORY.md Shared memory is shared by all users. ``` ### Technical Analysis The Skill directs the Agent to collect names, stable user identifiers, and gender information from WeCom and write those fields into a persistent memory file shared across users. It does not specify consent, purpose limitation, access controls, encryption, retention periods, deletion procedures, or data-correction controls. Because the storage is explicitly shared, information obtained in one user's session can become available to later sessions or influence identity handling for other users. Persistent shared state can also preserve incorrect or attacker-influenced identity associations. The documented content consists of profile data rather than attacker-authored behavioral rules, so the primary defect is insecure handling of sensitive data; persistent state contamination is an additional concern. ### Attack Path 1. A user starts a new session or has a first conversation with the Agent. 2. The Agent extracts the conversation's `chat_id` and treats it as a WeCom user ID. 3. The Agent obtains an access token using the configured application credentials. 4. The Agent calls the WeCom user-information endpoint. 5. The returned name, user ID, and gender are written to `memory/shared/MEMORY.m ...[truncated 897 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Do not collect profile data automatically at session startup or on a daily schedule. 2. Require explicit, informed user consent before retrieving personal information. 3. Apply data minimization: retain only the identifier strictly required for the requested delivery operation. 4. Remove gender collection unless a documented and lawful operational requirement exists. 5. Replace global shared memory with per-user, tenant-isolated storage protected by strict access controls. 6. Encrypt personal data at rest and in transit, and prevent it from appearing in prompts or diagnostic logs. 7. Define retention periods and automatically delete records when no longer required. 8. Provide procedures for users to inspect, correct, and delete stored profile information. 9. Validate the relationship between conversation metadata and WeCom user IDs before profile retrieval or message delivery. 10. Treat all user-derived memory content as untrusted data and prevent it from becoming executable Agent instructions. 11. Record auditable access events without logging the personal data or access tokens themselves. ]]>
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Findings (17)

Missing User Warnings

High
Confidence
98% confidence
Finding
The skill instructs automatic collection and shared-memory storage of user profile data without any user-facing warning or consent flow. This is dangerous because users are not informed that identity attributes are being fetched from an external API and persisted in a cross-session shared location.

Context-Inappropriate Capability

High
Confidence
99% confidence
Finding
The skill is presented as a messaging/rules standard, but it embeds live WeCom credentials, agent identifiers, and webhook capability that enable real outbound actions. This materially expands the skill from guidance into an operational secret-bearing integration, creating immediate risk of unauthorized messaging, abuse of enterprise channels, and credential leakage.

Credential Access

High
Category
Privilege Escalation
Content
### 常用API

```bash
# 获取Access Token
curl -s "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=$CORP_ID&corpsecret=$SECRET"

# 发送应用消息(私聊)
Confidence
99% confidence
Finding
The skill includes credential acquisition flow for obtaining an access token, and elsewhere provides the corresponding secret and tenant details needed to authenticate. Exposed enterprise API credentials can allow attackers or unintended agents to impersonate the application, send messages, and query user data.

Missing User Warnings

High
Confidence
98% confidence
Finding
Automatic periodic and per-conversation retrieval of user information is specified without privacy warning, making the collection invisible to the affected users. Hidden recurring collection significantly raises compliance and trust risks, especially when paired with persistence across sessions.

Ssd 3

High
Confidence
98% confidence
Finding
The skill directs ongoing harvesting of user profile data and persistence in a shared memory accessible across users, combining overcollection with insecure storage design. This makes the context more dangerous because the capability is automatic, repeated, and normalized as part of routine conversation handling.

Credential Access

High
Category
Privilege Escalation
Content
### 执行方式

```bash
# 获取 Access Token
CORP_ID="wwd00a4d7e69fffdf1"
SECRET="Jg7-sBKn1rhynH_NUgAf-C6dxmNrpUIxLz8qfQ109OQ"
TOKEN=$(curl -s "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=$CORP_ID&corpsecret=$SECRET" | grep -o '"access_token":"[^"]*"' | cut -d'"' -f4)
Confidence
100% confidence
Finding
This section explicitly pairs a live-looking corporate ID with a hardcoded secret and token retrieval command, which is direct credential exposure. In context, the skill also includes message-send and user-lookup calls, so the leaked secret can be used for both outbound messaging and user data access.

Missing User Warnings

High
Confidence
98% confidence
Finding
The session-start workflow stores identity metadata in shared memory for all users without warning that it is cross-user accessible. This creates a clear risk of privacy violation and unauthorized disclosure because identifying data is normalized into a public/shared context.

Ssd 3

High
Confidence
99% confidence
Finding
The skill explicitly states that public/shared memory is shared by all users and still instructs storing identity details there. This is a direct privacy and segregation failure that could expose user names, IDs, and gender across unrelated users or workflows.

Missing User Warnings

Medium
Confidence
89% confidence
Finding
The skill mandates outbound WeCom transmission for files and messages by default, but does not clearly warn users that content will be sent externally or that fallback methods may be used on failure. This can lead to unexpected external transmission of sensitive material and reduced user control over delivery paths.

Vague Triggers

Medium
Confidence
96% confidence
Finding
The trigger phrases for proactive outbound messaging are broad enough to match ordinary conversational text, which can cause unintended sends to enterprise contacts. In a system with real messaging capability, ambiguous triggers increase the chance of accidental data disclosure or unauthorized communication.

Context-Inappropriate Capability

Medium
Confidence
96% confidence
Finding
The skill mandates automatic retrieval of user profile data and storage into shared memory even though its stated purpose is messaging rules. This is unnecessary data collection and persistence, and shared storage increases the chance of cross-user exposure and misuse of personal information.

Ssd 3

Medium
Confidence
96% confidence
Finding
The instructions require collecting and storing identity data in shared memory across conversations, which violates data minimization and separation principles. Shared persistence of personal data can expose one user's information to unrelated contexts, tools, or users.

Natural-Language Policy Violations

Medium
Confidence
99% confidence
Finding
The skill forces gender-based honorifics and defaults to a gendered form of address without user choice. While not a classic technical exploit, it drives unnecessary collection/inference of sensitive personal attributes and can produce harmful or inappropriate communications.

External Transmission

Medium
Category
Data Exfiltration
Content
TOKEN=$(curl -s "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=$CORP_ID&corpsecret=$SECRET" | jq -r '.access_token')

curl -s -X POST "https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token=$TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "touser": "用户ID",
Confidence
94% confidence
Finding
This snippet performs real external transmission to the WeCom message API using an access token, enabling outbound delivery of content to enterprise recipients. In the context of a skill file, embedding executable transmission patterns increases the chance of unauthorized or accidental exfiltration and misuse.

External Transmission

Medium
Category
Data Exfiltration
Content
```bash
# 获取Access Token
curl -s "https://qyapi.weixin.qq.com/cgi-bin/gettoken?corpid=$CORP_ID&corpsecret=$SECRET"

# 发送应用消息(私聊)
curl -s -X POST "https://qyapi.weixin.qq.com/cgi-bin/message/send?access_token=$TOKEN" \
Confidence
93% confidence
Finding
The documented commands fetch tokens and send messages to external WeCom endpoints, so the skill contains actionable external communication behavior rather than passive policy text. This is risky because it can be repurposed for unauthorized outbound messaging or data transfer if the embedded configuration is valid.

Context-Inappropriate Capability

Medium
Confidence
97% confidence
Finding
The skill broadens into periodic and conversation-triggered harvesting of user information from the WeCom API, which is outside the narrow scope of formatting or delivery rules. Continuous collection tied to routine interactions creates a surveillance-like behavior and increases privacy and data handling risk.

Natural-Language Policy Violations

Medium
Confidence
97% confidence
Finding
The repeated policy reinforces use of gendered honorifics based on retrieved profile information without offering a neutral option or user preference. This increases privacy and dignity risks by operationalizing personal attribute inference in routine messaging.

Static analysis

No suspicious patterns detected.