Back to skill

Security audit

上市公司财报分析

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent for financial-report analysis, but it asks users to run unpinned code from an external repository and store an API key locally without adequate safeguards.

Review this skill before installing. Use it only if you trust the sensedeal Cue runner repository and Cue service with your research queries. Prefer a pinned, verified runner commit, restrict ~/.cue/config.json to owner-only access, avoid confidential or non-public company research inputs, and rotate the Cue API key if the config file may have been exposed.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T03 · Remote Payload Retrieval and Execution

Error
Location
SKILL.md:102
Finding
Mutable Remote Repository Is Downloaded and Executed Without Integrity Verification<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 102-128 **Vulnerability Type**: Remote payload retrieval and execution **Risk Level**: High ### Complete Code Snippet ```bash mkdir -p ~/.cue && git clone https://github.com/sensedeal/cue-skills ~/.cue/cue-skills # Alternative mirror: # git clone https://gitee.com/sensedeal/cue-skills ~/.cue/cue-skills ``` The downloaded runner is subsequently executed: ```bash python3 ~/.cue/cue-skills/cue-research/scripts/research_run.py \ --query "Target company earnings analysis: core indicators, business drivers, earnings quality, and supply-chain bargaining power" \ --template-id template_7qiAwz \ --output ~/cue-reports/$(date +%Y-%m-%d-%H%M)-earnings-analysis.md ``` ### Technical Analysis The installation procedure clones the mutable default branch of an externally controlled Git repository and later executes a Python script from that repository. It does not pin a reviewed commit hash or signed release and does not verify a checksum, signature, or trusted provenance before execution. This behavior is not literally a `curl | bash` pipeline. The separately flagged pipeline at line 180 passes an API response to a fixed Python JSON parser and does not execute the response as code. Nevertheless, cloning mutable remote code and executing it creates the same central review-time mutability concern: the effective local payload can change after the Skill itself has been audited. The Gitee mirror provides an additional mutable supply-chain source. A compromise of either repository, its maintainer account, release process, or hosting platform could cause later installations to retrieve code that was not present during this audit. The financial-analysis task requires communication with the Cue API, but it does not inherently require unrestricted execution of the latest contents of an unpinned external repository. This therefore exceeds the capability that can be safely validated from the reviewed a ...[truncated 1795 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin the runner to a reviewed, immutable commit: ```bash git clone https://github.com/sensedeal/cue-skills ~/.cue/cue-skills git -C ~/.cue/cue-skills checkout --detach <reviewed-commit-hash> ``` 2. Publish and verify a cryptographic checksum or signed release before execution. 3. Prefer signed Git tags and verify the signature against a documented maintainer key. 4. Vendor the minimal reviewed runner into the Skill package when licensing and maintenance requirements permit. 5. Treat mirrors as separate trust roots. Do not present a mirror as interchangeable unless its contents and signatures are independently verified. 6. Review the runner and all imported local modules before approving a new commit. 7. Execute the runner as an unprivileged user in a restricted environment with access only to: - The required Cue credential. - The intended report output directory. - The Cue API endpoints required for the task. 8. Avoid exposing unrelated environment variables, home-directory files, or broad filesystem mounts to the runner. 9. Document an update process that requires review and hash changes rather than automatically following the upstream default branch. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:107
Finding
Cue API Key Is Stored Without Enforced Owner-Only File Permissions<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 107 **Vulnerability Type**: Insecure plaintext credential storage **Risk Level**: Medium ### Complete Code Snippet ```bash mkdir -p ~/.cue && echo '{"api_key":"sk..."}' > ~/.cue/config.json ``` ### Technical Analysis The command writes a bearer API key directly to `~/.cue/config.json` but does not explicitly set restrictive permissions on either the directory or the file. The resulting permissions depend on the user's current `umask` and any pre-existing permissions on `~/.cue`. On systems with a permissive `umask`, shared home-directory access, backup exposure, or multiple local users, the credential may become readable by accounts or processes that do not need it. Because the key is used as a bearer token, possession may be sufficient for unauthorized Cue API requests. Storing a credential locally may be necessary for the declared workflow, but world-readable or group-readable storage is not necessary. The instructions therefore fail to enforce minimum access privileges for the secret. ### Attack Path 1. A user runs the documented configuration command under a permissive `umask`, or the `~/.cue` directory already has overly broad permissions. 2. `~/.cue/config.json` is created with permissions that allow an unintended local user, shared process, or backup context to read it. 3. The attacker reads the JSON file and extracts the bearer API key. 4. The attacker submits requests to the Cue API using the stolen credential. 5. The unauthorized requests may consume account credits or access resources available to that API identity. Exploitation requires local filesystem access or access through another process, backup, or account that can read the file. The artifact does not show the key being transmitted to an unrelated host. ### Impact Assessment The exposed privilege is limited to the authority assigned to the Cue API key. Plausible consequences include: - Unauthorized use of the C ...[truncated 450 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Create the configuration directory and credential file with explicit owner-only permissions: ```bash install -d -m 700 "$HOME/.cue" umask 077 printf '%s\n' '{"api_key":"sk..."}' > "$HOME/.cue/config.json" chmod 600 "$HOME/.cue/config.json" ``` Additional hardening measures: 1. Prefer an operating-system credential store or secret manager where supported. 2. If environment-based injection is supported, provide the key only to the runner process rather than exporting it globally. 3. Never include real keys in shell history, logs, examples, generated reports, or error output. 4. Validate existing installations and reject configuration files that are readable by group or other users. 5. Support credential rotation and immediate revocation after suspected disclosure. 6. Scope API keys to the minimum required operations and apply server-side quotas. 7. Ensure backups containing the configuration file are encrypted and access-controlled. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (2)

Missing User Warnings

Medium
Confidence
95% confidence
Finding
The skill explicitly instructs users to place a long-lived API key in ~/.cue/config.json and even reads it back from shell commands, but it does not warn about file permissions, secret rotation, shell history exposure, or safer alternatives such as environment variables or OS keychains. This increases the chance of credential disclosure through overly permissive filesystem access, backups, screenshots, or multi-user systems.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
Although the architecture section says requests go to Cue API and external data sources, the skill does not provide a clear privacy warning near usage that company queries, report parameters, and possibly associated metadata are transmitted to a third-party service. Users may unknowingly send sensitive research interests, internal watchlists, or proprietary analysis targets to an external operator.

Static analysis

No suspicious patterns detected.