GHSA-gqqj-85qm-8qhf
HIGHPaperclip: codex_local inherited ChatGPT/OpenAI-connected Gmail and was able to send real email
Blast Radius
paperclipaiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
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_profilemcp__codex_apps__gmail_search_emailsmcp__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_localagent created and run with default behavior
Observed reproduction path:
- Connect Gmail in the ChatGPT/OpenAI apps UI.
- Create or run a Paperclip
codex_localagent. - Execute a task that inspects mailbox state or performs outward communication.
- Observe successful Gmail connector calls such as:
mcp__codex_apps__gmail_get_profilemcp__codex_apps__gmail_search_emailsmcp__codex_apps__gmail_send_email
- 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/sendlogs - Paperclip-managed
codex-homeGmail connector cache path(s) - screenshot showing Gmail write-capable actions such as
send_email,send_draft, andupdate_draftexposed 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_localruns - 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
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | paperclipai | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for paperclipai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Remediation status
No patched version of paperclipai has shipped for GHSA-gqqj-85qm-8qhf yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-gqqj-85qm-8qhf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-gqqj-85qm-8qhf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-gqqj-85qm-8qhf in your dependencies?
O3 detects GHSA-gqqj-85qm-8qhf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.