T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:52
- Finding
- Unauthenticated API Key Claim Enables Agent Identity Takeover## Vulnerability Details **File Location**: `SKILL.md:52-57` **Vulnerability Type**: Unauthenticated credential issuance **Risk Level**: High **Vulnerable documentation:** ```text ### Step 2: Get your API key Send a POST request to claim: POST https://agentindex.world/api/auth/claim Content-Type: application/json {"agent_name":"YOUR_AGENT_NAME"} This returns a 64-character API key. Save it immediately -- it is shown only once. ``` The API reference at `SKILL.md:204` also explicitly identifies the endpoint as unauthenticated: ```text | /api/auth/claim | POST | No | Get API key (one-time) | ``` ### Technical Analysis The documented credential-claim workflow requires only the agent's public name and does not describe any proof of ownership, registration secret, authenticated session, signed challenge, or out-of-band verification. Because `/api/auth/claim` is explicitly documented as requiring no authentication, knowledge of a registered agent name appears sufficient to request its bearer API key. Agent names are public or discoverable through the registry and search endpoints. Consequently, treating an agent name as the sole claim credential creates a race condition: an attacker can claim a newly registered identity before its legitimate owner. The fact that the key is issued only once does not mitigate this issue; instead, it may prevent the legitimate owner from recovering the credential after an attacker claims it. ### Attack Path 1. The victim registers an agent through `/api/register`. 2. The attacker observes, predicts, or discovers the victim's public agent name through the registry, search API, logs, or normal communication. 3. Before the victim completes the claim operation, the attacker sends: ```http POST /api/auth/claim HTTP/1.1 Host: agentindex.world Content-Type: application/json {"agent_name":"VICTIM_AGENT_NAME"} ``` 4. Because the documented endpoin ...[truncated 1204 chars]
- Remediation
- ## Remediation Suggestions 1. Generate a cryptographically random, single-use claim secret during registration and return it only to the registering party. 2. Require both the agent name and claim secret when calling `/api/auth/claim`; never issue credentials based solely on a public identifier. 3. Give claim secrets a short expiration period, bind them to the intended identity, and invalidate them atomically after successful use. 4. Where an agent has a domain or public key, require ownership verification through a signed challenge, DNS record, or verified callback. 5. Apply per-IP, per-identity, and global rate limits to registration and claim attempts, with monitoring and alerts for suspicious races. 6. Do not expose whether a particular identity is awaiting a claim beyond what is operationally necessary. 7. Provide a secure recovery and revocation process so the legitimate owner can invalidate a stolen API key. 8. Log credential issuance and notify the registered owner through a separately verified channel. 9. Update `SKILL.md`, `README.md`, and the API documentation to describe the ownership-verification requirement and secure handling of claim secrets. 10. Add automated tests demonstrating that a claim request containing only an agent name is rejected.