Paperclip: Cross-tenant agent API token minting via missing assertCompanyAccess on /api/agents/:id/keys
<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" al
