T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:16
- Finding
- Hardcoded Gmail Account May Permit Unauthorized Mailbox Metadata Disclosure## Vulnerability Details **File Location**: `SKILL.md`, lines 16–18 **Vulnerability Type**: Hardcoded account selection without an explicit authorization check **Risk Level**: Medium ### Vulnerable Code ```bash gog gmail search "in:inbox" --max 5 --json --results-only --account william.kettle@neuralshift.co.uk ``` ### Technical Analysis The skill directs the agent to query a fixed Gmail account rather than selecting an account based on the invoking user's identity or requiring confirmation before access. It also instructs the agent to return the sender, subject, and date of the five newest inbox messages. In a shared environment where `gog` already has valid credentials for the hardcoded account, a user who can invoke the skill may cause the agent to access and display mailbox metadata without demonstrating that they are authorized to view that mailbox. The command does not bypass Gmail authentication or acquire additional Gmail permissions; exploitation depends on valid credentials already being available to the agent process. ### Attack Path 1. An administrator or mailbox owner authenticates `gog` for `william.kettle@neuralshift.co.uk` in an environment accessible to the agent. 2. Another user with access to that agent invokes `/skill gmail_last5`. 3. The agent executes the hardcoded `gog gmail search` command using the existing credentials. 4. Gmail returns the five newest inbox search results. 5. The agent exposes message senders, subjects, and dates to the invoking user without a separate authorization check. ### Impact Assessment A successful exploit can disclose private email metadata, including correspondent identities, subject lines, and message timestamps, from the hardcoded mailbox. Subject lines may contain confidential business, personal, security, or account-related information. The scope is limited to data accessible through the credentials and permissions already configured for `gog`. No evidence sh ...[truncated 156 chars]
- Remediation
- ## Remediation Suggestions 1. Remove the hardcoded Gmail address from the skill command. 2. Resolve the mailbox from the authenticated invoking user's approved account context. 3. If multiple accounts are configured, list only authorized account identifiers and require the user to select and explicitly confirm one before querying it. 4. Enforce server-side or agent-platform authorization so permission is not based solely on whether `gog` has cached credentials. 5. Isolate Gmail credentials by user and avoid sharing credential stores across unrelated users or sessions. 6. Apply least-privilege Gmail scopes and restrict the integration to read-only access when mailbox modification is unnecessary. 7. Warn users that email metadata will be displayed, and consider redacting sensitive subject lines in shared channels. 8. Record mailbox access in an audit log containing the invoking identity, selected account, time, and operation, while excluding message content and secrets. 9. On command failure, do not reveal configured account identities to unauthorized users; direct them to an administrator or a secure account-selection workflow.
