Description

Cap-go capgo.app before 12.267.1 fails to validate target API key privilege during rotation, allowing an apikey_manager to rotate a higher-privileged org_super_admin sibling key and recover its plaintext credential. Attackers with apikey_manager role can enumerate same-owner API keys, rotate a stronger sibling through the PUT endpoint, and obtain the replacement plaintext secret to authenticate as the higher-privileged principal.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-26T14:16:42.193Z",
  "pubdate": "2026-09-26T14:16:42.193Z",
  "executiveSummary": "Cap-go versions prior to 12.267.1 are susceptible to a critical improper privilege validation vulnerability within the API key rotation mechanism. This flaw allows an authenticated user with the 'apikey_manager' role to perform an unauthorized privilege escalation by rotating API keys belonging to higher-privileged accounts, specifically the 'org_super_admin' role.\nThe vulnerability stems from the application's failure to verify if an 'apikey_manager' possesses the necessary permissions to modify keys belonging to superior or sibling principals. By exploiting this oversight, an attacker can force the rotation of a stronger, more privileged API key and capture the resulting plaintext secret.\nThe successful exploitation of this vulnerability grants an attacker full administrative control over the targeted organization by assuming the identity of the 'org_super_admin'. This presents a severe security risk, potentially leading to total system compromise, data exfiltration, and unauthorized management of organizational assets. Exploitation requires authenticated access with 'apikey_manager' privileges but does not necessitate further system access beyond the provided API interface.",
  "technicalDetails": "The root cause of this vulnerability is an authorization logic failure in the API key management subsystem of Cap-go. Specifically, the PUT endpoint designated for API key rotation fails to validate the target's privilege level against the requestor's role during the rotation lifecycle. The application assumes that any user authorized to manage keys for a given owner can rotate any key within that same scope, failing to implement hierarchical privilege checks between the 'apikey_manager' role and the 'org_super_admin' role.\nThe attack flow begins with the adversary, who possesses the 'apikey_manager' role, authenticating to the platform. Through the API, the attacker enumerates all available API keys sharing the same owner ID. Once a target 'org_super_admin' sibling key is identified, the attacker issues a PUT request to the rotation endpoint. Because the application logic does not perform a permission check on the target key's privilege metadata, it processes the request and generates a new API key.\nA critical aspect of this flaw is the insecure disclosure of the newly generated credential. Upon successful rotation, the backend returns the plaintext representation of the replacement secret to the caller. The attacker captures this plaintext, which corresponds to the 'org_super_admin' account. With the newly acquired credential, the attacker can authenticate as the 'org_super_admin', effectively bypassing all intended access control restrictions and gaining elevated, administrative control over the organization's instance of Cap-go.\nThis vulnerability is present in versions of Cap-go before 12.267.1. It is accessible through the standard API communication channels used for key lifecycle management. Because the vulnerability is logic-based, no complex memory corruption or side-channel techniques are required; it is a direct abuse of an insecurely implemented administrative function."
}