Cross-Tenant Agent API Key IDOR – Missing Company-Level Authorization Checks

Vulnerability Description

The vulnerability is an Insecure Direct Object Reference (IDOR) combined with insufficient authorization validation in multi-tenant architecture. The three handler functions (GET, POST, DELETE) under /agents/:id/keys perform only session-type validation (assertBoard(req)) without verifying that the authenticated board-user belongs to the same company as the target agent. The root cause is the absence of a company-level ownership check before executing privileged operations. The impact is severe: an attacker with valid board credentials from any tenant can manipulate agent API keys across all other tenants, effectively gaining agent-level compromise in victim environments.

Proof-of-Concept Significance

This PoC demonstrates a reliable, deterministic exploitation path requiring minimal preconditions: (1) valid board-session credentials from any company, (2) knowledge or enumeration of victim agent UUIDs. The POST handler returning cleartext tokens is particularly damaging—it eliminates the need for token interception. The vulnerability is tenant-agnostic; any board user can target any agent globally. Exploitation likelihood is high because: agent UUIDs may be discoverable via enumeration or information leakage, and the attack requires no special privileges beyond basic board-level access.

Detection Guidance

Log indicators to monitor:

• Access to /agents/{id}/keys endpoints where the authenticated companyId differs from the agent owner's companyId
• Unusual spike in POST /agents/:id/keys requests (token generation) from a single board-user across multiple agent UUIDs
• DELETE /agents/:id/keys/:keyId calls targeting agents outside the user's assigned company
• Cleartext agent API tokens appearing in response payloads in access logs or WAF records

Detection queries: Alert on authentication logs showing board-sessions followed by agent-key operations where req.params.id maps to a foreign company.

Mitigation Steps

1. Immediate patch: Add company-ownership validation before all three handlers execute business logic:

   const agent = await svc.getAgent(id);
   assertUserBelongsToCompany(req.user, agent.companyId);
   

2. Code review: Audit all routes accepting :id parameters to ensure they validate resource ownership against authenticated context
3. Workground (temporary): Restrict board-level API access to company-specific scopes; implement per-user company allowlists in session middleware
4. Logging: Enable detailed request/response auditing on /agents/:id/keys with headers and authenticated user identity
5. Rotation: Force revocation of all agent API keys issued within the vulnerability window; rotate credentials for all agents

Risk Assessment

Likelihood of exploitation in the wild: HIGH. The vulnerability requires minimal attacker sophistication and provides maximum impact (full tenant compromise). Threat actors interested in supply-chain attacks or lateral movement would prioritize this. Threat actor interest: CRITICAL. This enables persistence, data exfiltration, and lateral pivots across customer infrastructure. The cleartext token return eliminates operational friction for attackers. Organizations should treat this as an active threat requiring immediate patching and forensic analysis of /agents/:id/keys access logs for the past 6–12 months.