Giggle Generation Aimv

• Outcome: Review
• Latest audit: Sep 11, 2026 · 9:52 PM UTC
• Version: 0.0.10

Overview

This skill is for Giggle MV generation, but it can automatically make a billable payment using your Giggle API key without a separate confirmation step.

Review this before installing if your Giggle account can be charged. Only use it if you are comfortable with the workflow automatically paying pending MV projects through GIGGLE_API_KEY; a safer version would require explicit confirmation of amount and project before payment.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: scripts/trustee_api.py:426
• Finding: Automatic Payment Without Explicit User Authorization<![CDATA[ ## Vulnerability Details **File Location**: `scripts/trustee_api.py:426-436` **Vulnerability Type**: `T05: Unauthorized Access and Privilege Escalation` **Risk Level**: High ### Vulnerable Code ```python if not paid and (pay_status == "pending" or (current_step and "pay" in current_step.lower())): print(f"[{datetime.now().strftime('%H:%M:%S')}] [{project_id}] 执行支付...", file=sys.stderr) pay_result = self.pay(project_id) code = pay_result.get("code") if isinstance(code, str): code = int(code) if code.isdigit() else 0 if code != 0 and code != 200: return {"code": code, "msg": f"支付失败: {pay_result.get('msg', '未知错误')}", "data": None} paid = True continue ``` The automatic-payment behavior is also documented in `SKILL.md:101-106` and `SKILL.zh-CN.md:101-106`. ### Technical Analysis The `execute_workflow` method automatically calls the authenticated payment endpoint when the remote API reports either: - `pay_status == "pending"`; or - a `current_step` value containing the substring `"pay"`. No explicit user confirmation is obtained immediately before payment. The implementation also does not retrieve and present the price in advance, validate an expected amount or currency, or enforce a user-defined spending limit. The decision to initiate payment consequently depends on status data returned by the remote service. Although automatic payment is mentioned in the skill documentation, starting an MV-generation workflow does not provide transaction-specific consent to an unknown charge. ### Attack Path 1. A user invokes `execute_workflow` to generate an MV. 2. The skill creates a project and submits the generation task using the user's `GIGGLE_API_KEY`. 3. During polling, the remote API returns `pay_status: "pending"` or a `current_step` containing `"pay"`. 4. The condition at lines 426-427 is satisfied. 5. The skill immediately calls `self.pay(project_id)` using the authenticated account. 6. The payment opera ...[truncated 842 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Remove automatic payment from `execute_workflow`. 2. When payment is required, return a structured response containing the project identifier, exact price, currency, and payment status. 3. Require explicit user confirmation immediately before calling `pay`. 4. Add a user-configurable maximum spending limit and reject amounts exceeding it. 5. Validate that the payment request belongs to the expected project and account. 6. Use an exact payment-state comparison rather than matching the substring `"pay"` in `current_step`. 7. Record a non-secret audit event containing the approved amount, project identifier, timestamp, and result. 8. Where supported, use a restricted API credential that cannot initiate payments without additional authorization. ]]>

T08 · Insecure Dependencies

Note

• Location: scripts/requirements.txt:1
• Finding: Unbounded Third-Party Dependency Version<![CDATA[ ## Vulnerability Details **File Location**: `scripts/requirements.txt:1` **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Low ### Vulnerable Code ```text requests>=2.31.0 ``` ### Technical Analysis The dependency declaration specifies only a minimum version of `requests`. Package installation can therefore resolve to any later release available from the configured package index. No lock file or cryptographic hashes are supplied to make installation reproducible or verify the exact artifact selected. The dependency is legitimate and consistent with the skill's declared network functionality. There is no evidence that the current `requests` package is malicious. The risk is prospective: an incompatible, compromised, or otherwise unsafe future release could be selected automatically during installation. ### Attack Path 1. An installer processes `scripts/requirements.txt`. 2. The package resolver selects the newest available `requests` version satisfying `>=2.31.0`. 3. If the selected future release or distribution artifact is compromised or incompatible, it is installed because no upper bound, exact pin, or integrity hash prevents its selection. 4. The installed package code is imported by `_check_requests()` when the skill runs. 5. Any malicious package-level behavior would then execute with the privileges of the user running the skill. This attack path is contingent on compromise of the dependency distribution channel or a future unsafe release; no such compromise was observed in the audited project. ### Impact Assessment A compromised dependency would execute in the local Python process and inherit the user's process permissions. It could potentially access environment variables, including `GIGGLE_API_KEY`, make network requests, and read or modify files accessible to that user. The confirmed project issue is the absence of deterministic dependency pinning and integrity verification, not evidence of an existing maliciou ...[truncated 17 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin `requests` to a specifically reviewed version instead of using an open-ended minimum constraint. 2. Generate and commit a lock file containing cryptographic hashes, for example with `pip-tools` and `--generate-hashes`. 3. Install dependencies with hash verification enabled. 4. Review and update the pinned version on a controlled schedule after security and compatibility testing. 5. Use a trusted package index and prevent fallback to unapproved indexes. 6. Run dependency vulnerability scanning in continuous integration. ]]>

SkillSpector

Vulnerability Patterns

• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (13)

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: The workflow explicitly states it will detect pending payment states and call the pay endpoint automatically, but the skill description and earlier warning sections do not clearly disclose that execution may incur charges. This is especially dangerous because a user or agent could invoke the skill expecting generation only, while the workflow proceeds to bill the associated account without separate informed consent.

Description-Behavior Mismatch

High

• Confidence: 99% confidence
• Finding: The execute_workflow() routine automatically transitions from task creation into payment when pay_status is pending or the current step suggests payment. This is dangerous because a user asking to generate an MV could unknowingly trigger a billable action, making the skill capable of spending funds without a distinct consent boundary.

Context-Inappropriate Capability

High

• Confidence: 98% confidence
• Finding: The automatic call to pay() is not necessary to satisfy the stated purpose of creating AI music videos and therefore broadens the skill's authority into financial operations. In practice, this enables an agent to convert a content-generation request into a purchase flow, increasing the risk of unauthorized or surprising charges.

Lp3

Medium

• Category: MCP Least Privilege
• Confidence: 95% confidence
• Finding: The skill requires access to environment variables and performs outbound network calls, but it does not declare an explicit tool scope such as permissions or allowed-tools. This weakens sandboxing and review controls because an agent may invoke capabilities not clearly surfaced to operators, increasing the risk of unintended secret access or network use.

Vague Triggers

Medium

• Confidence: 94% confidence
• Finding: The trigger list contains broad phrases like 'music video' and 'lyrics video', which can cause the skill to activate for ambiguous user requests that may not intend external API use. In this skill's context, over-triggering is more dangerous because activation can lead to network requests and an automated payment-capable workflow.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The documentation gives conflicting operational guidance: it says not to retry on error, but later states the script auto-retries network failures up to 5 times. In a workflow that can trigger payment and long-running API actions, contradictory retry semantics can cause duplicate submissions, repeated charges, or unsafe agent behavior under failure conditions.

Intent-Code Divergence

Medium

• Confidence: 95% confidence
• Finding: The documentation tells the operator both 'do not retry on error' and later that network failures should be retried automatically up to 5 times. This inconsistency can lead to unsafe or unintended repeated requests in a workflow that also submits jobs and may trigger payment, causing duplicate actions, unexpected charges, or confusing operational behavior.

Missing User Warnings

Medium

• Confidence: 98% confidence
• Finding: The skill states that the workflow will automatically detect and pay pending items, but it does not prominently warn that invoking the workflow can incur real charges. In an agent setting, this creates a high risk of unauthorized or surprising purchases because a user may think they are only generating content, not approving payment.

Description-Behavior Mismatch

Medium

• Confidence: 97% confidence
• Finding: The file exposes a dedicated pay() method that executes a billable remote action, which exceeds the advertised skill purpose of generating music videos. In an agent setting, this creates a financial-action capability that could be invoked without the user clearly understanding that money may be charged.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The workflow performs a sequence that may culminate in payment, but there is no explicit warning or confirmation step at the workflow entry point informing the operator that charges may occur. This weakens user consent and makes accidental spending more likely, especially when embedded in autonomous agent behavior.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The CLI exposes a pay command that directly triggers a billable action without any safety prompt, dry-run mode, or confirmation guard. This can lead to accidental charges from mistaken command execution, script misuse, or agent/tool invocation without the operator recognizing the financial consequence.

Unpinned Dependencies

Low

• Category: Supply Chain

Content

requests>=2.31.0

• Confidence: 93% confidence
• Finding: The dependency is specified as `requests>=2.31.0`, which allows any future version and does not guarantee a known-good, reproducible install. This can introduce vulnerable or breaking releases into the environment over time and makes it difficult to verify whether deployed versions are affected by published advisories.

Unverifiable Dependency: requests has 16 known advisory(ies) (CVE-2014-1830 (Exposure of Sensitive Information to an Unauthorized Actor in Requests); CVE-2024-47081 (Requests vulnerable to .netrc credentials leak via malicious URLs); CVE-2024-35195 (Requests `Session` object does not verify requests after making first request wi) +13 more), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low

• Category: Supply Chain
• Confidence: 90% confidence
• Finding: Because `requests` is not pinned, the manifest does not let reviewers determine whether the installed version is vulnerable to any of the known advisories affecting that package. In a skill that may interact with external services or user-supplied URLs/media workflows, uncertainty around HTTP client security increases supply-chain and runtime risk.

Static analysis

No suspicious patterns detected.