{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "paperclipai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.403.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T22:47:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "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`",
  "id": "GHSA-gqqj-85qm-8qhf",
  "modified": "2026-04-16T22:47:40Z",
  "published": "2026-04-16T22:47:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/paperclipai/paperclip/security/advisories/GHSA-gqqj-85qm-8qhf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/paperclipai/paperclip"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Paperclip: codex_local inherited ChatGPT/OpenAI-connected Gmail and was able to send real email"
}