T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:132- Finding
Inquiry Results Are Sent to a Hardcoded DingTalk Recipient
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill performs its stated 1688 inquiry workflow, but it can automatically send inquiry results to a fixed DingTalk recipient and uses unsafe scheduled-agent instructions.
Review this skill before installing. Only use it if the DingTalk target 238382 is definitely the intended recipient for all inquiry results, and prefer a version that confirms submissions, stores the requester identity with each task, routes replies dynamically, escapes user input safely, and pins dependencies.
SKILL.md:132Inquiry Results Are Sent to a Hardcoded DingTalk Recipient
SKILL.md:111Untrusted Inquiry Values Are Interpolated into Shell and Scheduled-Agent Instructions
requirements.txt:1Third-Party Dependencies Are Not Reproducibly Pinned
The documented purpose and the described behavior diverge materially: the skill claims a bounded inquiry workflow but also introduces local task tracking and proactive delivery behavior that are not cleanly reflected in the declared interface. This mismatch reduces transparency and can hide security-relevant behaviors such as persistent storage and unsolicited outbound messaging.
The trigger phrases are extremely broad and overlap with normal conversation, increasing the chance that the skill activates unintentionally. Because the skill can submit external inquiries, persist task state, and schedule follow-up actions, accidental activation could cause unauthorized outbound communications or data disclosure.
The cron instructions hard-code outbound delivery to DingTalk target 238382 regardless of who initiated the inquiry. This can leak supplier responses, product links, quantities, addresses, or business intent to an unrelated recipient, making it a direct confidentiality and misdelivery issue.
The README describes automatic inquiry submission, result retrieval, and DingTalk push notifications, but does not clearly disclose that user-provided questions, product links/IDs, task IDs, and reply data are transmitted to external platforms. In this context, missing disclosure increases privacy and compliance risk because users may unknowingly send business-sensitive procurement details to AlphaShop/1688 and DingTalk.
The example invocation phrases are broad, natural-language expressions such as asking a seller or supplier a question, which can overlap with ordinary conversation and cause the skill to trigger when the user did not intend to submit an external inquiry. In this skill's context, unintended activation is more dangerous because it can send product questions and identifiers to third-party services and create supplier-facing actions automatically.
The skill declares significant capabilities—environment variable access, file read/write, and network use—but does not restrict them with an explicit tool scope. In practice this weakens least-privilege boundaries and makes it easier for the skill to access secrets, persist data, and perform outbound actions beyond what a reviewer or user would expect.
Line L060 describes the core mechanism as cron querying results, writing them to a file, and the agent replying when the user next sends a message. Subsequent sections redefine the primary mechanism as proactive DingTalk push, with file-writing only as fallback, so the documentation presents two conflicting accounts of the intended main behavior.
The skill shifts from a passive 'reply on next message' model to proactive external delivery via DingTalk, which expands the data flow and trust boundary. That creates a privacy and abuse risk because inquiry contents and supplier responses may be sent outside the original interaction context without clear per-user routing or consent.
The cron payload instruction says '不要写文件' ('do not write files'), presenting file output as forbidden behavior for the task. Later, the fallback mechanism explicitly states that on DingTalk push failure the task will write results/{taskId}.md, which directly contradicts the earlier instruction rather than merely omitting detail.
The cron payload explicitly instructs the agent to summarize results as a Chinese message (“将结果总结为中文消息”), and the document consistently assumes Chinese output without offering any language choice. This is a natural-language policy issue because it imposes a specific language on the user experience without opt-in or documented locale justification.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
"Authorization": "Bearer {}".format(get_token())
}
try:
r = requests.post(url, json=body, headers=headers, timeout=120)
r.raise_for_status()
return r.json()
except requests.exceptions.HTTPError as e:
The manifest describes submitting 1688 inquiries, waiting up to 20 minutes, fetching supplier replies, and pushing results via DingTalk. This file also implements separate local persistence-management capabilities for a pending_inquiries.json tracking file, including listing and removing entries, which are not described in the manifest and are not used as an obvious implementation detail within this script’s submit/query/poll flow.
The dependency specification uses a lower-bound only version constraint for requests, which makes builds non-reproducible and can result in installing vulnerable or incompatible releases over time. In a skill that sends supplier inquiries and likely performs external HTTP requests, an unpinned HTTP client library increases the chance that a deployment unintentionally includes a version affected by known security issues.
requests>=2.20.0
PyJWT>=2.0.0
Requests has multiple known advisories, and because the manifest does not pin a version, there is no way to confirm that the deployed package is not affected. Given this skill’s business purpose of contacting external suppliers and likely fetching remote content or APIs, an outdated or vulnerable requests release could expose credentials, weaken TLS/request handling, or enable SSRF-style abuse depending on usage.
The PyJWT dependency is also unpinned, so the installed version may vary between environments and over time, making it impossible to verify whether known JWT-related vulnerabilities are present. If this skill uses JWTs for authentication, callbacks, or API integration, an unsafe version could weaken token validation and trust boundaries.
requests>=2.20.0
PyJWT>=2.0.0
PyJWT has known security advisories, and the lack of version pinning makes the risk unverifiable for this skill. If the skill relies on JWT parsing or validation for identity, webhook authentication, or service-to-service access, a vulnerable PyJWT version could permit improper token acceptance or related authentication bypass conditions.
This code rewrites pending_inquiries.json, which modifies user-local state, but the operation itself has no confirmation prompt and no inline comment or docstring warning near the write path explaining that the tracking file will be overwritten. Although the CLI help mentions removing a task, the file rewrite side effect is not explicitly disclosed at the point of the destructive file operation.
No suspicious patterns detected.