Security audit

OVERCLOCK Agent

Security checks for vulnerabilities and agentic risk

Overview

This skill is for an autonomous game agent, but it includes paid purchase flows, log access, and conflicting API hosts without enough scoping or user confirmation.

Review this skill carefully before installing. Only use it if you are comfortable with an autonomous agent making game-state changes, and require explicit approval and a spending cap before any card-pack purchase. Treat the log endpoint and conflicting API hosts as publisher issues that should be clarified or fixed before routine use.

A.I.G

Vulnerability Patterns

Unauthorized Access and Privilege EscalationObtains permissions beyond the task's legitimate needs
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
Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review

Findings (3)

other

Error

Location: SKILL.md:44
Finding: Paid Purchase Operations Lack Explicit User Approval and Spending Controls<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 44-62 and 95-101 **Vulnerability Type**: Autonomous financial transaction without confirmation **Risk Level**: High ### Vulnerable Code Snippet ```markdown ### 3. Card Pack Purchase ```bash POST /api/overclock/purchase Headers: X-Player-Id: your-agent-name Content-Type: application/json { "packType": "basic", "source": "acp" } ``` **Packs (Early Bird 50% off Basic/Standard):** | Pack | Price | Cards | Guaranteed | |---|---|---|---| | basic | **$2** | 3 | Common | | standard | **$4** | 5 | Uncommon | ``` The purchase is incorporated into the default workflow: ```markdown 1. GET /api/game → Check your state (auto-creates account) 2. POST /api/overclock/purchase → Buy card packs 3. POST /api/game/strategy → Set your strategy 4. POST /api/game/battle → Fight! (wait 20s between) 5. GET /api/game/players → Check leaderboard ``` ### Technical Analysis The skill advertises autonomous gameplay and directs the agent to call a paid purchase endpoint as part of its quick-start workflow. It does not require explicit, transaction-specific user approval, display a final charge before submission, establish a spending ceiling, or distinguish virtual currency from real-money payment authorization. The documented `X-Player-Id` header identifies the affected player but is not described as providing transaction-scoped authorization. Consequently, once the skill is invoked, an agent following the workflow may interpret purchasing as an authorized routine action rather than a separate financial decision requiring informed consent. This violates least-authority principles for consequential external actions. Authorization to play a game does not inherently grant authority to incur monetary charges. ### Attack Path 1. A user activates the skill to play the game autonomously. 2. The agent follows the documented quick-start procedure. 3. A game account is automatically created or loaded using `GET /api ...[truncated 837 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Require explicit, transaction-specific user confirmation immediately before every paid request. - Display the pack type, quantity, exact currency, exact price, payment source, and resulting balance before confirmation. - Default purchase functionality to disabled unless the user affirmatively enables it. - Introduce a user-configured per-transaction and cumulative session spending limit. - Never infer purchase authorization from general permission to play the game. - Use idempotency keys to prevent duplicate charges caused by retries. - Provide a dry-run or quote endpoint that performs no charge. - Record an auditable consent event tied to the exact transaction. - Stop after any ambiguous response instead of automatically retrying a purchase. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

Location: MISSION_QA.md:14
Finding: Routine QA Instructions Encourage Access to Potentially Global Server Logs<![CDATA[ ## Vulnerability Details **File Location**: `MISSION_QA.md`, lines 14 and 32 **Vulnerability Type**: Potential unauthorized operational-log access **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown GET /api/logs → Error logs ``` The mission explicitly directs users to generate an error and inspect the logs: ```markdown ### 3. Find Bugs (try invalid packType, check /api/logs) ``` The same endpoint is also exposed in `SKILL.md`, lines 91-93: ```markdown ### 7. Error Logs ```bash GET /api/logs ``` ``` ### Technical Analysis The QA workflow instructs an ordinary skill user to query a general `/api/logs` endpoint after intentionally submitting invalid input. Neither document specifies administrator authorization, player-level filtering, redaction, or access controls for this endpoint. Operational logs frequently contain request metadata, internal exception details, identifiers, other users' activity, infrastructure information, or inadvertently logged sensitive values. A generic log endpoint that is available within a normal player workflow can therefore cross the least-privilege boundary between player functionality and operational administration. The project contains documentation rather than server implementation, so it cannot be confirmed from the reviewed files whether the endpoint actually exposes global or sensitive records. The unsafe aspect confirmed by the audit is that the skill encourages access without defining or enforcing an appropriate authorization boundary. ### Attack Path 1. A player or agent follows the QA mission. 2. The agent submits an invalid `packType` to provoke an application error. 3. The agent requests `GET /api/logs`. 4. If the endpoint lacks administrative authorization or player-scoped filtering, the server returns operational records. 5. The caller reviews generated and potentially unrelated entries for internal errors, identifiers, request details, or data belonging to other play ...[truncated 611 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Remove `/api/logs` access from ordinary player and autonomous-agent workflows. - Restrict the endpoint to authenticated administrators with explicit role-based authorization. - Return only player-scoped, correlation-ID-based diagnostics when users need troubleshooting information. - Redact authorization headers, payment data, personal identifiers, tokens, stack traces, and internal host details. - Use a dedicated sanitized error-report endpoint rather than exposing raw operational logs. - Apply rate limiting, access auditing, retention controls, and alerts for unusual log access. - Ensure malformed-input testing occurs only in an authorized test environment, not against production services. - Document the required authorization and the exact scope of records returned. ]]>

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:12
Finding: Conflicting API Origins Can Route Identity and State-Changing Requests to an Unverified Service<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 12; `MISSION_QA.md`, line 5; `resources/API.md`, line 4 **Vulnerability Type**: Inconsistent trusted-endpoint configuration **Risk Level**: Medium ### Vulnerable Code Snippet `SKILL.md` specifies: ```markdown ## API Base URL ``` https://overclock-903028338458.us-central1.run.app ``` ``` `MISSION_QA.md` specifies the same origin: ```markdown **Base URL:** `https://overclock-903028338458.us-central1.run.app` ``` However, `resources/API.md` specifies a different origin: ```markdown ## Base URL ``` https://synth-colosseum-wukg3jhefq-uc.a.run.app ``` ``` ### Technical Analysis The package defines two distinct API origins without identifying one as canonical, explaining an environment distinction, or documenting ownership and trust requirements. Both sets of documentation describe state-changing operations, including battles, strategy updates, and card-pack purchases. An agent may select either reference depending on which file it treats as authoritative. Requests include the `X-Player-Id` value under the primary documentation, and purchase requests may affect account balances. Sending these requests to an unintended service can disclose player identifiers or mutate the wrong account and environment. This is an insecure configuration practice rather than proof that either listed service is malicious. Nevertheless, ambiguity in the trust boundary is security-relevant because agents routinely act directly on skill documentation and may not independently verify backend ownership. ### Attack Path 1. The agent loads the project documentation and encounters two conflicting API origins. 2. The agent selects `resources/API.md` or combines endpoint information from multiple files. 3. It sends game-state, strategy, battle, or purchase requests to the alternate origin. 4. The alternate service receives player identifiers and request contents. 5. If that origin is obsolete, incorrectly controlled ...[truncated 763 chars]
Remediation: <![CDATA[ ## Remediation Suggestions - Define one canonical, verified API origin in a single configuration source. - Update every document to reference that source rather than duplicating the URL. - If multiple environments are required, label them explicitly as production, staging, or development and prevent cross-environment credentials or identities. - Document service ownership and the expected TLS hostname. - Require an allowlist of approved origins and reject unrecognized hosts and cross-origin redirects. - Pin consequential operations such as purchases to the verified production origin. - Add automated consistency checks that fail packaging or release when documentation contains conflicting base URLs. - Include migration and deprecation notices when replacing an endpoint. ]]>

SkillSpector

Vulnerability Patterns

Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (3)

Missing User Warnings

Medium

Confidence: 97% confidence
Finding: The skill explicitly exposes a purchase endpoint with concrete dollar prices for card packs but does not warn users that invoking the action may incur real-world charges. In an autonomous agent context, this is dangerous because an agent may repeatedly call the purchase API without meaningful user awareness or consent, causing unintended spending.

Missing User Warnings

Low

Confidence: 92% confidence
Finding: The API reference exposes a purchase endpoint that changes account balance and acquires assets, but it does not clearly warn that invoking it spends in-game currency or may have irreversible account effects. In an autonomous agent skill, omission of transaction-impact warnings is dangerous because an agent may repeatedly call the endpoint as part of normal operation and deplete user resources without meaningful user awareness or confirmation.

Missing User Warnings

Low

Confidence: 95% confidence
Finding: The quick-start sequence instructs users or agents to repeat battle and purchase actions in a loop without warning about resource depletion, balance changes, or rate-limit/automation risks. In the context of an autonomous play skill, this materially increases danger because the repetition guidance can drive unattended spending and repeated state-changing actions as a default operating pattern.

Static analysis

No suspicious patterns detected.