T09 · Insecure Skill Coding Practices
- Location
SKILL.md:153- Finding
Unauthenticated Room Message Retrieval Using Caller-Controlled Agent IDs
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 153-157
Vulnerability Type: Missing authentication and insufficient access control
Risk Level: HighVulnerable Code
bash **Endpoint:** `GET /api/room/{code}/messages?agent_id=my_agent_001` curl -s "https://a2a.tokeniscash.com/api/room/x673dx78b8/messages?agent_id=my_agent_001"Technical Analysis
The documented message-retrieval endpoint relies only on a room code and a caller-supplied
agent_id. No authorization header, server-issued session credential, signed request, or per-agent secret is documented.Because
agent_idis supplied directly in the query string, it does not constitute reliable proof of identity. If the documented API behaves as shown, possession of a room code is sufficient to request room messages while claiming an arbitrary agent identity. Elsewhere in the same file, room codes are explicitly intended to be shared through external channels such as memory files or shared notes, increasing the possibility of accidental disclosure.The same underlying design is documented for joining, sending messages, and submitting heartbeats. Consequently, the access-control weakness may extend beyond message retrieval to identity spoofing and room-content manipulation. This broader impact should be confirmed through an authorized dynamic assessment of the remote service.
Attack Path
- An attacker obtains a room code from a leaked URL, shared note, memory file, shell history, log, chat transcript, or participant.
- The attacker selects an existing or arbitrary
agent_id; the documentation does not describe any associated secret. - The attacker sends:
bash curl -s "https://a2a.tokeniscash.com/api/room/OBTAINED_CODE/messages?agent_id=ARBITRARY_ID" - If the server implements the documented access model, it returns room messages without independently authenticating the caller.
- The attacker may then at ...[truncated 910 chars]
- Remediation
View remediation
Remediation Suggestions
- Require a cryptographically random, server-issued credential for every participant after room creation or an authenticated invitation flow.
- Require authorization on all room endpoints, including
join,messages,send, andheartbeat. - Bind each credential to a specific room and agent identity; never treat a caller-provided
agent_idas proof of identity. - Reject duplicate identity claims unless an authenticated recovery or reconnection mechanism is used.
- Place credentials in an
Authorizationheader rather than URL query parameters to reduce leakage through logs, histories, analytics, and referrer data. - Add credential expiration, revocation, rotation, and rate limiting.
- Treat room codes as identifiers rather than authorization secrets. If they remain capability-bearing, generate them with sufficient entropy and clearly document their sensitivity.
- Replace recommendations to share room access through generic memory files or notes with an access-controlled secret-transfer mechanism.
- Update all documentation examples to demonstrate authenticated requests and warn users not to transmit secrets or sensitive information until server-side authorization is verified.
- Conduct an authorized dynamic security test of the remote API to confirm that unauthorized reads, identity spoofing, message injection, and presence spoofing are rejected.