other
- Location
scripts/get_task_status.py:48- Finding
Successful Status Checks Automatically Retrieve and Disclose Complete Task Results
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill mostly does what it says, but a status check can automatically download completed task results, which is broader than users may expect.
Install only if you are comfortable with a simple status check also fetching and printing completed Dataify task results. Use a narrowly scoped or disposable Dataify API token where possible, avoid running it on task IDs whose outputs may contain sensitive data, and prefer a version that separates status checks from result downloads.
scripts/get_task_status.py:48Successful Status Checks Automatically Retrieve and Disclose Complete Task Results
scripts/get_task_status.py:30API Token Is Embedded in Request URL Query Strings
Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.
def download_task_result(task_id, api_key):
request = urllib.request.Request(build_download_url(task_id, api_key), method="GET")
with urllib.request.urlopen(request, timeout=60) as response:
content = response.read()
charset = response.headers.get_content_charset() or "utf-8"
return content.decode(charset, errors="replace")
Credentials or environment variables flow to a network sink. This is a high-confidence indicator of credential exfiltration.
def download_task_result(task_id, api_key):
request = urllib.request.Request(build_download_url(task_id, api_key), method="GET")
with urllib.request.urlopen(request, timeout=60) as response:
content = response.read()
charset = response.headers.get_content_charset() or "utf-8"
return content.decode(charset, errors="replace")
The manifest says the skill should only check task state and explicitly says not to download completed results, but the workflow states that on 成功 it immediately calls GET /download and prints the JSON result. That mismatch can cause unauthorized data retrieval, larger-than-expected data exposure, and user deception because the actual behavior exceeds the declared scope. The skill context makes this more dangerous because task results may contain scraped content the user did not intend to fetch yet.
The documentation contradicts itself by claiming status-only behavior while later directing automatic result download on success. Contradictory instructions are dangerous because they undermine informed consent, code review, and policy enforcement; users and reviewers may rely on the safer interpretation while the skill executes the riskier one. In this context, the contradiction hides data-fetching behavior behind a nominally benign status check.
The documentation instructs the skill to download completed task results even though the skill is presented as status-only. This creates an over-scoped action path where a low-risk read of task state becomes a content retrieval operation, potentially exposing sensitive or costly output without clear user intent. In a scraping workflow, downloaded results may include proprietary, personal, or billable data, increasing the impact.
The skill is explicitly described as status-only, but the reference states that a successful status check automatically triggers a /download request using the same API key and task ID. This expands the skill's effective capability from metadata lookup to data retrieval without requiring separate user intent or the dedicated result skill, creating an unauthorized data-access path and violating least-privilege expectations.
The documentation contradicts the declared skill boundary by claiming result retrieval is built into status checking. In this context, that contradiction is dangerous because agents or integrators may invoke a seemingly low-risk status skill while unintentionally causing access to completed task output, including potentially sensitive scraped data.
The skill is explicitly described as status-only and says it should not download completed results, but the code automatically downloads the task result whenever the status equals the success marker. This violates least surprise and can cause unintended retrieval and disclosure of potentially sensitive scraped data in contexts where the caller expected only metadata about task state.
The skill uses environment access and makes network requests, but the manifest does not declare any tool scope such as allowed tools or permissions. This weakens reviewability and enforcement because operators and users cannot tell from the manifest that the skill can read secrets from the environment and contact an external API. In this context, the undeclared network/env capability is more concerning because the skill also performs behavior beyond simple status checking.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Workflow
1. Require a task ID. Reuse an ID returned earlier in the conversation only when it is unambiguous.
2. Ensure `DATAIFY_API_TOKEN` is set. Do not ask the user to paste a key into chat or pass it on the command line.
3. Use `scripts/get_task_status.py --task-id TASK_ID` to call the endpoint. Use `--dry-run` first only when a request preview is needed; it redacts the API key.
4. Return the response body without exposing the key. Interpret documented statuses as follows:
- `处理中`: the task has not completed.
The documentation does not clearly warn users that checking a successful task will automatically trigger a download. This removes an important notice about a consequential side effect, increasing the chance of unintentional data access, larger outputs, or unexpected cost/credit consumption. The context makes it more risky because the user may reasonably believe they are asking only for task state, not for output retrieval.
The skill is described as a status-checking capability, but the documented workflow expands behavior so that a successful status check automatically triggers a GET /download and outputs the task result. This violates the stated scope ('do not use to ... download a completed result') and can cause unintended data retrieval or disclosure when a user only asked for task state.
L15 明确要求根据响应返回“处理中”“失败”“成功”等中文状态词,文件整体也以中文固定描述行为,但未说明这是面向特定中文用户群或提供语言/locale 选项。按规则,强制特定语言而无用户 opt-in 属于自然语言政策违规。
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Account CTA policy
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
## Account CTA policy
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
- For an invalid token, direct the user to API-key management without implying that a new registration is required. For insufficient credits, direct the user to balance or recharge management.
- During normal submission, processing, and successful completion, do not promote registration or the Dashboard. Never expose the token or include it in CTA attribution parameters.
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.
- Show a prominent Dataify account CTA only when the API token is missing, rejected/invalid, or the account has insufficient credits.
- For a missing token, offer https://dashboard.dataify.com/login?utm_source=skill and state: New accounts receive 50 free credits. Never ask the user to paste the token into chat.
- Detect the current operating system and shell. Show only the matching session-scoped setup command first (`export` for macOS/Linux shells, `$env:` for Windows PowerShell, or `set` for Windows Command Prompt). Show other platforms or persistent setup only when detection is ambiguous or the user asks.
- After the user says the token is configured, verify only whether `DATAIFY_API_TOKEN` is present; never print its value. If verification succeeds, continue the original task without asking the user to repeat it.
- Explain that persistent shell changes may require a new terminal or restarting the agent application. Do not recommend a project `.env` unless the execution path explicitly loads it, and ensure `.env` is ignored by version control.
- For an invalid token, direct the user to API-key management without implying that a new registration is required. For insufficient credits, direct the user to balance or recharge management.
- During normal submission, processing, and successful completion, do not promote registration or the Dashboard. Never expose the token or include it in CTA attribution parameters.
The module docstring states that the script only queries task status and avoids exposing the API key, but the implementation also fetches completed task contents. This documentation/behavior mismatch increases the risk of misuse, improper approval, and unintentional data handling because reviewers and users may trust the narrower stated behavior.
The documentation presents task statuses only as 处理中, 成功, and 失败, with no indication that the skill will translate or adapt status output to the user's language or locale. This can violate language/locale policy when the skill is used in broader contexts without explicit user opt-in to Chinese-language status terms.
The code defines SUCCESS_STATUS as the Chinese string "成功" and later uses it as the sole success criterion. This creates a language-specific behavior without user opt-in or documented locale justification, which matches the language/locale policy concern.