T09 · Insecure Skill Coding Practices
- Location
SKILL.md:84- Finding
WeChat AppSecret Transmitted to a Third-Party Default Endpoint
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a coherent WeChat push-message helper, but it uses sensitive WeChat credentials with third-party endpoints and documents unsafe URL-based credential transmission.
Review before installing. Prefer a self-hosted or explicitly trusted HTTPS endpoint, avoid go-wxpush defaults unless you trust the operator with your WeChat AppSecret, do not put tokens or AppSecrets in URLs, and rotate any credential previously used in query-string examples.
SKILL.md:84WeChat AppSecret Transmitted to a Third-Party Default Endpoint
references/edgeone.md:14EdgeOne Documentation Places Tokens and AppSecrets in URL Query Strings
references/wxpush.md:10Wxpush Documentation Exposes API Tokens in URL Query Strings
references/go-wxpush.md:29Go-WXPush Documentation Places the WeChat AppSecret in a URL
The GET example places highly sensitive credentials, including AppSecret, directly in the URL. This is more severe than a generic token-in-query example because long-lived application secrets in URLs are especially likely to be captured in logs, monitoring systems, referrer data, and command history, enabling full misuse of the associated WeChat integration.
The skill explicitly instructs the agent to send message contents and sensitive configuration values to remote endpoints, including third-party default services. In edgeone/go-wxpush modes this can include API tokens or WeChat AppID/Secret, so using the skill can transmit secrets off-host to infrastructure not controlled by the user.
## 发送消息
读取 `~/.config/wxpush/wxpush.env`,根据 mode 选择 curl 或 Python 发送请求。
优先使用 curl(最简洁),不可用时用 Python(标准库,无需额外依赖)。
The documentation explicitly permits passing an authentication token in the URL query string without warning about exposure. Query parameters are commonly logged by browsers, reverse proxies, web servers, observability tools, and shell history, which can leak the token to unintended parties. In a messaging/push context, compromise of the token could let an attacker send unauthorized messages.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# Token 模式
curl "https://your-edgeone.com/wxsend?token=xxx&title=通知&content=消息内容"
# 无 Token 模式
curl "https://your-edgeone.com/wxsend?appid=xxx&secret=xxx&userid=openid1&template_id=xxx&title=通知&content=消息内容&skin=warm-magazine"
The documentation explicitly demonstrates sending the AppSecret in a GET query string, which commonly exposes credentials via browser history, reverse proxies, access logs, monitoring tools, and referrer leakage. Because this is an API reference for a message-push skill, users are likely to copy the example directly, making credential disclosure a realistic operational risk rather than a theoretical concern.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl "https://your-server.com:5566/wxsend?title=通知&content=消息内容&appid=xxx&secret=xxx&userid=openid1&template_id=xxx"
The documentation explicitly recommends passing the API token in the URL query string. Query parameters are commonly exposed in browser history, server access logs, reverse proxies, monitoring tools, and referrer headers, which can leak credentials to unintended parties. In this skill context, the issue is more dangerous because it is operational API documentation that users are likely to copy directly into real deployments.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
curl "https://your-worker.com/wxsend?token=your_token&title=通知&content=消息内容"
All natural-language instructions in the file are presented in Chinese, with no indication that this locale is optional or region-specific. Under the stated policy, forcing a specific language without user opt-in can be a natural-language policy issue.
The parameter description states a default timezone of Asia/Shanghai, which imposes a specific locale behavior if the user does not choose otherwise. The document does not explain why this locale is required or present it as an explicit user choice.
The skill documentation is entirely in Chinese and does not offer an alternative language or indicate that the skill is intentionally restricted to a Chinese-speaking or region-specific audience. Under the stated policy, forcing a specific language without user opt-in can be a natural-language policy violation.