今日盘前机会

• Outcome: Review
• Latest audit: Sep 8, 2026 · 3:32 AM UTC
• Version: 1.0.4

Overview

The skill has a clear market-research purpose, but it asks users to run an unpinned remote Python runner and store a Cue API key in plaintext, so it should be reviewed before installation.

Install only if you trust the sensedeal cue-skills repository and Cue service. Prefer pinning the repository to a reviewed commit, checking the runner before execution, storing the API key with owner-only permissions, and rotating the key if it may have been exposed.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:65
• Finding: Unpinned Remote Repository Is Downloaded and Executed Locally## Vulnerability Details **File Location**: `SKILL.md`, lines 65-68 and 91-95 **Vulnerability Type**: Mutable remote payload retrieval and execution **Risk Level**: High ```bash # 1. 克隆 runner 到 ~/.cue/cue-skills mkdir -p ~/.cue && git clone https://github.com/sensedeal/cue-skills ~/.cue/cue-skills # 国内网络慢可换 Gitee 镜像： # git clone https://gitee.com/sensedeal/cue-skills ~/.cue/cue-skills ``` ```bash python3 ~/.cue/cue-skills/cue-research/scripts/research_run.py \ --query "今日盘前策略：隔夜全球事件→A股映射→产业链传导→爆发力主题" \ --template-id template_qsweF9 \ --output ~/cue-reports/$(date +%Y-%m-%d-%H%M)-pre-market.md ``` ### Technical Analysis The installation instructions clone the current default branch of an external GitHub or Gitee repository without pinning a reviewed commit, verifying a cryptographic signature, or checking file hashes. A Python program obtained from that mutable repository is subsequently executed with the user's privileges. The effective code therefore remains changeable after this Skill has been audited. The Gitee alternative creates an additional supply-chain trust point, and the instructions do not establish that both repositories contain identical, verified content. This is not the same as the pre-scan's suspected `curl | bash` behavior: the health-check response at line 154 is parsed as JSON by a fixed local Python expression rather than executed as source code. The confirmed remote-execution concern instead arises from cloning and running the unpinned repository. ### Attack Path 1. An attacker compromises the upstream maintainer account, repository, distribution mirror, or another part of the repository publication process. 2. The attacker modifies `cue-research/scripts/research_run.py` or a module imported by it on the repository's default branch. 3. A user follows the documented installation instructions and clones the modified repository. 4. The user or agent invokes `research_run ...[truncated 742 chars]
• Remediation: ## Remediation Suggestions - Pin the repository to a specific reviewed commit hash or immutable, signed release. - Publish and verify a cryptographic checksum for every downloaded executable file. - Require signed commits or release artifacts and document signature verification before execution. - Do not treat GitHub and Gitee as interchangeable sources unless both artifacts are independently verified against the same trusted digest. - Vendor the minimal reviewed runner into the Skill package where feasible. - Run the remote client with restricted filesystem and network access, such as in a dedicated container or sandbox. - Ensure the runner can access only the required API endpoint, API credential, query input, and selected output directory. - Re-audit the pinned runner and its imports whenever the pinned version changes.

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:70
• Finding: Cue API Key Storage Does Not Enforce Owner-Only Permissions## Vulnerability Details **File Location**: `SKILL.md`, lines 70-71 **Vulnerability Type**: Insecure credential storage and potential shell-history exposure **Risk Level**: Medium ```bash # 2. 写入 API Key（在 https://cuecue.cn/hub/api-key 创建后复制） mkdir -p ~/.cue && echo '{"api_key":"sk..."}' > ~/.cue/config.json ``` ### Technical Analysis The documented command writes the API key to a plaintext file without explicitly setting restrictive directory or file permissions. Resulting permissions depend on the user's current `umask`. On a permissively configured or shared system, the file may be readable by other local accounts. If the user substitutes the actual key directly into the displayed `echo` command, the secret may also be retained in shell history, terminal logging, process auditing, or copied command records. The example contains only a placeholder and does not itself expose a real credential, but the prescribed entry method creates this risk. ### Attack Path 1. A user replaces the placeholder with a valid Cue API key and runs the documented command. 2. The command is saved in shell history or the resulting file is created with permissions derived from an insufficiently restrictive `umask`. 3. Another local user, support process, backup collector, or actor with access to the user's history or readable files obtains the key. 4. The actor uses the stolen key against the Cue service within the authorization scope assigned to that credential. ### Impact Assessment Exposure may allow unauthorized use of the victim's Cue account capabilities, consumption of associated credits, access to API-visible account or task data where authorized by the key, and impersonation of the user to the Cue API. This issue does not establish system-level privilege escalation. Its scope is limited to local disclosure opportunities and whatever remote permissions the Cue API key grants.
• Remediation: ## Remediation Suggestions - Create the credential directory with owner-only permissions: ```bash install -d -m 700 "$HOME/.cue" ``` - Create the configuration file with mode `600`, independent of the current `umask`. - Avoid placing the key directly in a shell command. Read it through silent input, an operating-system credential store, or another mechanism that does not persist it in command history. - Prefer a platform secret manager or keychain over a plaintext configuration file where supported. - Ensure logs and diagnostics never print the authorization header or complete key. - Document key rotation and revocation procedures for suspected disclosure. - Restrict the API key to the minimum service permissions and usage limits required for research requests.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill instructs users to place a long-lived API key in plaintext under ~/.cue/config.json and then read it back into shell commands for curl-based health checks, but it provides no nearby warning about secret handling, file permissions, shell history, or multi-user system exposure. While this is common operational guidance rather than overtly malicious behavior, it increases the chance of credential leakage through weak local permissions, backups, endpoint compromise, or accidental disclosure.

Static analysis

No suspicious patterns detected.