GHSA-gqqj-85qm-8qhf: Paperclip Codex_local Inherited ChatGPT/OpenAI-connected Gmail And Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-gqqj-85qm-8qhf",
  "modified" : "2026-04-16T22:47:40Z",
  "published" : "2026-04-16T22:47:40Z",
  "aliases" : [ ],
  "summary" : "Paperclip: codex_local inherited ChatGPT/OpenAI-connected Gmail and was able to send real email",
  "details" : "### Summary\n\nA 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.\n\nIn 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.\n\nThis appears to be a trust-boundary failure between Paperclip-managed Codex execution and inherited OpenAI app connectors, amplified by dangerous-by-default runtime settings.\n\n### Details\n\nSuccessful runtime calls include:\n\n- `mcp__codex_apps__gmail_get_profile`\n- `mcp__codex_apps__gmail_search_emails`\n- `mcp__codex_apps__gmail_send_email`\n\nThe connected Gmail profile resolved to my personal account.\n\nInside the Paperclip-managed `codex-home`, I also found cached OpenAI curated connector state for Gmail under a path like:\n\n- `codex-home/plugins/cache/openai-curated/gmail/.../.app.json`\n\nThis 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.\n\nSeparately, 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.\n\nThe 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.\n\n### PoC\n\nEnvironment:\n\n- self-hosted Paperclip instance using `codex_local`\n- Gmail connected in the ChatGPT/OpenAI apps UI\n- no explicit Gmail connection configured inside Paperclip for this test\n- `codex_local` agent created and run with default behavior\n\nObserved reproduction path:\n\n1. Connect Gmail in the ChatGPT/OpenAI apps UI.\n2. Create or run a Paperclip `codex_local` agent.\n3. Execute a task that inspects mailbox state or performs outward communication.\n4. Observe successful Gmail connector calls such as:\n   - `mcp__codex_apps__gmail_get_profile`\n   - `mcp__codex_apps__gmail_search_emails`\n   - `mcp__codex_apps__gmail_send_email`\n5. Observe that the connected profile resolves to the ChatGPT/OpenAI-connected Gmail account and that mailbox reads and real sends are possible.\n\nPrivate evidence available on request:\n\n- successful `get_profile` / `search` / `send` logs\n- Paperclip-managed `codex-home` Gmail connector cache path(s)\n- screenshot showing Gmail write-capable actions such as `send_email`, `send_draft`, and `update_draft` exposed in the connected-app UI\n- incident timeline showing that a real outbound email was sent\n- recipient organizations, timestamps, message IDs, and sanitized evidence for both the original outbound email and the subsequent retraction messages\n\n### Impact\n\nThis was not only theoretical in my environment. It resulted in:\n\n- mailbox identity disclosure\n- mailbox search / thread access\n- a real outbound email being sent from a personal connected Gmail account to an external third party\n- follow-up retraction messages being sent after manual intervention, confirming repeated outward write/send capability\n\nFrom 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.\n\nOne or more of the following:\n\n- no inherited OpenAI app connectors by default in Paperclip-managed `codex_local` runs\n- send/write connectors blocked by default\n- explicit Paperclip-side opt-in before outward actions\n- auditable approval and provenance for connector-mediated actions\n- safer defaults, including `dangerouslyBypassApprovalsAndSandbox = false`",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "paperclipai"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "last_affected" : "2026.403.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/paperclipai/paperclip/security/advisories/GHSA-gqqj-85qm-8qhf"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/paperclipai/paperclip"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-284" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-16T22:47:40Z",
    "nvd_published_at" : null
  }
}