GHSA-gqqj-85qm-8qhf: paperclipai: connector trust bypass enables Gmail read/write

### Summary A Paperclip-managed `codex_local` runtime was able to access and use a Gmail connector that I had connected in the ChatGPT/OpenAI apps UI, even though I had not explicitly connected Gmail inside Paperclip or separately inside Codex. In my environment this enabled mailbox access and a real outbound email to be sent from my Gmail account. After I manually intervened to stop the workflow, follow-up retraction messages were also sent, confirming repeated outward write/send capability. This appears to be a trust-boundary failure between Paperclip-managed Codex execution and inherited OpenAI app connectors, amplified by dangerous-by-default runtime settings. ### Details Successful runtime calls include: - `mcp__codex_apps__gmail_get_profile` - `mcp__codex_apps__gmail_search_emails` - `mcp__codex_apps__gmail_send_email` The connected Gmail profile resolved to my personal account. Inside the Paperclip-managed `codex-home`, I also found cached OpenAI curated connector state for Gmail under a path like: - `codex-home/plugins/cache/openai-curated/gmail/.../.app.json` This strongly suggests that the runtime had access to an already connected OpenAI apps surface rather than a Paperclip-specific Gmail integration that I intentionally configured. Separately, in the installed Paperclip code, `codex_local` defaults `dangerouslyBypassApprovalsAndSandbox` to `true`, and the server-side agent creation path applies that default when the flag is omitted. In practice, that makes this boundary failure much more dangerous because a newly created `codex_local` agent can operate with approvals and sandbox bypassed by default. The key issue is this: I had connected Gmail only in the ChatGPT/OpenAI apps UI. I had not intentionally connected Gmail inside Paperclip or separately inside Codex. Despite that, the Paperclip-managed `codex_local` runtime was able to use Gmail read/write actions. ### PoC Environment: - self-hosted Paperclip instance using `codex_local` - Gmail connected in the ChatGPT/OpenAI apps UI - no explicit Gmail connection configured inside Paperclip for this test - `codex_local` agent created and run with default behavior Observed reproduction path: 1. Connect Gmail in the ChatGPT/OpenAI apps UI. 2. Create or run a Paperclip `codex_local` agent. 3. Execute a task that inspects mailbox state or performs outward communication. 4. Observe successful Gmail connector calls such as: - `mcp__codex_apps__gmail_get_profile` - `mcp__codex_apps__gmail_search_emails` - `mcp__codex_apps__gmail_send_email` 5. Observe that the connected profile resolves to the ChatGPT/OpenAI-connected Gmail account and that mailbox reads and real sends are possible. Private evidence available on request: - successful `get_profile` / `search` / `send` logs - Paperclip-managed `codex-home` Gmail connector cache path(s) - screenshot showing Gmail write-capable actions such as `send_email`, `send_draft`, and `update_draft` exposed in the connected-app UI - incident timeline showing that a real outbound email was sent - recipient organizations, timestamps, message IDs, and sanitized evidence for both the original outbound email and the subsequent retraction messages ### Impact This was not only theoretical in my environment. It resulted in: - mailbox identity disclosure - mailbox search / thread access - a real outbound email being sent from a personal connected Gmail account to an external third party - follow-up retraction messages being sent after manual intervention, confirming repeated outward write/send capability From an operator/security perspective, connecting Gmail in the ChatGPT/OpenAI apps UI should not automatically make that connector available to a Paperclip-managed local agent runtime, especially not for write/send actions. One or more of the following: - no inherited OpenAI app connectors by default in Paperclip-managed `codex_local` runs - send/write connectors blocked by default - explicit Paperclip-side opt-in before outward actions - auditable approval and provenance for connector-mediated actions - safer defaults, including `dangerouslyBypassApprovalsAndSandbox = false`

An attacker gains access to a self-hosted Paperclip instance (e.g., via a compromised employee account or misconfigured access controls). They create a codex_local agent with default settings and assign it a task that inspects mailbox state — phrased as a benign automation like 'summarize my recent emails.' The runtime discovers cached OpenAI connector credentials under codex-home/plugins/cache/openai-curated/gmail/ and silently inherits the connected Gmail account. With dangerouslyBypassApprovalsAndSandbox = true (the default), no approval prompt fires. The agent proceeds to call gmail_get_profile, gmail_search_emails, and gmail_send_email — exfiltrating sensitive threads and sending spear-phishing emails from the victim's trusted personal address to external targets without any user confirmation.