Executive brief
A security flaw in the Paperclip control-plane API allows an authorized user from one company to gain full access to another company's data and operations. By exploiting an oversight in how API keys are managed, an attacker can generate new credentials for any 'agent' in the system, regardless of which organization it belongs to. This results in a complete takeover of the victim's environment, allowing the attacker to read sensitive information, execute workflows, or disrupt services.
Technical details
An Insecure Direct Object Reference (IDOR) exists in the `GET`, `POST`, and `DELETE` handlers for `/agents/:id/keys`. The application uses `assertBoard(req)` to verify the actor type but fails to call `assertCompanyAccess(req, companyId)` to validate that the actor belongs to the company owning the target agent. An attacker can provide a victim agent's UUID to list existing keys, create new API keys, or revoke legitimate keys. Because the `POST` handler returns the new API token in cleartext and the authentication middleware assigns the victim's `companyId` to that token, the attacker gains full authorized access to the victim tenant's API surface. This is a classic scope-change vulnerability where a low-privileged user in one tenant compromises the entire boundary of another tenant.
Affected products
- Paperclip @paperclipai/server < 2026.416.0
Timeline
- 2026-04-16: disclosed
- 2026-04-16: patched: Fixed in version 2026.416.0