T09 · Insecure Skill Coding Practices
Warning
- Location
- skills.md:122
- Finding
- Hard-Coded Idempotency Key Causes Cross-Request Collisions## Vulnerability Details **File Location**: `skills.md`, lines 122–127 **Vulnerability Type**: Hard-coded idempotency key **Risk Level**: Medium ### Vulnerable Code ```text ### Required headers Content-Type: application/json Idempotency-Key: 9c4b9f2b-3d56-4c6c-8f2a-2b0f4c65c2b8 User-Agent: openclaw-agent ``` The global instructions at lines 86–91 establish the intended semantics: ```text Rules: - Clients should send an `Idempotency-Key` header (UUID recommended) - Retrying the same request with the same key is safe - Reusing a key with a different payload is an error - Bots should persist keys across retries and restarts ``` ### Technical Analysis The documented required headers contain a literal UUID rather than an unambiguous placeholder or instructions to generate a new value. An autonomous agent following the example literally may therefore reuse the same idempotency key for different early-access signup payloads. This conflicts with the document's own rule that a key must not be reused with a different payload. Idempotency keys identify a single logical write operation: the key should remain stable when retrying that operation but must be unique for each new operation. A globally reused key can cause the server to reject a later request or return a cached result belonging to an earlier request, depending on how the endpoint scopes and implements idempotency. The UUID is not an authentication secret, so this issue does not directly disclose credentials or grant elevated privileges. The risk arises from unsafe request configuration and its effect on operation integrity and availability. ### Attack Path 1. An agent loads `skills.md` and follows the early-access instructions. 2. The agent copies the fixed `Idempotency-Key` value into a signup request. 3. Another agent or a later signup submits a different contact or payload using the same documented value. 4. The server detects that the key has be ...[truncated 842 chars]
- Remediation
- ## Remediation Suggestions - Replace the literal UUID with an explicit placeholder, such as: ```text Idempotency-Key: <unique-uuid-for-this-logical-request> ``` - Direct clients to generate a fresh, cryptographically random UUID for every new logical signup. - Persist the generated key together with a canonical representation or hash of the request payload. - Reuse that key only when retrying the exact same operation and payload after a timeout or retryable failure. - Generate a new key whenever the contact or any other request field changes. - Add a complete request example that generates the UUID dynamically rather than inviting users or agents to copy a fixed value. - On the server, scope idempotency records to the authenticated client and endpoint where possible, compare payload hashes on key reuse, and reject mismatches without exposing another request's response.