# GHSA-gqqj-85qm-8qhf: Paperclip: codex_local inherited ChatGPT/OpenAI-connected Gmail and was able to send real email > Paperclip's codex_local runtime inherits Gmail access from ChatGPT/OpenAI apps, allowing unauthorized email reading and sending without explicit user consent. - **Severity:** Not scored - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Over the internet - **Victim action needed:** Not needed - **Fix available:** No - **Published:** 16 Apr 2026 ## What is GHSA-gqqj-85qm-8qhf? GHSA-gqqj-85qm-8qhf is a missing authorization vulnerability in paperclipai, published on 16 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim. ### Official description ### 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` ## Which versions are affected by GHSA-gqqj-85qm-8qhf? 2 open source packages ship an affected version, including paperclipai. | Package | Ecosystem | Affected | Fixed in | | --- | --- | --- | --- | | `paperclipai` | npm | All versions to 2026.403.0 | None | | `paperclipai` | npm | All versions to 2026.403.0 | None | ## How do I fix GHSA-gqqj-85qm-8qhf? No fix has been published for GHSA-gqqj-85qm-8qhf yet. Limit exposure of the affected software until one is available. ## Is GHSA-gqqj-85qm-8qhf being exploited? There is no known exploitation of GHSA-gqqj-85qm-8qhf in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for GHSA-gqqj-85qm-8qhf and fix it if it is affected. What it is: GHSA-gqqj-85qm-8qhf is a missing authorization vulnerability in paperclipai, published on 16 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim. Exploitation: There is no known exploitation of GHSA-gqqj-85qm-8qhf in the wild and no public exploit code. Affected packages and fixed versions: - paperclipai (npm): affected all versions up to 2026.403.0; no fix listed - paperclipai (npm): affected all versions up to 2026.403.0; no fix listed Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/GHSA-gqqj-85qm-8qhf/ (Markdown: https://insights.sbomify.com/GHSA-gqqj-85qm-8qhf/index.md) ``` ## Sources - OSV: https://osv.dev/vulnerability/GHSA-gqqj-85qm-8qhf --- From sbomify Insights: https://insights.sbomify.com/GHSA-gqqj-85qm-8qhf/ Summaries are generated and may contain mistakes; the official description above is the record.