T09 · Insecure Skill Coding Practices
- Location
scripts/add_bug.sh:7- Finding
Hardcoded WeCom Webhook Credential
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This bug-reporting skill is purpose-aligned, but it should go to Review because it auto-writes reports to a WeCom sheet using an exposed webhook secret and avoidable install/script risks.
Install only if this is intentionally tied to the specific WeCom smart sheet. The publisher should rotate the exposed webhook key, move it to protected configuration, remove or pin the unused npm dependency, use a safe JSON encoder and temporary-file handling, and require explicit user confirmation before submitting reports. Users should avoid putting credentials, personal data, or incident details into reports until those controls exist.
scripts/add_bug.sh:7Hardcoded WeCom Webhook Credential
SKILL.md:10Unpinned and Unused npm Dependency
scripts/add_bug.sh:13Predictable Shared Temporary File Enables Symlink and Concurrency Attacks
scripts/add_bug.sh:10Unescaped User Input Permits JSON Structure Injection
The trigger phrases are overly broad, such as general expressions like '有xxx问题' or 'xxxBug', which can match ordinary conversation. Because the skill auto-submits content to an external webhook, accidental activation can exfiltrate user text and create unwanted records without clear user intent.
The skill automatically sends user-provided problem descriptions to an external enterprise webhook but does not warn users that their content will be transmitted outside the current chat context. This creates a privacy and data-governance risk, especially if users include sensitive internal details, personal data, or credentials in bug reports.
The documentation contains a live WeCom webhook URL with its secret key embedded directly in the skill file. Anyone who can view or reuse this skill can send arbitrary records to the associated smart sheet, causing unauthorized data injection, spam, or abuse outside the intended bug-report workflow.
Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).
-d @/tmp/bug_request.json)
# 清理
rm -f /tmp/bug_request.json
# 检查是否成功
if echo "$RESPONSE" | grep -q '"errcode":0'; then
The skill appears capable of making outbound requests and installing/running a binary (mcporter) but does not declare a restrictive tool scope such as permissions or allowed-tools. In an agent environment, missing scope boundaries increases the chance the skill can invoke shell/network capabilities more broadly than intended, especially when combined with automatic triggering.
The skill documentation does not clearly define when the automation should or should not trigger, leaving behavior ambiguous. In context, that ambiguity is risky because the action is not local-only; it performs an external write to a corporate system, so misfires have real operational and privacy consequences.
This curl call sends collected user content to an external webhook endpoint, creating a clear data exfiltration path. In the context of a bug-reporting skill, users may include secrets, internal URLs, credentials, or incident details, so silent external transmission increases confidentiality risk.
EOF
# 发送请求
RESPONSE=$(curl -s -X POST "$WEBHOOK_URL" \
-H "Content-Type: application/json" \
-d @/tmp/bug_request.json)
The script automatically transmits user-provided bug descriptions to an external WeCom webhook, which is a third-party service boundary from the user's perspective. Bug reports often contain sensitive internal details, and there is no disclosure, consent step, or minimization before exfiltrating that content off the local system.
The script's natural-language comments and user-facing output are presented in Chinese only, without offering any language selection or opt-in. This can violate language/locale policy when a skill forces a specific language on users regardless of preference.
The script writes the bug report body into a predictable temporary path under /tmp, which can expose sensitive report contents to other local users or processes depending on system configuration and race conditions. Even though the file is deleted later, the data exists on disk temporarily without any warning or secure handling.
No suspicious patterns detected.