T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:45
- Finding
- Overly Broad Cross-Session Visibility<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:45-66` **Vulnerability Type**: Excessive session permissions and violation of least privilege **Risk Level**: Medium ### Vulnerable Code Snippet ```json { "tools": { "agentToAgent": { "enabled": true }, "sessions": { "visibility": "all" } }, "agents": { "list": [ { "id": "main", "tools": { "allow": [ "sessions_spawn", "sessions_send", "sessions_history", "sessions_list" ] } } ] } } ``` ### Technical Analysis The recommended host configuration grants the main agent visibility into all sessions while also permitting it to read session history and send cross-session messages. This is broader than the Skill's stated requirement of managing only the task sessions associated with a particular Feishu account and peer. The registry contains session keys used as routing capabilities. However, the documented workflow does not require the runtime to verify that a session key belongs to the current channel, account, peer, or registry before calling `sessions_send` or `sessions_history`. With `sessions.visibility=all`, an incorrectly selected, attacker-influenced, or leaked session key could therefore reference an unrelated session. The issue is an access-control weakness rather than evidence of intentionally malicious behavior. Exploitation depends on the host applying the recommended global visibility configuration and an attacker being able to influence or obtain a session identifier. ### Attack Path 1. An operator enables `sessions.visibility=all` using the configuration recommended by the Skill. 2. The main agent receives permission to use `sessions_send` and `sessions_history` against globally visible sessions. 3. An attacker causes an unrelated session key to enter the active task registry, manipulates routing context, or supplies a session identifier through another agen ...[truncated 816 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Replace global session visibility with the narrowest supported scope, preferably sessions spawned by the current parent agent. 2. Maintain an authoritative mapping of each spawned session key to its channel, account, peer, and task ID. 3. Before every `sessions_send` or `sessions_history` call, verify that: - the session key exists in the current peer's registry; - the session was created by this workbench; - the channel, account, and peer match the active request; - the task has not been archived or otherwise made inaccessible. 4. Do not accept session keys directly from user messages. 5. If the platform supports only global visibility, add an application-level session allowlist and deny access by default. 6. Avoid displaying session keys in normal task status output. Expose them only through a separately authorized diagnostic mode with appropriate redaction and audit logging. 7. Log rejected cross-session access attempts without recording complete session keys or private message contents. ]]>