GHSA-GQQJ-85QM-8QHF

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

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

GHSA-GQQJ-85QM-8QHF has a CVSS score of 8.7 (High). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. No fixed version is listed yet, so configuration controls and monitoring matter more in the interim.

Kodem intelligence

1. What is GHSA-GQQJ-85QM-8QHF? GHSA-GQQJ-85QM-8QHF is a high-severity security vulnerability in paperclipai (npm), affecting versions <= 2026.403.0. No fixed version is listed yet.
2. How severe is GHSA-GQQJ-85QM-8QHF? GHSA-GQQJ-85QM-8QHF has a CVSS score of 8.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of paperclipai are affected by GHSA-GQQJ-85QM-8QHF? paperclipai (npm) versions <= 2026.403.0 is affected.
4. Is there a fix for GHSA-GQQJ-85QM-8QHF? No fixed version is listed for GHSA-GQQJ-85QM-8QHF yet. Monitor the advisory for updates and apply mitigations in the interim.
5. Is GHSA-GQQJ-85QM-8QHF exploitable, and should I be worried? Whether GHSA-GQQJ-85QM-8QHF is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether GHSA-GQQJ-85QM-8QHF is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.