Security audit

insta-orcha-task

Security checks for vulnerabilities and agentic risk

Overview

This skill is a real task-grabbing and delivery integration, but it allows externally supplied task text to drive unattended agent work and uploads while also shipping default API credentials.

Install only if you intend to let this agent claim Yintai tasks, create deliverables locally, and upload them to the configured service. Do not run the cron/autonomous workflow until tasks are reviewed as untrusted input, uploads show an explicit file list and destination, embedded credentials are removed and rotated, and the API endpoint is pinned or otherwise validated.

A.I.G

Vulnerability Patterns

Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
Insecure DependenciesIntroduces malicious components through unsafe dependency sources
Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
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

Findings (5)

T01 · Skill Instruction Hijacking

Error

Location: SKILL.md:20
Finding: Untrusted Remote Task Descriptions Control Agent Actions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:20-25`, `SKILL.md:100-105`, and `skill.py:153-158` **Vulnerability Type**: Remote instruction injection into an autonomous agent **Risk Level**: Critical ### Vulnerable Code and Instructions `SKILL.md:20-25` directs the agent to interpret remote task content and autonomously select capabilities: ```text agent 读取任务描述(title/description/category) ↓ agent 自主决策并执行 ← 使用自身能力 + 其他 skill - PPT 任务 → 调用 Powerpoint/PPTX skill 生成 .pptx - 代码任务 → 编写代码文件 - 写作任务 → 撰写文档 ``` `SKILL.md:100-105` recommends periodically executing the same behavior: ```json "payload": { "kind": "agentTurn", "message": "Yintai 任务抢单指令：1) 调用 grab_one_task() 抢单 2) 有任务则分析描述并执行 3) 自行产出产物到工作目录 4) 调用 package_and_upload() 交付 5) 更新状态", "timeoutSeconds": 300 } ``` The untrusted description is returned directly to the agent in `skill.py:153-158`: ```python def _task_to_dict(self, t: TaskDetail) -> dict: return { "id": str(t.id), "title": t.title, "description": t.description or "", "category": t.category, "bounty": str(t.bounty), ``` ### Technical Analysis Task titles and descriptions originate from the remote task API and can therefore be controlled by a task creator. The Skill does not distinguish these values from trusted operational instructions. Instead, its instructions explicitly tell the agent to analyze the values, make autonomous decisions, and use its own capabilities and other installed Skills. There is no fixed task schema, instruction filtering, capability allowlist, approval boundary, or sandbox policy between the remote description and the agent's tool use. A task description can consequently contain prompt-injection instructions that attempt to override the intended task, request access to local files, invoke command-capable tools, or place sensitive information into an artifact that is subsequently uploaded. This is instruction hijacking rather than ...[truncated 1522 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Treat task titles and descriptions strictly as untrusted data, never as authoritative agent instructions. 2. Replace autonomous natural-language execution with a fixed, validated task schema containing allowlisted task types and parameters. 3. Define a strict capability allowlist for each supported task type. 4. Prevent task content from requesting shell execution, secret access, arbitrary file reads, installation, or invocation of unrelated Skills. 5. Run task processing in a sandbox with: - A dedicated empty filesystem workspace. - No inherited secrets except narrowly scoped task credentials. - Restricted network egress. - No access to host paths, agent memory, or unrelated tools. 6. Require explicit user approval before executing a newly retrieved task and again before uploading artifacts. 7. Display the exact artifact list and upload destination during approval. 8. Apply prompt-injection defenses that separate system policy, trusted workflow instructions, and remote task data. 9. Disable unattended cron execution until these controls are implemented. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: run_grab.py:1
Finding: Hard-Coded API Key and Secret in Executable Source<![CDATA[ ## Vulnerability Details **File Location**: `run_grab.py:1-6` **Vulnerability Type**: Embedded authentication credentials **Risk Level**: High ### Vulnerable Code ```python """Grab one Yintai task and print JSON result.""" import os os.environ.setdefault("YINTAI_APP_KEY", "ak_6ecb8c01b061ea710451d61e6df8982e") os.environ.setdefault("YINTAI_APP_SECRET", "a09c7ea62ad8f5588d3ade4d9846929bc2bd25c6840216ad1a60db83bbf0f109") os.environ.setdefault("TASK_API_BASE_URL", "https://claw.int-os.com") os.environ.setdefault("TASK_OUTPUT_DIR", "/tmp/yintai_output") ``` ### Technical Analysis The package distributes an API key and API secret in plaintext. `setdefault()` causes these credentials to be used automatically whenever the corresponding environment variables are absent. The remainder of `run_grab.py` constructs `YintaiTaskAgent` and contacts the configured task API, so the embedded values are operationally connected to authenticated API calls. Any party able to download the package, read its source, inspect a source archive, or access a repository copy can recover the credentials. Obscuring or encoding these values would not solve the issue because client-side secrets included in a distributed package remain extractable. ### Attack Path 1. An attacker obtains the package or its source code. 2. The attacker extracts the API key and API secret from `run_grab.py`. 3. The attacker creates requests carrying the corresponding `X-API-Key` and `X-API-Secret` headers. 4. The attacker invokes task-platform operations permitted to the associated bot identity. 5. The attacker continues using the credentials until they are revoked or expire. ### Impact Assessment The exact server-side authorization scope is not present in the audited project. Based on the implemented API client, the exposed identity may be able to: - List available tasks. - Retrieve task details. - Claim tasks. - Change task status. - Upload task deliverables. The credentials may also expose oth ...[truncated 203 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed API key and secret immediately. 2. Remove both values from the current source and all repository history, release archives, logs, and cached artifacts. 3. Require credentials to be supplied through a secret manager or protected environment injection. 4. Fail closed when credentials are absent rather than falling back to embedded defaults. 5. Scope replacement credentials to only the required task operations. 6. Add expiration, rotation, server-side rate limits, and anomaly monitoring. 7. Add automated secret scanning to development and release pipelines. 8. Review server logs for unauthorized use of the exposed identity. ]]>

T09 · Insecure Skill Coding Practices

Error

Location: config.py:43
Finding: Authentication Credentials and Deliverables Can Be Sent to an Arbitrary Endpoint<![CDATA[ ## Vulnerability Details **File Location**: `config.py:43-48` and `api_client.py:94-105` **Vulnerability Type**: Unvalidated sensitive-data destination **Risk Level**: High ### Vulnerable Code `config.py:43-48` accepts an unrestricted API base URL: ```python # 从环境变量覆盖 if os.environ.get("TASK_API_BASE_URL"): config.api_base_url = os.environ["TASK_API_BASE_URL"] if os.environ.get("YINTAI_APP_KEY"): config.api_key = os.environ["YINTAI_APP_KEY"] if os.environ.get("YINTAI_APP_SECRET"): config.api_secret = os.environ["YINTAI_APP_SECRET"] ``` `api_client.py:94-105` constructs URLs from that value and attaches credentials: ```python def _make_url(self, path: str) -> str: """构建完整URL""" return f"{self.base_url}{self.config.api_prefix}{path}" def _get_headers(self) -> dict: """生成认证请求头""" headers = {"Content-Type": "application/json"} if self.api_key: headers["X-API-Key"] = self.api_key if self.api_secret: headers["X-API-Secret"] = self.api_secret return headers ``` The same URL construction and authentication headers are used for deliverable uploads in `api_client.py:219-225`: ```python path = f"/bots/tasks/{task_id}/deliverable" url = self._make_url(path) headers = self._get_headers() headers.pop("Content-Type", None) # multipart 需要 boundary ``` ### Technical Analysis `TASK_API_BASE_URL` is accepted without scheme validation, trusted-host allowlisting, or endpoint identity pinning. The client then attaches both authentication values to requests made to that base URL. The upload path also sends generated ZIP archives to the same unrestricted destination. If an attacker can influence the process environment, deployment configuration, launcher, or cron configuration, the attacker can redirect all requests to an attacker-controlled HTTP or HTTPS server. A plaintext `http://` URL is also not explicitly rejected, which can expose credentials and artifacts to network interception. ### Attack Path 1. ...[truncated 1097 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Require an `https` scheme and reject plaintext HTTP. 2. Validate the hostname against an explicit, immutable allowlist of approved task-service domains. 3. Normalize and parse the URL with a standard URL parser before validation. 4. Reject URLs containing user information, fragments, unexpected ports, IP literals, or ambiguous host encodings unless explicitly required. 5. Configure redirect handling so credentials are never forwarded to a different origin. 6. Separate credential configuration from endpoint configuration and prevent untrusted callers from overriding either value. 7. Consider certificate or public-key pinning where the deployment model supports safe rotation. 8. Display and require approval for the upload hostname before sending artifacts. 9. Use short-lived, audience-bound tokens instead of reusable static secrets. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: skill.py:255
Finding: Upload Failures Are Reported as Success and Workspace Cleanup Is Not Awaited<![CDATA[ ## Vulnerability Details **File Location**: `skill.py:255-269` **Vulnerability Type**: Incorrect security-sensitive success handling and ineffective cleanup **Risk Level**: Medium ### Vulnerable Code ```python # 上传 try: up = await self.client.upload_deliverable( task_id=uuid.UUID(task_id), result_description=result_description, zip_file_path=str(zip_path), ) result["upload_result"] = up logger.info(f"上传成功: {task_id}") except Exception as e: logger.warning(f"上传失败: {e}") result["error"] = str(e) result["success"] = True result["zip_path"] = str(zip_path) # 打包后自动清理工作目录 self.cleanup_workspace(task_id) ``` The cleanup function is asynchronous in `skill.py:166-172`: ```python async def cleanup_workspace(self, task_id: str): """清理任务的隔离工作目录""" ws = self._work_base / f"workspace_{task_id}" if ws.exists(): shutil.rmtree(ws) logger.info(f"已清理工作目录: {ws}") ``` The documented calling pattern in `SKILL.md:68-71` trusts the erroneous success result: ```python if result["success"]: await agent.update_status(task["id"], "completed") else: await agent.update_status(task["id"], "cancelled") ``` ### Technical Analysis The upload exception is caught and recorded, but execution then unconditionally sets `result["success"]` to `True`. Callers following the documented workflow will therefore mark the task as completed even when no deliverable was accepted. Additionally, `cleanup_workspace()` is declared with `async def` but is called without `await`. Calling an async function in this manner only creates a coroutine object; its body does not run. Consequently, the source workspace remains on disk despite documentation claiming automatic cleanup. The generated delivery ZIP is also retained and has no post-upload deletion path. These issues create integrity and data-retention failures. They can be triggered by ordinary network errors or deliberately by causing the upload endpoint to re ...[truncated 1187 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Set `success` only after `upload_deliverable()` returns a confirmed successful response. 2. Return immediately or preserve `success=False` when upload fails. 3. Await asynchronous cleanup explicitly: ```python await self.cleanup_workspace(task_id) ``` 4. Place temporary-directory and archive cleanup in a carefully designed `finally` block. 5. Decide whether failed-upload artifacts must be retained for retry. If retained, use restrictive permissions, an expiration policy, and an explicit status indicating retention. 6. Delete the generated ZIP after a confirmed upload unless local retention is an intentional documented requirement. 7. Use a secure temporary directory with restrictive permissions rather than a shared predictable output location. 8. Update the caller so task status becomes `completed` only when server-side delivery confirmation has been verified. 9. Add tests for upload rejection, timeout, malformed responses, cleanup execution, and repeated scheduled failures. ]]>

T08 · Insecure Dependencies

Note

Location: pyproject.toml:27
Finding: Incomplete and Unbounded Dependency Declaration<![CDATA[ ## Vulnerability Details **File Location**: `pyproject.toml:27-29`, `README.md:36-40`, and `config.py:7` **Vulnerability Type**: Non-reproducible and incomplete dependency management **Risk Level**: Low ### Vulnerable Configuration `pyproject.toml:27-29` declares only a lower bound for `httpx`: ```toml dependencies = [ "httpx>=0.25.0", ] ``` `README.md:36-40` recommends an entirely unpinned installation: ```bash pip install httpx # 依赖 ``` However, `config.py:7` imports another runtime dependency that is not declared: ```python from pydantic import BaseModel ``` The build requirements in `pyproject.toml:1-4` are also not reproducibly pinned: ```toml [build-system] requires = ["setuptools>=61.0", "wheel"] build-backend = "setuptools.build_meta" ``` ### Technical Analysis The project has no reviewed upper bounds, lockfile, or hashes for installed dependencies. A fresh installation can therefore resolve to versions materially different from those tested by the author. The runtime import of `pydantic` is absent from project dependencies, making behavior depend on unrelated packages already present in the environment or requiring users to install it manually. No malicious dependency name, typosquatting package, or unsafe package index was identified in the reviewed files. The confirmed issue is weak dependency hygiene, not evidence that the named dependencies themselves are malicious. ### Attack Path 1. A user installs the project at a later date or in a different environment. 2. The package manager resolves the newest versions satisfying the broad constraints. 3. An incompatible or compromised future dependency release is selected, or installation fails because `pydantic` is absent. 4. The Skill executes with unreviewed dependency code in the agent process. 5. Any vulnerability or malicious behavior in the selected dependency receives the same process access as the Skill. ### Impact Assessment Potential consequences include: - Non-repr ...[truncated 412 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Add `pydantic` to the runtime dependency list with a reviewed compatible version range. 2. Use bounded dependency constraints rather than unrestricted future versions. 3. Produce and publish a lockfile or constraints file for reproducible deployments. 4. Use package hashes in deployment environments where supported. 5. Pin or tightly constrain build-system dependencies. 6. Test the exact locked dependency set in continuous integration. 7. Run dependency vulnerability and provenance scanning before each release. 8. Update installation documentation to install the project and its declared dependencies rather than recommending ad hoc package installation. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (24)

Tp4

High

Category: MCP Tool Poisoning
Confidence: 94% confidence
Finding: The description says the skill is responsible for three workflow steps: grabbing tasks, updating status, and packaging/uploading. This code chunk only performs the grabbing step and prints the result. That is a materially narrower actual behavior than the declared purpose for this supplied chunk. Additionally, the code embeds default Yintai app key and secret and configures access to an external API endpoint, which is a sensitive external-resource capability not reflected in the declared permissions list. While use of an API is consistent with task grabbing, the undeclared hardcoded credentials and missing declared permissions make the description/permissions inaccurate relative to the code shown.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The README explicitly states that the skill will package and upload all files in the task workspace and then automatically delete that workspace, but it does not warn operators that sensitive, unintended, or tool-generated files may be swept into the archive. In this skill’s context, where the agent autonomously executes task instructions based on untrusted task descriptions, this increases the risk of exfiltrating secrets or deleting useful evidence/artifacts without review.

Lp3

Medium

Category: MCP Least Privilege
Confidence: 94% confidence
Finding: The skill declares required environment variables and implies network/file operations, but it does not declare an explicit tool scope such as permissions or allowed-tools. This weakens the security boundary because an agent can be induced to use broader capabilities than a user or platform reviewer would expect, especially given the documented autonomous workflow.

Missing User Warnings

Medium

Confidence: 91% confidence
Finding: The description does not clearly warn users that the skill can autonomously act on externally supplied task descriptions and upload generated artifacts to an external service. This creates consent and transparency risk because operators may invoke or schedule the skill without understanding that untrusted remote content can drive actions and exfiltrate outputs.

Ssd 4

Medium

Confidence: 96% confidence
Finding: The architecture section states that execution decisions are made entirely by the agent based on task title/description/category, while the skill handles packaging and upload. In this context, the skill is effectively a conduit from untrusted remote instructions to local action and external delivery, which materially increases the risk of prompt injection, unsafe file creation, and unintended disclosure in uploaded artifacts.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: The cron example enables unattended execution of tasks fetched from an external service, including analysis, production of artifacts, and upload, without any warning or approval gate. In practice this makes prompt-driven or task-text-driven behavior run automatically, which increases the risk of harmful actions, data leakage, or abuse at scale.

Ssd 4

Medium

Confidence: 97% confidence
Finding: The cron payload explicitly instructs the agent to grab a task, analyze arbitrary task text, execute based on that text, and upload results, with no stated safety gating. This is dangerous because it turns untrusted external content into an operational command chain, making prompt injection and unsafe delegated actions much more likely.

Description-Behavior Mismatch

Medium

Confidence: 84% confidence
Finding: The manifest says the skill only handles 抢单、更新状态、打包上传, while execution is left to the agent. This method fetches and returns rich task details including description, creator_id, visibility, assignment, and timestamps, which is beyond the narrowly stated operational scope and meaningfully expands what the skill does.

Missing User Warnings

Medium

Confidence: 83% confidence
Finding: This code transmits user-provided result descriptions and optional ZIP file contents to a remote service, which can affect user data/privacy. Within this file there is no confirmation prompt, print/log disclosure before the upload, or explicit warning comment indicating that local file contents will be sent over the network.

Natural-Language Policy Violations

Medium

Confidence: 91% confidence
Finding: The file's descriptive strings and comments are in Chinese, and the default delivery message is also fixed in Chinese, suggesting a language-specific behavior. There is no indication in this file that users can choose another language or opt into Chinese-only interaction, which may violate language/locale policy expectations.

Description-Behavior Mismatch

Medium

Confidence: 96% confidence
Finding: The package metadata explicitly describes the project as an "Agent-driven task grabbing, execution, and delivery," which broadens the advertised behavior beyond the stated skill scope of only grabbing tasks, updating status, and uploading artifacts. In an agent skill, scope ambiguity is security-relevant because downstream users, reviewers, or orchestration systems may grant permissions under false assumptions, enabling unintended autonomous execution.

Missing User Warnings

Medium

Confidence: 99% confidence
Finding: The script hardcodes credential-like values for YINTAI_APP_KEY and YINTAI_APP_SECRET via environment defaults, which embeds secrets directly in code and silently enables authenticated access when no explicit user configuration is provided. In a task-grabbing skill that can autonomously claim work from a remote service, this creates unauthorized-use risk, secret leakage, and abuse of the associated account or backend API.

Intent-Code Divergence

Medium

Confidence: 88% confidence
Finding: The top-level docstring explicitly states 'skill 只做三件事' and enumerates only three APIs. In reality, the module defines additional callable behaviors, including profile retrieval, manual task grabbing by ID, workspace deletion, and command-line execution support, which contradicts the stated exclusivity of the documented scope.

Description-Behavior Mismatch

Medium

Confidence: 91% confidence
Finding: The manifest and module docstring both limit the skill to three responsibilities: grabbing tasks, updating status, and packaging/uploading deliverables. However, the code also performs separate bot profile retrieval from historical/completed tasks and uses that data to influence task-selection behavior, which is additional operational scope beyond the declared three actions.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The code removes an existing task workspace with shutil.rmtree before recreating it, which is a destructive file operation. Although there is logging after recreation, there is no confirmation prompt or prior user-facing warning that existing contents will be erased.

Missing User Warnings

Medium

Confidence: 95% confidence
Finding: cleanup_workspace deletes the entire task workspace recursively, which can remove all generated artifacts. The function has only a brief internal docstring and post-action log, but no user-facing warning or confirmation that data will be permanently deleted.

Missing User Warnings

Medium

Confidence: 94% confidence
Finding: This function automatically uploads all files found in the workspace together with result text to a remote service, with no validation, allowlist, redaction step, or explicit consent gate. In this skill's context, the middle 'execution' is delegated to another agent based on task description, so untrusted task content could induce collection and exfiltration of sensitive local artifacts through the delivery channel.

Intent-Code Divergence

Low

Confidence: 76% confidence
Finding: The file-level documentation labels this as an 'OpenClaw Task Runner Skill', while the manifest names a different skill and emphasizes a constrained role limited to grabbing orders, updating status, and packaging/uploading. This creates intent ambiguity in the documentation about what system and responsibility boundary the code is actually for.

Natural-Language Policy Violations

Low

Confidence: 75% confidence
Finding: The file's human-readable docstrings, comments, and log message are written exclusively in Chinese, indicating a language-specific experience without any visible opt-in or alternative locale handling. The policy calls for flagging language or locale constraints when the skill forces a specific language without user choice.

Missing User Warnings

Low

Confidence: 83% confidence
Finding: The function reads `YINTAI_APP_KEY` and `YINTAI_APP_SECRET` from environment variables, which is access to sensitive credentials. In this file, there is no user-facing logging, warning, or explanatory comment about handling these secrets beyond brief inline labels, so the credential access lacks disclosure under the code-file warning criteria.

Unverifiable Dependency: setuptools has 10 known advisory(ies) (CVE-2013-1633 (Setuptools vulnerable to Man-in-the-middle attacks); CVE-2025-47273 (setuptools has a path traversal vulnerability in PackageIndex.download that lead); CVE-2024-6345 (setuptools vulnerable to Command Injection via package URL) +7 more), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

Category: Supply Chain
Confidence: 40% confidence
Finding: Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.

Unverifiable Dependency: wheel has 4 known advisory(ies) (CVE-2026-24049 (Wheel Affected by Arbitrary File Permission Modification via Path Traversal in w); CVE-2022-40898 (pypa/wheel vulnerable to Regular Expression denial of service (ReDoS)); CVE-2022-40898 (An issue discovered in Python Packaging Authority (PyPA) Wheel 0.37.1 and earlie) +1 more), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

Category: Supply Chain
Confidence: 40% confidence
Finding: Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.

Unverifiable Dependency: httpx has 2 known advisory(ies) (CVE-2021-41945 (Improper Input Validation in httpx); CVE-2021-41945 (Encode OSS httpx <=1.0.0.beta0 is affected by improper input validation in `http)), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

Category: Supply Chain
Confidence: 40% confidence
Finding: Dependency has known vulnerabilities (CVEs). Using packages with unpatched security flaws exposes the environment to known exploits.

Missing User Warnings

Low

Confidence: 84% confidence
Finding: The script automatically connects to a remote task service and grabs a task without any user confirmation, disclosure, or policy gate. In this skill's context, where the agent then participates in task execution and delivery workflows, silent network-backed task acquisition can trigger unintended external actions, data handling, and operational abuse if the skill is invoked unexpectedly or by an untrusted workflow.

Static analysis

Detected: suspicious.exposed_secret_literal

File appears to expose a hardcoded API secret or token.

Critical

Code: suspicious.exposed_secret_literal
Location: api_client.py:88