Paperclip cross-tenant agent API key IDOR in /agents/:id/keys

Severity: low · CVSS 3.1 · Published 2026-04-16

Paperclip is an open-source platform for managing AI agents in enterprises. A critical authorization bypass in its control-plane API allows any authenticated user from one company to create, list, and revoke API keys for agents belonging to other companies, then authenticate as those agents to access victim data and workflows. This enables complete cross-tenant compromise where an attacker can impersonate agents in rival organizations and execute any operation they are authorized to perform.

Technologies: @paperclipai/server (npm), Paperclip AI Paperclip. Vendors: npm, Paperclip AI.

Quick answers

Is This vulnerability exploited in the wild?
No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
How severe is This vulnerability?
Low severity, with a CVSS score of 3.1, published 16 April 2026.
Which products and versions are affected?
@paperclipai/server (npm) SEMVER:introduced=0,fixed=2026.416.0; Paperclip AI Paperclip <= 2026.410.0-canary.1.
Is there a fix for This vulnerability?
Yes. @paperclipai/server (npm): upgrade to 2026.416.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is This vulnerability attacked?
It is attacked over the network, in a software library.
Am I affected?
Check whether you run @paperclipai/server (npm) or Paperclip AI Paperclip at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • @paperclipai/server (npm): upgrade to 2026.416.0 or later
    npm install @paperclipai/server@2026.416.0

Technical details

The vulnerability is an insecure direct object reference (IDOR) / authorization bypass in the three key-management routes (GET, POST, DELETE) under /agents/:id/keys. The handlers call assertBoard(req) which only verifies the caller is a board-type user, but omit assertCompanyAccess(req, companyId) to verify the caller owns the target agent's company. The POST handler returns the newly-created API key in cleartext. The service layer (agents.ts) does not validate company membership either—it only checks agent existence and status. When used, the returned token sets req.actor.companyId to the victim's company, allowing it to bypass all downstream company-access checks. The DELETE route has an additional flaw: it only requires keyId and ignores the agentId URL parameter, so any authenticated user can revoke any key by its id. Agent UUIDs are widely exposed to board users, and key IDs are disclosed by the GET endpoint, eliminating any ID-guessing difficulty. Fix: call assertCompanyAccess(req, agent.companyId) in all three routes before operating on keys, mirroring the pattern used in adjacent /agents/:id/wakeup and /agents/:id/heartbeat/invoke routes (both of which correctly perform this check). Patched in v2026.416.0.

Affected products

  • Paperclip AI Paperclip <= 2026.410.0-canary.1

Timeline

  • 2026-04-16: disclosed: Advisory published on GitHub and OSV
  • 2026-04-16: patched: Fixed in v2026.416.0

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.