Attack Chain

1. The attacker sends an unauthenticated GET request to /api/health to obtain deployment mode, exposure setting, auth status, version, and feature flags.
2. The attacker sends an unauthenticated GET request to /api/skills/index to retrieve a list of available skill endpoints.
3. The attacker sends an unauthenticated GET request to /api/skills/paperclip to leak the agent heartbeat procedure, API endpoints, parameters, authentication mechanisms, and agent coordination protocols.
4. The attacker sends an unauthenticated GET request to /api/heartbeat-runs/:runId/issues, attempting to access issue data for a heartbeat run by guessing or obtaining a valid runId.
5. The attacker sends an unauthenticated POST request to /api/cli-auth/challenges with a JSON payload containing a command to create a CLI authentication challenge and obtain a boardApiToken.
6. The attacker uses the leaked information to map the internal API structure and plan further attacks or unauthorized access.
7. The attacker exploits the boardApiToken obtained in step 5, combined with open registration (if enabled), to persistently generate API keys.

Impact

This vulnerability results in significant data exposure, including heartbeat run issues, agent instructions, and internal API structure. An attacker can fingerprint the deployment and map the entire internal API for reconnaissance purposes. Successful exploitation of the unauthenticated CLI challenge creation allows for authentication bypass, potentially leading to a full remote code execution chain. The vulnerability affects organizations using Paperclip versions prior to 2026.416.0. A successful attack can compromise sensitive data, facilitate unauthorized access, and lead to further malicious activities.

Recommendation

• Apply the patch to upgrade Paperclip to version 2026.416.0 or later, which addresses the unauthenticated API access vulnerabilities.
• Implement authentication checks for the /api/heartbeat-runs/:runId/issues endpoint in server/src/routes/activity.ts using assertCompanyAccess.
• Implement authentication checks for the /api/cli-auth/challenges endpoint in server/src/routes/access.ts using assertBoard.
• Implement authentication checks for the /api/skills/index and /api/skills/:skillName endpoints in server/src/routes/access.ts.
• Reduce the information exposed by the /api/health endpoint by removing sensitive data such as deploymentMode, deploymentExposure, and version or by requiring authentication via assertBoard.
• Deploy the Sigma rule “Detect Paperclip Unauthenticated Health Endpoint Access” to identify unauthorized access attempts to the /api/health endpoint.

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.