Attack Chain

1. Attacker signs up for a Paperclip account using the default /api/auth/sign-up/email endpoint.
2. Attacker verifies their account and confirms they have no company memberships via GET /api/companies.
3. Attacker identifies the ID of a target agent belonging to a different company, potentially through activity feeds or other exposed APIs.
4. Attacker sends a POST request to /api/agents/:id/keys with a desired name for the API key, targeting the victim agent’s ID.
5. The server responds with a 201 status code, returning a plaintext pcp_* token. No company access check is performed at this stage.
6. Attacker uses the stolen token as a Bearer credential in subsequent API requests.
7. The actorMiddleware resolves the token to an actor with the victim’s company ID, bypassing authorization checks.
8. Attacker can now access sensitive information such as company metadata, issues, approvals, and agent configurations via API endpoints like /api/companies/:victimId, /api/companies/:victimId/issues, and /api/agents/:victimAgentId. They can also pause, terminate, or delete the agent using other vulnerable endpoints.

Impact

This vulnerability allows for a complete bypass of tenancy boundaries in Paperclip. The impact includes:

• Confidentiality: Unauthorized access to sensitive company data, including metadata, issues, approvals, agent configurations, and adapter settings.
• Integrity: Ability to manipulate agent configurations and trigger actions within the victim tenant, potentially leading to data breaches or malicious activities.
• Availability: Ability to pause, terminate, or delete agents belonging to other companies, disrupting their operations.

The severity is high due to the ease of exploitation, default configurations, and the persistence of the stolen tokens. The vulnerability affects all Paperclip instances running in authenticated mode with open sign-up enabled.

Recommendation

• Apply the suggested fix provided in the advisory to server/src/routes/agents.ts by implementing company access checks (assertCompanyAccess) for the /api/agents/:id/keys endpoint.
• Audit and apply similar fixes to the sibling lifecycle handlers at /agents/:id/pause, /resume, /terminate, and DELETE /agents/:id as these share the same vulnerability.
• Conduct a code-wide sweep for assertBoard(req) calls not immediately followed by assertCompanyAccess or assertInstanceAdmin to identify and address other potential cross-tenant access issues.
• Deploy the Sigma rules provided below to your SIEM and tune for your environment to detect unauthorized token minting and API access.
• Monitor Paperclip server logs for unusual API requests to /api/agents/:id/keys from users without company memberships.

Attack Chain

1. The attacker authenticates as a board user within Company A.
2. The attacker discovers or obtains the UUID of an agent belonging to Company B.
3. The attacker sends a POST request to /agents/<VICTIM_COMPANY_B_AGENT_ID>/keys with a name to create a new API key.
4. The server, lacking proper authorization checks, creates a new API key associated with the victim agent’s companyId and returns the cleartext token.
5. The attacker uses the newly minted agent token in the Authorization header to authenticate subsequent requests.
6. The server’s authentication middleware incorrectly sets the req.actor to an agent type associated with the victim’s company.
7. The attacker successfully accesses resources and executes actions within Company B’s tenant, bypassing company access checks.
8. The attacker can enumerate and revoke existing keys using the /agents/:id/keys and /agents/:id/keys/:keyId endpoints, causing denial of service to legitimate users.

Impact

This vulnerability leads to a full cross-tenant compromise. An attacker can gain unauthorized access to any tenant within the Paperclip instance, provided they have a minimal valid account (board user in any company) and a victim agent UUID. This allows the attacker to execute workflows, read sensitive data, and call any authorized endpoint within the victim tenant, leading to complete confidentiality, integrity, and availability loss. Furthermore, the attacker can revoke legitimate agent keys, resulting in a denial of service. This represents a scope change, where a vulnerability in Company A’s scoping checks results in catastrophic impact within Company B’s tenant.

Recommendation

• Implement explicit company-access checks on the /agents/:id/keys (GET, POST) and /agents/:id/keys/:keyId (DELETE) routes before interacting with the service layer. This directly addresses the core issue as described in the advisory’s “Recommended Fix” section.
• Deploy the Sigma rule Detect Paperclip Cross-Tenant API Key Creation to identify unauthorized API key creation attempts.
• Deploy the Sigma rule Detect Paperclip Cross-Tenant API Access to detect unauthorized access using stolen agent tokens.
• Upgrade to npm/@paperclipai/server version 2026.416.0 or later to patch the vulnerability as mentioned in the advisory’s “Affected Packages” section.